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

# Uptime monitoring

> Monitor Signa from your own observability stack via /v1/health and /health/ready

Two unauthenticated health endpoints let you monitor Signa from your own observability stack -- useful for SLA reporting, status-page integration, and incident triage across multiple vendors.

## What to probe

| Endpoint            | Probe interval | What it tells you                                                                                                           |
| ------------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------- |
| `GET /v1/health`    | 60s            | API process is up. Returns HTTP 200 and `{"status":"ok"}`.                                                                  |
| `GET /health/ready` | 60s            | API plus Postgres, Valkey, and OpenSearch all reachable. Returns `degraded` for non-critical-dep outages, 503 for critical. |

Both endpoints are unauthenticated -- no API key required for your monitoring agent.

## Datadog Synthetics

```yaml theme={null}
type: api
name: Signa API readiness
config:
  request:
    method: GET
    url: https://api.signa.so/health/ready
  assertions:
    - type: statusCode
      operator: is
      target: 200
    - type: body
      operator: validatesJSONPath
      target:
        jsonPath: "$.status"
        targetValue: ok
        operator: is
locations:
  - aws:us-east-1
  - aws:eu-west-1
options:
  tick_every: 60
  retry:
    count: 1
    interval: 30000
```

Set the alert threshold to **2 consecutive failures** to filter out the inevitable cross-region network blip.

## Pingdom / StatusCake / cron

```bash theme={null}
#!/usr/bin/env bash
set -e
RESPONSE=$(curl -fsS --max-time 5 https://api.signa.so/health/ready)
STATUS=$(echo "$RESPONSE" | jq -r '.status')
if [ "$STATUS" = "ok" ] || [ "$STATUS" = "degraded" ]; then
  exit 0
fi
echo "Signa API ${STATUS}: ${RESPONSE}" >&2
exit 1
```

Run on a 60-second schedule. Treat `degraded` as a warning rather than a page -- non-critical dependency outages don't break most calls.

## What these endpoints don't cover

`/health/ready` is API-side health only. It does not surface:

* **Ingestion freshness.** Office connectors that fall behind don't flip the API to `degraded`. If you watch a specific office and alerts stop firing, check the [diagnostics endpoint](/api-reference/monitoring/watches/diagnostics) -- `last_relevant_sync_run.completed_at` will be stale.
* **Webhook delivery.** That's between Signa and your receiver. Cross-check [`GET /v1/webhooks/{id}/deliveries`](/api-reference/monitoring/webhooks/list-deliveries) for the delivery audit log.
* **Monitoring evaluator lag.** A backlog in the monitoring service looks healthy via `/health/ready`. Same fix -- the diagnostics endpoint surfaces `lease_state` and the sync timeline.

If `/health/ready` is green but you suspect a Signa-side issue, follow the [troubleshooting guide](/guides/monitoring/troubleshooting).

## Status page integration

Signa does not currently publish a public status page -- the health endpoints above are the canonical machine-readable signal, and incident questions go to [support@signa.so](mailto:support@signa.so). If you maintain your own status page, surface readiness for Core API health and the diagnostics-derived freshness signal for office ingestion separately -- they cover different incident classes.