How to Monitor Tyk API Gateway Health with Vigilmon

Tyk API Gateway is the high-performance API proxy and management layer that sits in front of every backend service in your infrastructure — authenticating API keys, enforcing rate limits, transforming requests, and forwarding to upstream services. When the Tyk Gateway Go process crashes due to an out-of-memory condition caused by a sudden traffic spike loading large response payloads into transformation middleware buffers, every API call reaching your Tyk installation receives a connection refused response immediately — all mobile clients, partner integrations, and internal service-to-service calls that go through the API gateway fail simultaneously with no graceful degradation; when the Redis instance that Tyk uses as its session store and rate limiting backend becomes unreachable due to a Redis restart without Tyk awareness, Tyk enters a mode where it cannot validate API key sessions and rejects all incoming requests with 401 Unauthorized — all authenticated API traffic fails even though upstream services are fully operational; when a deployment of a new upstream service version introduces a regression that increases median response time from 80ms to 3,500ms, the 99th percentile upstream latency visible through Tyk's analytics climbs gradually while SLA breach alerts fire from the affected downstream clients before any operational alert fires from the gateway. These are total or partial API traffic failures that require external monitoring of the Tyk Gateway process, Redis backend, and upstream latency metrics to catch before SLAs are breached.

Vigilmon gives you external visibility into Tyk API Gateway health through HTTP probe monitoring and heartbeat monitors for Redis connectivity, Tyk Pump health, and upstream latency tracking. This tutorial covers both.

Why Tyk API Gateway Needs External Monitoring

Tyk API Gateway failure modes have API-traffic-wide blast radius:

• Gateway process crash: The tyk Go process handles all incoming API requests; an OOM kill, panic from a nil pointer in custom middleware, or fatal plugin load failure terminates the process; systemd may restart it (if Restart=always is configured) but the restart gap causes all proxied API traffic to receive connection refused; without an external health probe, the restart may appear routine in logs but represents a brief availability gap that SLAs count
• Redis unavailability: Tyk uses Redis for API key session storage, rate limit counters, OAuth token storage, and quota tracking; when Redis becomes unreachable, Tyk cannot validate any API key sessions; depending on Tyk configuration, requests may be rejected with 401 (storage failure) or passed through without authentication (a security failure); rate limiting stops enforcing; the Redis connection pool exhaustion is a common pre-failure state that appears as increased Redis operation latency before full unavailability
• Rate limit misconfiguration causing false rejections: When rate limit policies are updated in the Tyk Dashboard and pushed to gateways, a misconfigured rate (too low) or quota (too small) causes legitimate API clients to receive 429 Too Many Requests; this is invisible unless the rate limit rejection count is monitored separately from normal 4xx errors
• Upstream latency accumulation: Tyk proxies requests to upstream services and times the upstream response; when upstream services degrade, the gateway queues requests waiting for upstream responses; if the upstream response timeout is set too high, Tyk goroutines pile up waiting for responses, consuming memory and eventually triggering OOM; monitoring p99 upstream latency through Tyk's built-in analytics catches upstream degradation before it cascades to the gateway itself
• Tyk Pump failure causing analytics blackout: Tyk records analytics events into Redis and the Tyk Pump process reads those events and writes them to storage backends (MongoDB, PostgreSQL, Elasticsearch); when Tyk Pump fails, the Redis analytics queue grows unboundedly; this eventually impacts Redis memory and then Tyk's ability to write analytics; analytics-driven rate limiting and quota enforcement also fails
• API definition staleness in Dashboard-backed mode: In Dashboard-backed deployment, Tyk Gateways poll the Dashboard for API definition updates; if the Dashboard becomes unreachable or the polling interval is too long, Gateways run with stale API configurations — a newly deployed API definition (new authentication policy, updated rate limits, new upstream URL) does not take effect until the Gateway polls successfully

External monitoring with Vigilmon adds:

