Uptime and support

Live status, 90-day uptime per component and recent incidents are on the status page. The same data is available as JSON at https://developers.listener.com/status.json, so you can feed it into your own monitoring.

A monitor running on separate infrastructure from the API checks every component once a minute. The API runs on its own servers; the monitor runs as a scheduled job on a different hosting provider, so an API outage is recorded instead of silencing the monitor. Every check uses public endpoints only: no credentials, no writes, nothing that touches your data.

A check that fails is retried once, a few seconds later, before it counts. A response slower than 4 seconds counts as degraded, as does a background worker (webhook delivery, the change poller) that is restarting or has fallen behind.

• Uptime for a day is the share of that day’s checks that were not down. Degraded checks count as up. Days are UTC.
• The 90-day uptime next to each component is the same ratio over every check in the window. Days before monitoring started show as no data and are not counted.
• An incident opens automatically after two failed checks in a row and starts at the first of them. It closes at the first good check. A single failed check lowers that day’s uptime but does not open an incident.
• The current status of a component changes only while an incident is open, so one dropped check does not show as an outage.

Our target for the REST API is 99.9% uptime per calendar month, measured as above (about 43 minutes of downtime in a 30-day month).

GET https://developers.listener.com/status.json needs no authentication and is cached for up to 30 seconds.

{
  "object": "status",
  "overall": "operational",
  "last_checked_at": "2026-10-16T14:02:00.000Z",
  "stale": false,
  "check_interval_seconds": 60,
  "day_boundary": "UTC",
  "components": [
    {
      "id": "api",
      "name": "REST API",
      "status": "operational",
      "uptime_90d_percent": 99.98,
      "days": [
        { "date": "2026-10-16", "status": "operational", "uptime_percent": 100, "checks": 842, "down_checks": 0, "degraded_checks": 0 }
      ]
    }
  ],
  "incidents": [
    {
      "component": "api",
      "status": "down",
      "state": "resolved",
      "started_at": "2026-10-09T03:14:00.000Z",
      "resolved_at": "2026-10-09T03:18:00.000Z",
      "duration_seconds": 240,
      "summary": "REST API was unavailable (HTTP 502)."
    }
  ]
}

• Retry with backoff. Treat 5xx responses and timeouts as temporary. Send an Idempotency-Key on writes so a retry never applies twice (see Idempotency).
• Webhooks catch up. Deliveries that fail while we are down are retried for up to three days (see Retries & auto-disable), and the Events API lets you list anything you missed.
• Check the status page before debugging your integration. If it shows everything operational and you still see errors, contact us.

Email tech@listener.com with the request_id from the error, the method and path, and roughly when it happened. See Support for what else to include and how to report a security issue.

• Checks run from one region (US East), so a network problem between you and the API in another region may not show up.
• Checks prove each component is reachable and answering correctly; they do not exercise every endpoint or your workspace’s data.
• The status page and status.json are hosted separately from the API. If they cannot be reached, GET https://api.listener.com/health still answers.