> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blockra.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Monitor Blockra Uptime From Your Own Tooling

> Point your uptime monitor at an endpoint that exercises the real sign-in path — GoTrue, the database and Redis — rather than a liveness ping that stays green while auth is down.

Blockra publishes its own status at [status.blockra.io](https://status.blockra.io). If you run your own monitoring — or you operate a status page that depends on Blockra — there are two endpoints worth watching.

## Liveness: `GET /health`

Public, unauthenticated, and cheap. It proves the API process is answering.

```bash theme={null}
curl https://api.blockra.io/health
```

```json 200 theme={null}
{
  "data": {
    "status": "ok",
    "redis": "up",
    "min_payment_usd": 0.1,
    "time": "2026-07-29T09:35:44.431Z"
  },
  "error": null
}
```

<Warning>
  `/health` is a **liveness** check. It stays green while the authentication backend is entirely down, because answering the request does not touch it. Do not use it as your only alert.
</Warning>

## Auth stack: `GET /monitor/auth`

This one fails when a merchant could not sign in — the thing actually worth being woken for. It exercises the same dependencies, in the same order, that authenticating a real request does:

| Check      | What it proves                                      | Fatal? |
| ---------- | --------------------------------------------------- | ------ |
| `gotrue`   | The authentication service is reachable and healthy | Yes    |
| `database` | Postgres and the data layer answer a real query     | Yes    |
| `redis`    | Token revocation and rate limiting are available    | No     |

Redis is reported but **not** fatal by design: the API deliberately fails open on it, so sign-in survives a cache outage. Paging someone for that would be a false alarm.

### Authentication

The probe is gated by a shared secret sent in the `X-Monitor-Key` header. A header rather than a query parameter on purpose — query strings end up in access logs, proxy logs and `Referer` headers, so a URL-borne secret leaks by design.

A missing or wrong key returns `404`, not `401`, so an unauthenticated scanner cannot tell the route exists.

```bash theme={null}
curl https://api.blockra.io/monitor/auth \
  -H "X-Monitor-Key: $BLOCKRA_MONITOR_KEY"
```

```json 200 theme={null}
{
  "data": {
    "status": "AUTH_OK",
    "checks": {
      "gotrue":   { "ok": true, "ms": 595 },
      "database": { "ok": true, "ms": 196 },
      "redis":    { "ok": true, "ms": 148 }
    },
    "time": "2026-07-29T09:35:44.431Z"
  },
  "error": null
}
```

When something is wrong the response is `503`, `status` becomes `AUTH_DEGRADED`, and the failing check carries a `detail` string:

```json 503 theme={null}
{
  "data": {
    "status": "AUTH_DEGRADED",
    "checks": {
      "gotrue":   { "ok": false, "ms": 5001, "detail": "GoTrue returned 503" },
      "database": { "ok": true,  "ms": 204 },
      "redis":    { "ok": true,  "ms": 151 }
    },
    "time": "2026-07-29T09:41:02.118Z"
  },
  "error": null
}
```

### Configuring your monitor

The response is shaped so the two most common alert rules both work, and either one alone is sufficient:

<Steps>
  <Step title="Add the header">
    Set a custom request header `X-Monitor-Key` to your key. Most monitors (BetterStack, Checkly, Pingdom, Uptime Robot) support custom headers on HTTP checks.
  </Step>

  <Step title="Alert on status code">
    Rule: **HTTP status other than `200`**. A degraded auth stack returns `503`; a wrong key returns `404`, which also alerts — that is deliberate, since a monitor with a stale key is not monitoring anything.
  </Step>

  <Step title="Or alert on keyword">
    Rule: **body does not contain `AUTH_OK`**. The keyword lives in its own field so a future change to the response shape cannot silently remove it.
  </Step>
</Steps>

<Note>
  The probe is side-effect free: no session is created, no row is written, no email is sent, and the database check returns a count rather than any record. Polling it every 30–60 seconds is fine.
</Note>

<Tip>
  Ask us for a monitor key at [support@blockra.io](mailto:support@blockra.io) if you need to watch Blockra from your own status page.
</Tip>