• Proactive alerting when the Tyk Gateway /hello health endpoint fails (process down or unhealthy)
• Redis health tracking through the Tyk health endpoint and direct Redis probes
• Request error rate trending to catch upstream service degradations and authentication failures
• Tyk Pump health through heartbeat monitors on pump process status and queue depth

Step 1: Configure the Tyk Health Endpoint

Tyk Gateway exposes a built-in health endpoint at /hello that returns gateway status and Redis connectivity.

Verify the Built-in Tyk Health Endpoint

# Test the Tyk Gateway health endpoint (adjust port for your deployment)
curl -s http://localhost:8080/hello | jq .

# Expected healthy response:
# {
#   "status": "pass",
#   "version": "5.x.x",
#   "description": "Tyk GW",
#   "details": {
#     "redis": { "status": "pass" },
#     "dashboard": { "status": "pass" }
#   }
# }

Tyk returns HTTP 200 when healthy and HTTP 500 when Redis is unreachable or other backend dependencies are failing.

Extended Health Sidecar (Node.js)

For richer metrics including request rates and upstream latency, build an extended health sidecar that combines the Tyk /hello endpoint with Redis checks and metrics from the Tyk Gateway management API:

// health/tyk.js
const express = require('express');
const http = require('http');
const { createClient } = require('redis');

const app = express();

const TYK_GATEWAY_URL = process.env.TYK_GATEWAY_URL || 'http://localhost:8080';
const TYK_ADMIN_SECRET = process.env.TYK_GW_SECRET || 'your-gateway-secret';
const REDIS_URL = process.env.REDIS_URL || 'redis://localhost:6379';

function fetchTyk(path) {
  return new Promise((resolve, reject) => {
    const url = new URL(path, TYK_GATEWAY_URL);
    const req = http.get(url.href, {
      headers: { 'x-tyk-authorization': TYK_ADMIN_SECRET },
      timeout: 5000,
    }, res => {
      let body = '';
      res.on('data', chunk => body += chunk);
      res.on('end', () => resolve({ status: res.statusCode, body: JSON.parse(body || '{}') }));
    });
    req.on('error', reject);
    req.on('timeout', () => { req.destroy(); reject(new Error('timeout')); });
  });
}

async function checkRedis() {
  const client = createClient({ url: REDIS_URL, socket: { connectTimeout: 3000 } });
  client.on('error', () => {});
  const start = Date.now();
  await client.connect();
  await client.ping();
  const latencyMs = Date.now() - start;
  await client.disconnect();
  return latencyMs;
}

app.get('/health/tyk', async (req, res) => {
  const checks = {};
  let healthy = true;

  // Tyk Gateway /hello endpoint
  try {
    const start = Date.now();
    const { status, body } = await fetchTyk('/hello');
    checks.gateway_hello_status = status;
    checks.gateway_hello_ms = Date.now() - start;
    checks.gateway_status = body.status || 'unknown';
    checks.gateway_version = body.version || 'unknown';
    if (status !== 200 || body.status !== 'pass') {
      healthy = false;
      checks.gateway_details = body.details || {};
    }
  } catch (err) {
    checks.gateway_hello = `down: ${err.message}`;
    healthy = false;
  }

  // Direct Redis connectivity check
  try {
    const latencyMs = await checkRedis();
    checks.redis_ping_ms = latencyMs;
    checks.redis = 'ok';
    if (latencyMs > 100) {
      checks.redis_warning = `Redis ping ${latencyMs}ms (>100ms threshold)`;
    }
  } catch (err) {
    checks.redis = `down: ${err.message}`;
    healthy = false;
  }

  // Tyk Gateway metrics via management API
  try {
    const { body } = await fetchTyk('/tyk/health/?api_id=all');
    if (body && body.throttle_count !== undefined) {
      checks.rate_limit_hits = body.throttle_count;
      checks.key_failures = body.key_failures;
      checks.upstream_errors = body.upstream_errors;
    }
  } catch {
    // Management API not always available; non-fatal
  }

  return res.status(healthy ? 200 : 503).json({
    status: healthy ? 'ok' : 'degraded',
    checks,
  });
});

