tutorial

How to Monitor Tyk API Gateway with Vigilmon (HTTP, TCP, and Alerts)

Tyk is the open-source API management platform used by enterprises at Vodafone, Starbucks, and hundreds of SaaS companies. It handles API key management, rat...

Tyk is the open-source API management platform used by enterprises at Vodafone, Starbucks, and hundreds of SaaS companies. It handles API key management, rate limiting, analytics, and OAuth — all the critical infrastructure that sits between your customers and your backend services. When the Tyk gateway goes down, every consumer behind it is blocked immediately.

In this tutorial you'll set up end-to-end monitoring for a self-hosted Tyk deployment using Vigilmon — free tier, no credit card required.

Why Tyk needs external monitoring

Tyk's architecture involves several interdependent services:

  • Tyk Gateway — the high-performance API proxy, typically on ports 8080 (HTTP) and 8443 (HTTPS)
  • Tyk Dashboard — the management UI and admin API, typically on port 3000
  • Tyk Pump — the analytics aggregator that writes request data to Redis/MongoDB/Postgres
  • Redis — stores API keys, session data, rate limit counters, and inter-node state
  • MongoDB or PostgreSQL — persistence for policies, API definitions, and users

Failure modes that Tyk's internal health checks miss:

  • Redis connection loss — Tyk Gateway can't validate API keys and starts rejecting all authenticated requests with 401, even for valid keys
  • Dashboard-to-Gateway sync failure — you create a new API definition in the Dashboard, but the Gateway doesn't reload it because the RPC link between them is broken; the new API remains unavailable silently
  • Tyk Pump backlog — Pump can't write to the analytics sink (MongoDB down); the buffer fills and Pump crashes; Gateway continues to serve traffic but analytics go dark
  • Port 8080 vs 8443 mismatch — TLS termination at a load balancer fails, causing 443 traffic to return connection errors while port 8080 still works

What you'll need

  • A running Tyk deployment (Docker Compose, Helm, or Tyk Cloud)
  • A free Vigilmon account — takes 30 seconds to create

Step 1: Identify Tyk health endpoints

Gateway health:

GET http://<gateway-host>:8080/hello

Returns {"status":"pass","version":"5.x.x","description":"Tyk GW"} when the Gateway is operational. This is the primary health endpoint to monitor.

Dashboard health:

GET http://<dashboard-host>:3000/api/debug

Returns system information when the Dashboard is running. Requires the admin_secret header for full details, but returns 200 even without it — useful for liveness checking.

Gateway API test (key validation):

If you have a test API key, you can probe an actual API endpoint to verify end-to-end key validation is working:

curl -H "Authorization: your-test-api-key" https://api.yourcompany.com/your-test-api/health

Test the health endpoints from an external network:

curl -f https://api.yourcompany.com/hello
# Expected: {"status":"pass","version":"5.x.x",...}

Step 2: Expose health endpoints through your load balancer

For production Tyk deployments, traffic arrives through a load balancer or nginx proxy. Make sure the /hello health endpoint is routable without authentication:

server {
    listen 443 ssl http2;
    server_name api.yourcompany.com;

    ssl_certificate     /etc/letsencrypt/live/api.yourcompany.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.yourcompany.com/privkey.pem;

    # Route all API traffic to Tyk Gateway
    location / {
        proxy_pass http://tyk-gateway:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_read_timeout 60s;
    }

    # Health endpoint — allow without auth
    location /hello {
        proxy_pass http://tyk-gateway:8080/hello;
        access_log off;
    }
}

For Kubernetes, the Gateway's /hello endpoint should be reachable via the Service's external IP or Ingress. Tyk's official Helm chart creates a Service of type LoadBalancer — add the /hello path to your Ingress rules if you're routing through an Ingress controller:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tyk-gateway-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /hello
spec:
  rules:
    - host: api.yourcompany.com
      http:
        paths:
          - path: /hello
            pathType: Exact
            backend:
              service:
                name: tyk-gateway-svc
                port:
                  number: 8080

Step 3: Set up HTTP monitoring in Vigilmon

Gateway health monitor:

  1. Log in to vigilmon.online and go to Monitors → New Monitor
  2. Choose HTTP / HTTPS as the type
  3. Set the URL to https://api.yourcompany.com/hello
  4. Set the check interval to 1 minute
  5. Under Expected response, set:
    • Status code: 200
    • Response body contains: "status":"pass"
  6. Save the monitor

Dashboard availability monitor:

Create a second HTTP monitor pointing to https://tyk-dashboard.yourcompany.com with expected status 200. The Dashboard going down doesn't break live API traffic, but it blocks all policy changes and API onboarding.

End-to-end API key validation:

If you maintain a dedicated synthetic test key, create an HTTP monitor that exercises a real API call through Tyk — including key validation, rate limiting, and proxy to the upstream:

URL: https://api.yourcompany.com/healthtest/v1/ping
Headers: Authorization: <your-test-key>
Expected status: 200
Expected body: {"status":"ok"}

This is the most valuable monitor in your Tyk setup — it validates that the entire Gateway pipeline (key lookup in Redis → rate limit check → upstream proxy) is working.

Step 4: Monitor Redis and MongoDB via TCP

Redis is the most critical Tyk dependency. Without it, all key validation fails:

  1. In Vigilmon, go to Monitors → New Monitor
  2. Choose TCP Port
  3. Enter your Redis host and port 6379
  4. Save the monitor

For Redis Sentinel or Redis Cluster, add a TCP monitor for each node — Tyk uses all nodes for different key prefixes.

