# Status and monitoring

> Check whether LayerHop is up at status.layerhop.com or with GET /v1/status — current status of the API, checkout, worker, dashboard and every liquidity provider, 90 days of uptime, and recent incidents.

Source: https://docs.layerhop.com/guides/status-and-monitoring

LayerHop's status page at [status.layerhop.com](https://status.layerhop.com) shows whether each part of LayerHop is working right now, its uptime over the last 90 days, and incidents from the last 14 days. The same data is public JSON at `GET https://api.layerhop.com/v1/status`, so you can show it in your own app or alert on it. Every component is checked every minute (liquidity providers every 5 minutes), and LayerHop's team is alerted as soon as something breaks.

## What is monitored?

| Component | Group | How it is checked |
|---|---|---|
| `api`: API | Core | `GET https://api.layerhop.com/v1/health` answers `2xx` |
| `web`: Swap app & website | Core | `https://layerhop.com/` answers `2xx` |
| `worker`: Order tracking & webhooks | Core | The worker's heartbeat. It tracks orders and checkout payments and delivers webhooks; it counts as down when its heartbeat is older than 3 minutes |
| `checkout`: Checkout & payment buttons | Payments | `https://layerhop.com/checkout.js` answers `2xx` |
| `dashboard`: Developer dashboard | Developer tools | `https://dashboard.layerhop.com/` answers `2xx` |
| `docs`: Documentation | Developer tools | `https://docs.layerhop.com/` answers `2xx` |
| `mcp`: MCP server | Developer tools | `https://mcp.layerhop.com/healthz` answers `2xx` |
| `bot`: Telegram bot | Developer tools | `https://bot.layerhop.com/healthz` answers `2xx` |
| `provider:jupiter`, `provider:relay`, `provider:debridge`, `provider:lifi`, `provider:zerox`, `provider:kyberswap` | Liquidity providers | Every 5 minutes LayerHop quotes three sample routes through its public API; a provider is up when it returned a quote |

HTTP probes time out after 10 seconds. Check history is kept for 90 days.

## Incidents and alerts

Two consecutive failed checks of a component open an **incident**: the component shows as `down` on the status page and the incident is listed with its start time. The LayerHop team is alerted at once by email and Telegram. The first successful check after that resolves the incident and sends a recovery alert.

A component whose latest check failed but has no open incident shows as `degraded`. Because a stopped worker cannot report itself, the API watches the worker's heartbeat independently and opens (and alerts on) the worker incident on its own.

When the worker is down, quotes, transactions and checkout pages still work, but order status updates, `paid` checkout sessions and webhook deliveries are delayed. Nothing is lost: when the worker recovers it catches up on every order and session, and pending webhook deliveries are retried as usual (see [Webhooks](/guides/webhooks#how-do-retries-work)).

## GET /v1/status

`GET https://api.layerhop.com/v1/status` needs no key, allows any origin (CORS), and is cached for 30 seconds.

```bash
curl https://api.layerhop.com/v1/status
```

```json
{
  "status": "operational",
  "updatedAt": "2026-10-18T09:00:12.000Z",
  "components": [
    {
      "id": "api",
      "name": "API",
      "group": "Core",
      "status": "operational",
      "latencyMs": 84,
      "uptime90d": 99.98,
      "days": [
        { "date": "2026-07-21", "uptime": null },
        { "date": "2026-10-18", "uptime": 100 }
      ]
    }
  ],
  "incidents": [
    {
      "id": "inc_01k7…",
      "componentId": "provider:lifi",
      "component": "LI.FI",
      "title": "LI.FI is unavailable",
      "startedAt": "2026-10-16T22:10:00.000Z",
      "resolvedAt": "2026-10-16T22:25:00.000Z"
    }
  ],
  "url": "https://layerhop.com/status"
}
```

| Field | Meaning |
|---|---|
| `status` | Overall: `operational` (everything up), `degraded` (some component's latest check failed) or `outage` (at least one component is down). |
| `components[].status` | `operational`, `degraded` (latest check failed) or `down` (open incident). |
| `components[].latencyMs` | Response time of the latest check in the last 15 minutes, or `null`. |
| `components[].uptime90d` | Percentage of successful checks over 90 days (two decimals), or `null` without checks. |
| `components[].days` | 90 entries, oldest first: each day's uptime percentage, or `null` for days without checks. |
| `incidents` | Incidents started in the last 14 days, newest first (at most 50). `resolvedAt` is `null` while ongoing. |
| `url` | The human-readable status page. |

With the SDKs: `await lh.serviceStatus()` (TypeScript), `lh.service_status()` ([Python](/sdks/python)), `c.ServiceStatus(ctx)` ([Go](/sdks/go)) and `lh.service_status().await` ([Rust](/sdks/rust)).

## Using it in your integration

- Show a banner when `status` is not `operational`, or when the components you depend on (for example `checkout` and `worker` for payments, or one provider) are not.
- Poll at most every 30 seconds; responses are cached for that long.
- A provider being `down` does not mean swaps fail: LayerHop [compares every provider](/concepts/meta-aggregation) and routes through the others.
- To be told about delays in order tracking, alert on the `worker` component.

Questions about an incident: dev@layerhop.com.