app.listen(3022, () => console.log('Tyk health sidecar on :3022'));

Python (FastAPI) Alternative

# health/tyk_health.py
import os
import time
import json
import httpx
import redis as redislib
from fastapi import FastAPI, Response

app = FastAPI()

TYK_GATEWAY_URL = os.environ.get("TYK_GATEWAY_URL", "http://localhost:8080")
TYK_ADMIN_SECRET = os.environ.get("TYK_GW_SECRET", "your-gateway-secret")
REDIS_URL = os.environ.get("REDIS_URL", "redis://localhost:6379")
REDIS_HOST = os.environ.get("REDIS_HOST", "localhost")
REDIS_PORT = int(os.environ.get("REDIS_PORT", "6379"))

async def check_tyk_hello() -> dict:
    async with httpx.AsyncClient(timeout=5.0) as client:
        start = time.monotonic()
        resp = await client.get(
            f"{TYK_GATEWAY_URL}/hello",
            headers={"x-tyk-authorization": TYK_ADMIN_SECRET}
        )
        elapsed_ms = int((time.monotonic() - start) * 1000)
        body = resp.json()
        return {"status": resp.status_code, "body": body, "ms": elapsed_ms}

def check_redis_direct() -> int:
    r = redislib.Redis(host=REDIS_HOST, port=REDIS_PORT, socket_connect_timeout=3)
    start = time.monotonic()
    r.ping()
    return int((time.monotonic() - start) * 1000)

@app.get("/health/tyk")
async def tyk_health():
    checks = {}
    healthy = True

    try:
        result = await check_tyk_hello()
        checks["gateway_hello_status"] = result["status"]
        checks["gateway_hello_ms"] = result["ms"]
        body = result["body"]
        checks["gateway_status"] = body.get("status", "unknown")
        checks["gateway_version"] = body.get("version", "unknown")
        if result["status"] != 200 or body.get("status") != "pass":
            healthy = False
            checks["gateway_details"] = body.get("details", {})
    except Exception as e:
        checks["gateway_hello"] = f"down: {str(e)}"
        healthy = False

    try:
        latency_ms = check_redis_direct()
        checks["redis_ping_ms"] = latency_ms
        checks["redis"] = "ok"
        if latency_ms > 100:
            checks["redis_warning"] = f"Redis ping {latency_ms}ms (>100ms)"
    except Exception as e:
        checks["redis"] = f"down: {str(e)}"
        healthy = False

    status_code = 200 if healthy else 503
    return Response(
        content=json.dumps({"status": "ok" if healthy else "degraded", "checks": checks}),
        status_code=status_code, media_type="application/json"
    )

Step 2: Configure Vigilmon Monitoring

HTTP Monitor — Tyk Gateway Built-in Health

Configure Vigilmon to probe Tyk's native health endpoint directly:

| Field | Value | |-------|-------| | Monitor name | Tyk API Gateway | | URL | http://api-gateway.internal:8080/hello | | Method | GET | | Check interval | Every 30 seconds | | Expected status | 200 | | Expected body contains | "status":"pass" | | Alert threshold | 2 consecutive failures | | Regions | Select 2+ regions for consensus |

HTTP Monitor — Extended Tyk Health Sidecar

For Redis and upstream latency checks:

| Field | Value | |-------|-------| | Monitor name | Tyk Gateway Extended Health | | URL | http://api-gateway.internal:3022/health/tyk | | Method | GET | | Check interval | Every 1 minute | | Expected status | 200 | | Alert threshold | 2 consecutive failures |

Heartbeat Monitor — Tyk Pump Health

Monitor the Tyk Pump analytics pipeline. Configure a 10-minute timeout heartbeat:

#!/bin/bash
# /etc/cron.d/tyk-pump-health — runs every 5 minutes
HEARTBEAT_URL="https://vigilmon.online/hb/your-tyk-pump-heartbeat"
MAX_QUEUE_DEPTH="${TYK_PUMP_MAX_QUEUE:-10000}"
REDIS_HOST="${REDIS_HOST:-localhost}"
REDIS_PORT="${REDIS_PORT:-6379}"

