# Status (https://upapi.io/docs/platform/status)



## Status page [#status-page]

[app.upapi.io/status](https://app.upapi.io/status) shows the current health of
every component the gateway depends on — the execution engine, the operation
catalog, the datastore and the cache.

## Status endpoint [#status-endpoint]

[`GET /api/status`](https://app.upapi.io/api/status) returns the same report as
JSON, uncached.

```bash
curl -i https://app.upapi.io/api/status
```

It needs no authentication.

<Callout title="The status code is the signal">
  `/api/status` answers **200 only when everything is operational**. Any degraded component or
  outage returns **503**. You can therefore point an uptime monitor at the URL and let it treat the
  HTTP status as the verdict, without parsing the body.
</Callout>

That behaviour is intentional and worth relying on: it exists because an outage
where the catalog silently emptied returned a cheerful 200 for hours. A partial
degradation is a real failure, so it is reported as one.

The endpoint is designed never to throw. If the health checks themselves cannot
run, it reports everything as down rather than returning a 500 — the safe
direction to fail for a monitor.

## When something is wrong [#when-something-is-wrong]

Failures at the gateway carry an `x-request-id` on the response. Include it when
you [get in touch](https://upapi.io/docs/platform/support) — it identifies your exact call.

If the status page is green but your calls are failing, the code in the
[error envelope](https://upapi.io/docs/errors) tells you which layer to look at: `UPSTREAM_*`
means the third-party service an operation wraps, not the platform.