tutorial

How to Monitor Portkey with Vigilmon

How to monitor Portkey with Vigilmon — HTTP health checks on the Portkey AI gateway, LLM routing endpoints, API availability, SSL certificate monitoring, and alerting for your LLM operations infrastructure.

Portkey is the AI gateway and LLM operations platform that sits between your application and every LLM provider — OpenAI, Anthropic, Gemini, Mistral, and open-source models — handling intelligent routing, automatic fallbacks, prompt caching, request logging, cost tracking, and production observability. When the Portkey gateway goes down, every LLM call in your application either fails outright or bypasses your routing logic, losing fallback protection, cost controls, and observability in a single outage. Vigilmon gives you external uptime monitoring for Portkey — gateway API availability, control plane dashboard health, SSL certificate validity, and alerting before your LLM routing layer fails silently.

What You'll Build

  • An HTTP monitor on the Portkey gateway API endpoint to catch routing failures
  • A monitor on the Portkey control plane dashboard for web application availability
  • An SSL certificate monitor for your Portkey gateway domain
  • Alerting rules that notify your team when LLM traffic starts bypassing your routing layer

Prerequisites

  • A running Portkey deployment — cloud-hosted (https://api.portkey.ai) or self-hosted on your own infrastructure
  • The Portkey gateway endpoint network-reachable from Vigilmon probes
  • A free account at vigilmon.online

Step 1: Understand Portkey's Architecture

Portkey separates the AI gateway that proxies LLM requests from the control plane that manages configurations, logs, and analytics. The externally-critical components are:

| Component | Default path | Role | |---|---|---| | Gateway API | /v1/ | Proxies LLM requests to configured providers with routing, fallbacks, caching | | Health endpoint | /v1/health | Returns gateway liveness and readiness status | | Control plane | / | Dashboard for configs, logs, analytics, cost tracking | | Feedback API | /v1/feedback | Receives request feedback and evaluation data |

For self-hosted Portkey, the gateway and control plane run as separate services. For Portkey Cloud, both are managed at api.portkey.ai and app.portkey.ai respectively.

Step 2: Monitor the Portkey Gateway Health Endpoint

The gateway health endpoint is the fastest liveness signal — it confirms the routing engine is running and ready to proxy LLM requests:

curl -I https://api.portkey.ai/v1/health
# Returns 200 when the gateway is healthy
  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://api.portkey.ai/v1/health (or your self-hosted gateway URL + /v1/health).
  3. Check interval: 60 seconds.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: ok (Portkey health endpoint returns {"status":"ok"}).
  7. Label: Portkey gateway health.
  8. Click Save.

This monitor catches:

  • Gateway container crashes or pod evictions
  • Database connectivity failures preventing config lookups
  • Memory pressure causing gateway unresponsiveness
  • Deployment rollouts that broke the gateway binary

Alert sensitivity: Set to trigger after 1 consecutive failure. A gateway outage means every LLM call in your application loses routing, fallback, and caching simultaneously.

Step 3: Monitor the Portkey Gateway API Endpoint

The v1 API endpoint handles all production LLM proxy traffic. A check here confirms the gateway is accepting requests, not just reporting healthy:

curl -I https://api.portkey.ai/v1/
# Returns 200 or 401 (unauthorized without API key — both confirm the gateway is alive)
  1. Add Monitor → HTTP.
  2. URL: https://api.portkey.ai/v1/ (or your self-hosted gateway URL + /v1/).
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds.
  5. Expected status: 200 or 401.
  6. Label: Portkey gateway API.
  7. Click Save.

Why both monitors: The health endpoint checks internal readiness. The API endpoint checks external reachability — network policies, load balancers, and TLS termination issues can block API traffic while the health endpoint responds internally.

Step 4: Monitor the Portkey Control Plane Dashboard

The Portkey dashboard is where your team manages routing configs, reviews request logs, tracks costs, and investigates LLM failures. An HTTP check confirms the web application is serving:

curl -I https://app.portkey.ai
# Returns 200 with text/html content
  1. Add Monitor → HTTP.
  2. URL: https://app.portkey.ai (or your self-hosted control plane URL).
  3. Check interval: 2 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: Portkey (appears in the page title or HTML).
  7. Label: Portkey control plane.
  8. Click Save.

Self-hosted note: On self-hosted deployments, the control plane often shares the same ingress as the gateway. A dashboard outage may indicate problems with your ingress controller or TLS configuration affecting both services.

Step 5: Monitor SSL Certificates

Portkey's TLS certificate secures both the AI gateway and the dashboard. An expired certificate causes your application's LLM clients to raise SSL errors, stopping all AI functionality:

openssl s_client -connect api.portkey.ai:443 2>/dev/null | openssl x509 -noout -dates
  1. Add Monitor → SSL Certificate.
  2. Domain: api.portkey.ai (and separately app.portkey.ai if using Portkey Cloud or split domains on self-hosted).
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

Why SSL matters for Portkey specifically: Unlike browser apps where users see a certificate warning, an expired Portkey gateway certificate causes your server-side application code to throw SSL exceptions at every LLM call — often in production with no UI-facing error message, making root cause diagnosis slow.

Step 6: Configure Alerting

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Action | |---|---|---| | Portkey gateway health | Non-200 or keyword missing | Check gateway container; inspect routing config; review provider connectivity | | Portkey gateway API | Non-200/401 or timeout | Gateway unreachable externally; check load balancer and ingress rules | | Portkey control plane | Non-200 or timeout | Dashboard unavailable; LLM routing still works but observability is blind | | SSL certificate | < 30 days to expiry | Renew certificate; verify application SDKs reconnect cleanly after renewal |

Alert after: 1 consecutive failure for gateway monitors. 2 consecutive failures for the dashboard monitor.

Common Portkey Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Gateway container OOM killed | Health monitor fires; all LLM requests fail or hit providers directly | | Provider API key misconfiguration | Gateway API returns errors; routing to fallback providers may engage | | Database down (config store) | Gateway cannot load routing rules; health monitor fires | | SSL certificate expired | SSL monitor alerts at 30-day threshold; application LLM calls raise SSL errors | | Control plane deployment failure | Dashboard monitor fires; gateway may still route traffic | | Network policy change blocks external probe | All monitors fire; teams alerted before LLM traffic disruption | | High-throughput spike causes gateway overload | Response time increases; Vigilmon timeout alert fires | | DNS misconfiguration after migration | All monitors fire; LLM client connections rejected | | Kubernetes pod restart during peak traffic | Health monitor fires briefly; watch for repeated short outages | | Cache backend failure (Redis) | Gateway degrades gracefully but prompt cache misses spike |

Gateway Availability vs. LLM Provider Availability

Vigilmon monitors whether the Portkey gateway itself is reachable — it does not verify whether the upstream LLM providers Portkey routes to are healthy. For complete LLM observability:

  • Provider health: Portkey's dashboard shows per-provider error rates and latencies — a healthy gateway with provider errors is a provider-side incident, not a gateway incident.
  • Fallback coverage: Portkey's fallback configs should route around degraded providers automatically; Vigilmon tells you when the gateway itself is unavailable, not when a specific provider is slow.
  • Request logging gaps: If Portkey is up but your request logs show gaps, investigate cache backend connectivity and log storage separately from gateway availability.

Vigilmon catches infrastructure-level failures — gateway unreachability, certificate expiry, service crashes. End-to-end LLM request success requires monitoring Portkey's internal provider metrics alongside external uptime monitoring.

Portkey routes every LLM call your application makes, but the gateway itself needs monitoring. A Portkey outage silently removes fallback protection, cost controls, and request logging from all your LLM traffic — often without any error message visible to end users. Vigilmon checks Portkey's gateway, health endpoint, dashboard, and SSL certificate on a 60-second cycle, so you know within a minute when your LLM routing layer stops working.

Start monitoring Portkey in under 5 minutes — register free at vigilmon.online.

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