# Check Tyk Pump process is running
PUMP_PID=$(pgrep -x "tyk-pump" 2>/dev/null || echo "")
if [ -z "$PUMP_PID" ]; then
  echo "Tyk Pump process is not running" >&2
  exit 1
fi

# Check analytics queue depth in Redis (tyk-analytics-* keys)
QUEUE_DEPTH=$(redis-cli -h "$REDIS_HOST" -p "$REDIS_PORT" \
  LLEN "tyk-record-log" 2>/dev/null || echo 0)

if [ "$QUEUE_DEPTH" -lt "$MAX_QUEUE_DEPTH" ]; then
  curl -fsS --max-time 10 "$HEARTBEAT_URL" > /dev/null 2>&1
else
  echo "Tyk Pump analytics queue depth: ${QUEUE_DEPTH} (threshold: ${MAX_QUEUE_DEPTH})" >&2
fi

Configure with a 10-minute timeout (runs every 5 minutes with 5-minute slack).

Heartbeat Monitor — API Error Rate Check

Watch for sustained API error rate spikes:

#!/bin/bash
# /etc/cron.d/tyk-error-rate — runs every 5 minutes
HEARTBEAT_URL="https://vigilmon.online/hb/your-tyk-error-rate-heartbeat"
TYK_GATEWAY_URL="${TYK_GATEWAY_URL:-http://localhost:8080}"
TYK_SECRET="${TYK_GW_SECRET:-your-gateway-secret}"
MAX_ERROR_RATE=5  # percent

# Fetch Tyk health stats (requires Tyk Gateway management API)
STATS=$(curl -fsS --max-time 10 \
  -H "x-tyk-authorization: $TYK_SECRET" \
  "${TYK_GATEWAY_URL}/tyk/health/?api_id=all" 2>/dev/null)

if [ -z "$STATS" ]; then
  # Health stats unavailable but gateway may still be serving — do not alert
  curl -fsS --max-time 10 "$HEARTBEAT_URL" > /dev/null 2>&1
  exit 0
fi

