Status Page

Overview

The status page provides a public-facing view of your OpenPay deployment's health. It monitors all core services and displays their current status, response latency, and last check time.

Accessing the Status Page

# Local development
open http://localhost:3000/status

# Production (via Docker)
open http://your-domain.com/status

# Via API (JSON response)
curl http://localhost:3000/api/health

How It Works

The status page uses a server-side API route to check each service. This architecture avoids CORS issues that would occur with direct browser-to-service requests.

Browser (localhost:3000)
    ↓ fetch /api/health
Next.js Server (no CORS restrictions)
    ↓ fetch http://localhost:8081/health
    ↓ fetch http://localhost:8082/1.0/healthcheck
    ↓ fetch http://localhost:8222/healthz
    ↓ fetch http://localhost:8084/health
JSON Response → Browser
    ↓
Display status + latency for each service

Request Flow

1. Browser loads /status page
2. Page calls /api/health endpoint
3. Server-side route fetches each service's health endpoint
4. Server returns JSON with status (up/down) and latency for each service
5. Browser displays the results with color-coded indicators
6. Process repeats every 30 seconds via polling

Monitored Services

The status page monitors the following core services:

Status Indicators

Configuration

Health check URLs are configurable via environment variables. This allows you to point the status page to services running in different locations.

Environment Variables

Local Development

The default values work for local Docker development. No changes needed.

# No changes needed for local development
# Defaults are set in the API route

Production (Docker)

For production deployments, update the URLs to use Docker service names or external addresses:

# Production configuration
HEALTH_CHECK_HYPERSWITCH_URL=http://hyperswitch:8080/health
HEALTH_CHECK_KILLBILL_URL=http://killbill:8080/1.0/healthcheck
HEALTH_CHECK_NATS_URL=http://nats:8222/healthz
HEALTH_CHECK_TAZAMA_URL=http://tazama-rule-exec:8080/health

Production (External Services)

If services run on separate servers, use their external addresses:

# External services configuration
HEALTH_CHECK_HYPERSWITCH_URL=https://payments.yourdomain.com/health
HEALTH_CHECK_KILLBILL_URL=https://billing.yourdomain.com/1.0/healthcheck
HEALTH_CHECK_NATS_URL=https://messaging.yourdomain.com/healthz
HEALTH_CHECK_TAZAMA_URL=https://fraud.yourdomain.com/health

API Response Format

The /api/health endpoint returns a JSON response with the status of all services:

{
  "services": [
    {
      "name": "Hyperswitch (Payments API)",
      "status": "up",
      "latency": 286
    },
    {
      "name": "Kill Bill (Subscriptions)",
      "status": "up",
      "latency": 330
    },
    {
      "name": "NATS JetStream",
      "status": "up",
      "latency": 272
    },
    {
      "name": "Tazama (Fraud Detection)",
      "status": "up",
      "latency": 272
    }
  ],
  "lastChecked": "2026-08-05T21:07:21.904Z"
}

Response Fields

Source Code

The status page implementation consists of two main files:

Troubleshooting

• Service shows "Down" but is actually runningCheck if the health endpoint URL is correct. Verify the service is accessible from the Next.js server by running curl http://localhost:8081/health.
• Health checks time outThe default timeout is 5 seconds per service. If services are slow to respond, they may be marked as down. Check service logs for performance issues.
• All services show "Checking..." indefinitelyThe API route may be hanging. Check the Next.js server logs. Try restarting the dev server with npx next dev.
• Latency shows 0msThis typically means the service is unreachable and the request failed immediately. Check network connectivity and service status.

Related Documentation

• Monitoring & Grafana Dashboards — Advanced monitoring with Prometheus and Grafana
• Environment Variables — Complete list of configuration options
• Troubleshooting — Common issues and solutions