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

# Service status

> Read publishing health per channel, and probe whether the API is up.

Two endpoints answer health questions, and neither one needs an API key. Both are safe to poll from a monitor: they are not scoped to your account and they spend none of your [rate limit](/concepts/rate-limits).

## Publishing health per channel

`GET /v1/status` reports, for each of the 22 [channels](/concepts/channels), whether posts have been landing over the last 24 hours. It is the same data the public [status page](https://hub.madiad.com/status) renders.

```bash theme={null}
curl https://api.madiad.com/v1/status
```

```json theme={null}
{
  "status": "operational",
  "window_minutes": 1440,
  "platforms": [
    {
      "platform": "instagram",
      "display_name": "Instagram",
      "status": "operational",
      "failure_rate": 0.125,
      "sample": 8,
      "failed": 1,
      "unknown": 0,
      "platform_wide": false
    }
  ],
  "updated_at": "2026-09-06T09:31:21.227Z"
}
```

| Field                       | Meaning                                                                                            |
| --------------------------- | -------------------------------------------------------------------------------------------------- |
| `status` (top level)        | The worst per-channel verdict on the list: `operational`, `degraded` or `outage`.                  |
| `window_minutes`            | The observation window. Currently `1440`, i.e. 24 hours.                                           |
| `platform` / `display_name` | The channel slug you would put in `platforms[]`, and its human name.                               |
| `sample`                    | Publishes to that channel that reached a verdict inside the window.                                |
| `failed`                    | How many of them the channel refused.                                                              |
| `unknown`                   | Publishes whose outcome was never established. Counted as neither success nor failure.             |
| `failure_rate`              | `failed / sample`, rounded to three decimals. `null` when the sample is too small to state a rate. |
| `platform_wide`             | `true` when the channel is having a problem beyond MADIAD Hub.                                     |
| `updated_at`                | When the answer was computed.                                                                      |

Per-channel `status` has five values, and two of them are deliberately not health claims:

* **`operational`** — failures are under 25% of the sample.
* **`degraded`** — 25% or more failed.
* **`outage`** — 50% or more failed.
* **`no_activity`** — nothing was published to that channel in the window. A fact about traffic, not a verdict.
* **`monitoring`** — some publishes, but fewer than 8, which is too few for a percentage to mean anything. The counts are still shown; only the verdict is withheld.

<Note>
  These figures are an aggregate over all publishing through MADIAD Hub, with no account, profile or post identifiable in them — which is also why a channel can read `operational` here while *your* posts to it keep failing. A restriction on one connected account never moves this number. For your own results, read each post's per-channel outcome and see [Publish failures](/concepts/publish-failures).
</Note>

The answer is cached for up to a minute, so polling faster than that returns the same body.

## Is the API up?

`GET /v1/health` is a liveness probe. It reads nothing and answers immediately:

```bash theme={null}
curl https://api.madiad.com/v1/health
```

```json theme={null}
{ "ok": true, "service": "madiad-hub-gateway", "time": "2026-09-06T09:31:21.227Z" }
```

A `200` means the API is serving requests. It says nothing about whether publishing is healthy — that question belongs to `GET /v1/status`. Point uptime monitors here rather than at an authenticated route, so a probe every minute never eats into the requests your integration is allowed.