Skip to main content

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.

​
Why monitor Signa from outside

Signa runs its own internal availability monitoring (ALB health checks, Datadog dashboards, PagerDuty), but enterprise customers often need their own signal — for SLA reporting, customer status pages, and “is-it-them-or-us” debugging during multi-vendor incidents. The /v1/health and /health/ready endpoints are designed for exactly this.

​
What to monitor

EndpointProbe intervalWhat it tells you
GET /v1/health60sAPI process is up (HTTP 200, body {"status":"ok"}).
GET /health/ready60sAPI + Postgres + Valkey + OpenSearch all reachable. Returns degraded for non-critical-dep outages, 503 for critical.
Both endpoints are unauthenticated — you don’t need to provision an API key for your monitoring agent.

​
Recipe — Datadog Synthetics

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  # 30s — avoid double-alerting on a transient blip
Set the alert threshold to 2 consecutive failures to filter out the inevitable cross-region network blip. Signa’s own SLO is 99.9% monthly, so 1 minute of red on a 60s probe is well inside the budget.

​
Recipe — Pingdom / StatusCake / DIY cron

For simpler monitoring tools or your own cron: 
#!/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 60s schedule. Treat degraded as a warning (paging is overkill — non-critical dep outages don’t break most calls).

​
What the endpoints DON’T cover

/health/ready is API-side health. 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 notice alerts stop firing, check the diagnostics endpoint — last_relevant_sync_run.completed_at will be stale.
  • Webhook delivery. That’s between Signa’s dispatcher and your receiver. Cross-check GET /v1/webhooks//deliveries for delivery status.
  • Watch evaluator lag. A backlog in the evaluator looks healthy via /health/ready even though no alerts are firing. Same fix: diagnostics surfaces lease_state and the sync_run timeline.
If /health/ready is green but you suspect a Signa-side issue, follow the troubleshooting guide.

​
Status page integration

Signa’s own status page lives at https://status.signa.so. For status-page aggregators (Statuspage.io component status), wire the API readiness probe to a “Core API” component and the diagnostics-derived freshness signal to an “Office Ingestion” component. The two surface different incident classes — coupling them obscures which side is impaired.