Add a TCP monitor for MongoDB on port 27017 or PostgreSQL on port 5432 if you're using it for Dashboard persistence.

| Monitor | Type | Port | Why it matters | |---------|------|------|----------------| | Tyk Gateway /hello | HTTP | 443 | Gateway alive and routing | | Tyk Dashboard | HTTP | 443/3000 | Management plane available | | End-to-end API call | HTTP | 443 | Full pipeline: key → rate → proxy | | Redis | TCP | 6379 | Key validation and sessions | | MongoDB | TCP | 27017 | Policy and API definition storage | | Tyk Pump | TCP | 8083 | Analytics pipeline alive |

Step 5: Configure alerting for key validation failures

Tyk gateway failures often manifest as specific HTTP error codes rather than complete outages. Configure Vigilmon to detect these:

400-range error monitor:

Create an additional HTTP monitor on your most critical API path. Set the expected status to 200 — if Tyk returns 401 (key expired), 429 (rate limit), or 502 (upstream down), Vigilmon will open an incident. This catches API-layer failures that the /hello health check won't surface.

Tyk event webhook integration:

Tyk also supports its own event hooks. Configure them to send incidents to your Vigilmon account via webhook for events that Tyk tracks internally:

{
  "event_handlers": {
    "events": {
      "KeyExpired": [
        {
          "handler_name": "eh_web_hook_handler",
          "handler_meta": {
            "method": "POST",
            "target_path": "https://your-internal-webhook-receiver/tyk-events",
            "template_path": "templates/default_webhook.json"
          }
        }
      ]
    }
  }
}

Your webhook receiver can forward critical Tyk events to a Slack channel or PagerDuty for out-of-band alerting separate from Vigilmon's uptime checks.

Step 6: Set up webhook alerts in Vigilmon

When the Tyk gateway goes down, every API consumer is blocked. Your team needs immediate notification:

  1. In Vigilmon, go to Alert Channels → Add Channel → Webhook
  2. Enter your PagerDuty endpoint for the gateway health and end-to-end monitors
  3. Enter a Slack webhook for Dashboard and Redis monitors
  4. Assign the appropriate channels to each monitor

Example incident payload from Vigilmon when the Tyk gateway /hello goes down:

{
  "monitor_name": "Tyk Gateway /hello",
  "status": "down",
  "url": "https://api.yourcompany.com/hello",
  "started_at": "2026-04-22T08:15:00Z",
  "duration_seconds": 93
}

For a multi-region Tyk deployment, create separate alert channels per region so on-call engineers know exactly which Gateway cluster is affected.

Step 7: Set up a status page for API consumers

If Tyk is your public API gateway, your API consumers need a status page:

  1. In Vigilmon, go to Status Pages → New Status Page
  2. Name it after your API product (e.g., "ACME API Status")
  3. Add the Gateway health monitor and the end-to-end API call monitor
  4. Optionally add per-service monitors if your Tyk gateway routes to multiple upstream services
  5. Publish the page and link it from your API documentation and developer portal

A well-maintained status page reduces support ticket volume significantly — developers check the status page before filing a bug report.

Step 8: Monitor Tyk after configuration changes

Tyk configuration changes (new API definitions, policy updates, plugin changes) go through the Dashboard and sync to Gateways via Redis. Misconfigurations can silently break routing for specific APIs while the Gateway /hello endpoint stays healthy.

After every Tyk configuration change, verify your end-to-end Vigilmon monitor stays green. If you have a CI/CD pipeline that deploys Tyk API definitions, add a post-deploy check:

# post-deploy-check.sh
#!/bin/bash
set -e

HEALTH_URL="https://api.yourcompany.com/healthtest/v1/ping"
API_KEY="${SYNTHETICS_API_KEY}"

response=$(curl -s -o /dev/null -w "%{http_code}" \
  -H "Authorization: $API_KEY" \
  "$HEALTH_URL")

if [ "$response" != "200" ]; then
  echo "Post-deploy health check failed: HTTP $response"
  exit 1
fi

echo "Gateway health check passed: HTTP $response"

Run this script in your CI pipeline after every Tyk configuration deployment. If it fails, roll back the API definition changes before they affect production consumers.

Putting it all together

Complete Tyk monitoring setup:

Tyk Gateway /hello            → HTTP monitor, 1-min interval, body: "status":"pass"
Tyk Dashboard                 → HTTP monitor, 1-min interval, status: 200
End-to-end API call           → HTTP monitor, 1-min interval, status: 200
Redis                         → TCP monitor on port 6379
MongoDB                       → TCP monitor on port 27017
Tyk Pump                      → TCP monitor on port 8083

Alert channels:

  • PagerDuty: Gateway /hello, end-to-end API monitor
  • Slack #api-platform: Dashboard, Redis, MongoDB
  • Slack #api-status: public-facing incident notifications

Status page: published to developer portal with 90-day uptime history

What's next

  • SSL certificate monitoring — Tyk terminates TLS for your API consumers. A lapsed certificate is an immediate hard failure for all HTTPS clients. Vigilmon monitors cert expiry and alerts you 14 days before it happens.
  • Tyk Operator on Kubernetes — if you're using Tyk Operator to manage API definitions as CRDs, monitor the Operator's webhook server (usually port 9443) to ensure configuration sync is working.
  • Response time SLAs — Tyk should add minimal latency to API calls. Vigilmon's response time tracking lets you compare latency before and after plugin changes or version upgrades, and alert when P95 latency exceeds your SLA threshold.

Get started free at vigilmon.online — no credit card required, and your first monitors are running in under a minute.

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