# Status & uptime

> The public status page shows live status, incident history and 90-day uptime for the web app, the API and scheduled jobs & webhooks.

Source: https://developers.processcart.com/status

The public status page is **[status.processcart.com](https://status.processcart.com)**. It shows live status, the incident history and 90-day uptime for each component:

| Component | What it covers | How it is checked |
| --- | --- | --- |
| **Web app** | `app.processcart.com` — the member app, guest pages and kickoff forms | An HTTPS check of the app, continuously |
| **API** | `/api/v1` | `GET /api/v1/health` — the unauthenticated probe that reports `ok` (200) or `degraded` (503) |
| **Scheduled jobs & webhooks** | The background workers that deliver webhooks, send email and run the due-date scanner | A heartbeat the due-date scanner sends on every run |

An incident is opened when a monitor fails and closed with a note when it is resolved; the history stays on the page.

## Reading an incident from your side

- A failing `GET /v1/health` (503 `degraded`) means the database did not answer in time. Until it recovers, a request that needs it answers 503 `unavailable` with `Retry-After` when the connection is refused or dropped — or, when the database stalls rather than refusing, may take long enough to time out. Retry with backoff; a 503 is never stored for idempotent replay, so retrying with the same `Idempotency-Key` re-executes.
- Webhook deliveries that fail during an incident on your side are retried on the published schedule ([Webhooks](https://developers.processcart.com/webhooks)); an incident on our side delays dispatch but loses no delivery — the outbox is durable.
- Every response carries `X-Request-Id`; quote it when reporting a problem.