tutorial

How to Monitor OpenFaaS Serverless Functions with Vigilmon

OpenFaaS brings serverless function execution to any infrastructure — Kubernetes, Docker Swarm, or bare metal. You package a function, push it to a registry,...

OpenFaaS brings serverless function execution to any infrastructure — Kubernetes, Docker Swarm, or bare metal. You package a function, push it to a registry, and OpenFaaS handles the scaling, queueing, and invocation lifecycle. But that abstraction comes with new blind spots: a gateway that silently stops routing, a function that scales to zero and fails to cold-start, a queue worker that drops messages without error, and an auto-scaler that runs out of replica headroom without telling anyone.

This tutorial walks through setting up external uptime monitoring for OpenFaaS infrastructure using Vigilmon, so you catch function platform failures before they affect your users.

Why OpenFaaS needs external monitoring

OpenFaaS exposes metrics via Prometheus (port 8082 on the gateway by default), and the OpenFaaS UI shows function invocation counts and replica status. But none of that answers the most important question: can the gateway actually serve requests right now?

External monitoring fills the gaps:

  • Gateway process crashes — Prometheus metrics stop updating; the UI may still load from cache while requests are failing
  • Function cold-start failures — a function scaled to zero can fail to spin up when invoked, returning 500s that internal metrics may record but not alert on
  • Ingress misconfiguration — TLS certificate renewal, nginx config errors, or DNS changes can make the gateway unreachable from outside the cluster while appearing healthy internally
  • Queue worker saturation — the NATS streaming queue worker can fall behind and stop processing async invocations while the sync gateway looks fine
  • Provider-level failures — the faas-provider (faasd or the Kubernetes provider) can lose contact with the container runtime, causing all function invocations to hang

Vigilmon monitors from external locations, giving you an independent view that doesn't share failure modes with your OpenFaaS cluster.

