RUNTIME HQ
>_RUNTIME_HQHTTP_SERVICE_MONITORING

Know whenyour serviceschange.

Runtime HQ sends real HTTP requests to your services, records every result, and opens an incident when a healthy service starts failing.

Get startedSign in
  • HTTP GET
  • 3s timeout
  • Every 5 minutes
  • History per check
>_SERVICE_HEALTHSAMPLE_DATA · LAST_CHECK 10:35:02

  • ORDERS_API

    api.example.com/orders/health

    OPERATIONAL

    HTTP 200 · 10:35:02

    LATENCY117ms

  • PAYMENTS_API

    pay.example.com/status

    DEGRADED

    HTTP 429 · 10:35:02

    LATENCY842ms

  • AUTH_API

    auth.example.com/health

    OPERATIONAL

    HTTP 200 · 10:35:02

    LATENCY94ms

  • WEBHOOK_INGEST

    hooks.example.com/ping

    AWAITING_CHECK

    NO_CHECK_YET

    LATENCY—

>_CHECK_HISTORYSAMPLE_DATA

Checks recorded · one service · 7 days

2,016

That is 288 checks a day on a 5-minute schedule. Each one keeps its status, HTTP code and measured latency.

Configured is not the same as checked.

Adding a service does not make it healthy. Until the first check runs, Runtime HQ shows it as awaiting check. After that, health is whatever the checks returned.

NEW_SERVICEAwaiting check · 0 checks
INVENTORY_APIOperational · 1 failure recorded

INVENTORY_API · recent checks

  • 10:35:02HTTP 200 · 118ms
  • 10:30:01HTTP 200 · 124ms
  • 10:25:02HTTP 200 · 109ms
  • 10:20:01HTTP timeout · 3001ms
  • 10:15:02HTTP 200 · 121ms
>_INCIDENT_LIFECYCLEORDERS_API · SAMPLE_DATA

When a service fails, the history shows it.

Outage duration · recorded on resolve

5m 12s

  1. 09:00:03

    Service_Health

    HTTP 200 • 118ms

    Checks pass and the service is operational.

  2. 09:15:04

    Check_Fails

    HTTP timeout • 3001ms

    The state becomes outage.

  3. 09:15:04

    Incident_Opens

    CRITICAL

    Outage detected: Service unavailable. Opened automatically.

  4. 09:20:16

    Service_Recovers

    HTTP 200 • 118ms

    A later check succeeds.

  5. 09:20:16

    Incident_Resolves

    Duration 5m 12s

    Service recovered and incident automatically resolved.

>_SYSTEM_INDEX

Every check leaves a record.

MONITORING
HTTP checks · latency · status
INCIDENTS
Automatic detection · resolution · duration · manual declaration
HISTORY
Every check stored · timelines · uptime from recorded results
CONTROL
Manual checks · service registry · per-user ownership
>_READY_WHEN_YOU_ARE

Start monitoring your services.

Get startedSign in
YOUR_FIRST_SERVICEAWAITING_CHECK

Sample · the first result appears as soon as the first check runs