# Parse error rate (simplified — adapt to your Tyk version's response format)
UPSTREAM_ERRORS=$(echo "$STATS" | python3 -c "
import sys, json
data = json.load(sys.stdin)
print(data.get('upstream_errors', 0))
" 2>/dev/null || echo 0)

if [ "$UPSTREAM_ERRORS" -lt "$MAX_ERROR_RATE" ]; then
  curl -fsS --max-time 10 "$HEARTBEAT_URL" > /dev/null 2>&1
else
  echo "Tyk upstream error rate: ${UPSTREAM_ERRORS}% (threshold: ${MAX_ERROR_RATE}%)" >&2
fi

Configure with a 10-minute timeout.

Heartbeat Monitor — API Definition Staleness

For Dashboard-backed deployments, verify API definitions are syncing:

#!/bin/bash
# /etc/cron.d/tyk-api-sync — runs every 5 minutes
HEARTBEAT_URL="https://vigilmon.online/hb/your-tyk-api-sync-heartbeat"
TYK_GATEWAY_URL="${TYK_GATEWAY_URL:-http://localhost:8080}"
TYK_SECRET="${TYK_GW_SECRET:-your-gateway-secret}"
MAX_STALE_MINUTES=10

LAST_SYNC=$(curl -fsS --max-time 10 \
  -H "x-tyk-authorization: $TYK_SECRET" \
  "${TYK_GATEWAY_URL}/tyk/apis/" 2>/dev/null | \
  python3 -c "
import sys, json
from datetime import datetime, timezone
apis = json.load(sys.stdin)
if not apis:
    print(0)
    sys.exit()
# Find most recent config hash change time if available
print(1)
" 2>/dev/null || echo 0)

# Since sync timing requires Tyk Dashboard integration, use process-level reload check
RELOAD_ERRORS=$(journalctl -u tyk --since "10 minutes ago" 2>/dev/null | \
  grep -c "reload failed\|config sync error" || echo 0)

if [ "$RELOAD_ERRORS" -eq 0 ]; then
  curl -fsS --max-time 10 "$HEARTBEAT_URL" > /dev/null 2>&1
else
  echo "Tyk config sync errors in last 10 minutes: ${RELOAD_ERRORS}" >&2
fi

Step 3: Configure Alerting

Alert Policies

Tyk Gateway Down Alert

• Trigger: /hello endpoint returns non-200 or connection refused
• Severity: Critical — P1
• Channels: PagerDuty (immediate) + Slack #api-gateway-critical
• Message: "Tyk API Gateway is unreachable. All proxied API traffic is failing. Check the tyk process status with systemctl status tyk and review logs for crash reason. Restart with systemctl restart tyk if process is terminated."

Redis Unavailability Alert

• Trigger: Health endpoint returns 503 with Redis down detail
• Severity: Critical — P1
• Channels: PagerDuty (immediate) + Slack #api-gateway-critical
• Message: "Tyk Gateway cannot reach Redis. Rate limiting, API key validation, and quota enforcement are failing. All authenticated API requests may be rejected. Restore Redis connectivity immediately — check Redis process and network path from gateway host."

Tyk Pump Down Alert

• Trigger: Pump heartbeat not received for 10 minutes
• Severity: High
• Channels: Slack #api-gateway-alerts + email to ops
• Message: "Tyk Pump process has stopped or analytics queue is backed up. API analytics data is not being written to storage backends. Rate limit enforcement based on analytics may degrade. Check systemctl status tyk-pump and Redis queue depth."

High API Error Rate Alert

• Trigger: Error rate heartbeat missed (error rate >5%)
• Severity: High
• Channels: Slack #api-gateway-alerts + email to engineering
• Message: "Tyk API Gateway error rate has exceeded threshold. Upstream services may be degraded or returning errors. Review Tyk analytics dashboard for per-API error breakdown and check upstream service health."

Authentication Failure Spike Alert

• Trigger: Health endpoint shows key_failures spiking above baseline
• Severity: Medium (Security)
• Channels: Slack #security-alerts + email to security team
• Message: "Tyk API Gateway is reporting elevated authentication failures. This may indicate credential stuffing, misconfigured API clients, or expired API keys. Review authentication error logs and consider rate limiting by source IP."

Key Metrics Summary

| Metric | Alert Threshold | Impact | |--------|----------------|--------| | Tyk Gateway process / /hello | Any failure | All proxied API traffic fails | | Redis connectivity | Any failure | API key auth fails; rate limiting disabled | | Redis ping latency | >100ms | Rate limit counter accuracy degrades | | Request error rate (4xx/5xx) | >5% sustained | API consumers receiving errors | | Rate limit rejection rate | Spike vs baseline | Legitimate clients being throttled | | Authentication failure rate | Spike vs baseline | Credential stuffing or misconfigured clients | | Upstream response latency p99 | >2 seconds | SLA breaches; goroutine buildup in gateway | | Tyk Pump process status | Down | Analytics blackout; quota enforcement degraded | | Analytics queue depth (Redis) | >10,000 records | Pump lag; potential Redis memory pressure | | API definition last sync | >10 minutes stale | New API configs not taking effect |

Conclusion

Tyk API Gateway is the authentication and rate limiting enforcement point for all API traffic flowing through your infrastructure — when the Gateway process crashes, Redis becomes unreachable, or upstream services degrade, the impact is immediate across every API consumer. Vigilmon HTTP probes on Tyk's built-in /hello endpoint catch Gateway process failures instantly, while the extended health sidecar adds Redis connectivity validation and upstream error rate visibility. Heartbeat monitors on Tyk Pump health and API definition sync give you coverage of the analytics and configuration pipeline failures that direct process monitors miss. Configure the monitors in this tutorial and your API platform team will receive alerts about Gateway problems before partner integrations and mobile clients start filing support tickets.