What you'll need

  • An OpenFaaS installation (Kubernetes via Helm, or faasd on a VM)
  • The OpenFaaS gateway accessible on a reachable URL (e.g., https://gateway.example.com or http://your-server:8080)
  • A deployed function to monitor (we'll use the built-in nodeinfo function as an example)
  • A free Vigilmon account

Step 1: Verify your OpenFaaS gateway endpoint

The OpenFaaS gateway exposes a readiness endpoint you can probe directly:

GET /healthz

Test it from your local machine:

curl -o /dev/null -s -w "%{http_code}" https://gateway.example.com/healthz
# Expected: 200

If you're using basic auth (the default when installing via arkade or the official Helm chart):

# Get your gateway password
PASSWORD=$(kubectl get secret -n openfaas basic-auth -o jsonpath="{.data.basic-auth-password}" | base64 --decode)

# Test with credentials
curl -u admin:$PASSWORD https://gateway.example.com/healthz
# {"status":"ok"}

The /healthz endpoint checks that the gateway process is alive and connected to the faas-provider. This is the primary endpoint to monitor.

Step 2: Add the gateway health monitor in Vigilmon

  1. Log in to vigilmon.online and click Monitors → New Monitor
  2. Choose HTTP / HTTPS
  3. Set the URL to https://gateway.example.com/healthz
  4. Set the check interval to 1 minute
  5. Under Expected response:
    • Status code: 200
    • Response body contains: ok
  6. If your gateway requires basic auth, add the header:
    • Header name: Authorization
    • Header value: Basic <base64(admin:password)>
  7. Save the monitor

Vigilmon will probe the gateway from multiple regions every minute. If the gateway stops responding — for any reason — you'll get an alert within 60 seconds.

Monitor a specific function endpoint

Beyond the gateway health check, monitor a live function invocation to verify the full execution path:

  1. Add a second HTTP monitor
  2. URL: https://gateway.example.com/function/nodeinfo
  3. Method: GET (or POST if your function requires a body)
  4. Expected status code: 200
  5. Check interval: 2 minutes

If this monitor fails while /healthz passes, you know the gateway is alive but function execution is broken — which narrows your diagnosis immediately.

Step 3: Deploy a minimal health-check function

The nodeinfo function works for testing but isn't purpose-built for health monitoring. For production, deploy a dedicated canary function that you control:

# handler.py
def handle(req):
    return "ok"

# health-check.yml
version: 1.0
provider:
  name: openfaas
  gateway: https://gateway.example.com

functions:
  health-check:
    lang: python3-http
    handler: ./health-check
    image: registry.example.com/health-check:latest
    labels:
      com.openfaas.scale.min: "1"
      com.openfaas.scale.max: "1"
    environment:
      write_debug: false

Deploy it:

faas-cli up -f health-check.yml

Setting scale.min: "1" keeps one replica always warm, eliminating cold-start false positives in your health check. Monitor this function:

GET https://gateway.example.com/function/health-check
Expected: 200, body contains "ok"

Step 4: Monitor the gateway TCP port

TCP monitoring catches port-level failures that happen below the HTTP layer — the process isn't listening at all, a firewall rule dropped the port, or the load balancer removed the backend.

  1. In Vigilmon, go to Monitors → New Monitor
  2. Choose TCP Port
  3. Enter your gateway host and port (default 8080 for HTTP, 443 for HTTPS)
  4. Save the monitor

A TCP failure when the HTTP monitor is also failing confirms the gateway process is completely down. A TCP failure with HTTP passing is a proxy or TLS termination issue upstream.

Step 5: Monitor the Prometheus metrics endpoint

OpenFaaS exposes Prometheus metrics at :8082/metrics on the gateway. While you wouldn't typically scrape these with Vigilmon, you can add a simple HTTP monitor to verify the metrics endpoint is up — which confirms the gateway's internal metrics server is running:

curl http://gateway.example.com:8082/metrics | grep gateway_function_invocation_total

Add this as an HTTP monitor if your metrics port is publicly reachable (on private clusters, this is typically internal-only).

Step 6: Monitor the async queue worker

If you use OpenFaaS's async invocation mode (via the /async-function/ path), the NATS streaming queue worker is a separate process that can fail independently. Verify async invocations work with a dedicated test:

# Submit an async invocation and check the callback
curl -X POST \
  -H "X-Callback-Url: https://webhook.example.com/openfaas-async-test" \
  https://gateway.example.com/async-function/health-check \
  -d ""

For Vigilmon, add an HTTP monitor for the async endpoint itself:

  1. URL: https://gateway.example.com/async-function/health-check
  2. Method: POST
  3. Body: ""
  4. Expected status code: 202 (async accepted)
  5. Check interval: 5 minutes

A 202 means the gateway accepted the message and queued it. If this returns 500 or times out, the queue worker is likely the culprit.

Step 7: Configure alert channels

Function platform outages are typically user-facing, so fast alerting matters.

Email alerts

  1. In Vigilmon, go to Alert Channels → Add Channel → Email
  2. Add your on-call email or team distribution list
  3. Assign to all OpenFaaS monitors

Webhook for Slack or PagerDuty

  1. Go to Alert Channels → Add Channel → Webhook
  2. Paste your Slack incoming webhook URL
  3. Assign to your monitors

Vigilmon sends a payload like:

{
  "monitor_name": "OpenFaaS Gateway Health",
  "status": "down",
  "url": "https://gateway.example.com/healthz",
  "started_at": "2026-07-02T10:00:00Z",
  "duration_seconds": 62
}

Wire this into PagerDuty, create a Slack alert in your #platform-alerts channel, or trigger an automated recovery script.

Step 8: Diagnose OpenFaaS failures from alerts

When Vigilmon fires an alert, work through this checklist:

# 1. Check gateway pod/process status
kubectl get pods -n openfaas
# or for faasd:
systemctl status faasd faasd-provider

# 2. Check gateway logs
kubectl logs -n openfaas deploy/gateway --tail=50
# or:
journalctl -u faasd -n 50 --no-pager

# 3. Check function replica count
faas-cli list
# "0/0" replicas means the function is undeployed or broken

# 4. Check the faas-provider
kubectl logs -n openfaas deploy/faas-netes --tail=50

# 5. Check NATS (async queue)
kubectl logs -n openfaas deploy/nats --tail=30

# 6. Check ingress/TLS
kubectl describe ingress -n openfaas gateway-ingress
kubectl get cert -n openfaas

Common failure patterns

| Symptom | Likely cause | Fix | |---------|-------------|-----| | /healthz returns 503 | faas-provider disconnected | Restart gateway pod, check provider logs | | Function returns 502 | Container runtime issue | Check node status, restart faas-netes | | Function returns 429 | Max replicas reached | Increase scale.max or add capacity | | Async returns 500 | NATS queue worker down | Restart queue-worker deployment | | TCP port unreachable | Gateway process crashed | Check OOM logs, restart gateway |

Step 9: Create a status page for your API consumers

If external services or customers invoke your OpenFaaS functions via API, a shared status page reduces "is the API down?" support requests.

  1. In Vigilmon, go to Status Pages → New Status Page
  2. Name it "Serverless API Status"
  3. Add your monitors:
    • OpenFaaS Gateway Health
    • Health Check Function
    • Async Queue
  4. Publish the page

Share the URL with API consumers. They can subscribe to notifications directly from the status page without needing access to your infrastructure.

Recommended monitoring setup

| Monitor | Type | Interval | What it catches | |---------|------|----------|-----------------| | https://gateway.example.com/healthz | HTTP | 1 min | Gateway process down | | https://gateway.example.com/function/health-check | HTTP | 2 min | Function execution broken | | https://gateway.example.com/async-function/health-check | HTTP | 5 min | Async queue worker down | | gateway.example.com:443 | TCP | 1 min | Port-level failure |

What's next

With external monitoring in place, you'll know the moment your serverless platform stops serving requests — not when a user files a bug report. Next steps for production readiness:

  • Auto-scaling alerts: add a custom endpoint that exposes current replica counts and alert if any function drops below its minimum replica threshold
  • Function error rate tracking: combine Vigilmon uptime alerts with Prometheus alertmanager rules on gateway_function_invocation_total{code="500"} for a complete picture
  • Deployment verification: run your Vigilmon function monitor as a smoke test after every faas-cli deploy in CI, and fail the pipeline if it returns non-200 within 30 seconds

Vigilmon's external perspective catches failures that internal Prometheus metrics miss — certificate expiry, network partitions, and cold-start regressions that only appear under real external traffic.

Start monitoring your OpenFaaS gateway in under 2 minutes at vigilmon.online — free tier, no credit card required.

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles