Incidents & Maintenance

Manual and automatic incidents, updates, severity and maintenance windows.

Incidents

Incidents communicate outages on your status page. They can be created two ways:

  • Manually — POST /incidents or the dashboard incident form
  • Automatically — a monitor with auto_create_incident opens an incident when it goes down; auto_publish_incident publishes it immediately
curl -X POST https://api.shxrk.systems/api/v1/uptime/incidents \
  -H "Authorization: Bearer sk_shx_..." \
  -H "Content-Type: application/json" \
  -d '{
    "status_page_id": "<status_page_uuid>",
    "title": "Elevated API latency",
    "description": "We are seeing increased response times on the API.",
    "severity": "major",
    "status": "investigating",
    "is_public": true,
    "monitor_ids": ["<monitor_uuid>"]
  }'

Severity: minor major critical. Status flow: investigating → identified → monitoring → resolved.

Timeline updates

Keep subscribers informed as you work:

curl -X POST https://api.shxrk.systems/api/v1/uptime/incidents/<id>/updates \
  -H "Authorization: Bearer sk_shx_..." \
  -H "Content-Type: application/json" \
  -d '{ "status": "identified", "message": "Root cause identified: connection pool exhaustion." }'

Publishing controls visibility: POST /incidents/:id/publish and /unpublish toggle whether the incident appears on the public page.

Incident templates

Reusable templates per status page (/status-pages/:id/incident-templates) so recurring incidents take seconds to post — title, body, severity and an initial update prefilled:

curl -X POST https://api.shxrk.systems/api/v1/uptime/status-pages/<id>/incident-templates \
  -H "Authorization: Bearer sk_shx_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "database-outage",
    "title": "Database connectivity issues",
    "severity": "major",
    "status": "investigating",
    "initial_update": "We are investigating elevated error rates on the database.",
    "is_public": true
  }'

Maintenance windows

Scheduled maintenance silences alerts and marks monitors as under maintenance on the status page:

curl -X POST https://api.shxrk.systems/api/v1/uptime/maintenance \
  -H "Authorization: Bearer sk_shx_..." \
  -H "Content-Type: application/json" \
  -d '{
    "status_page_id": "<uuid>",
    "title": "Database migration",
    "description": "Primary DB failover for schema migration",
    "start_time": "2025-02-01T02:00:00Z",
    "end_time": "2025-02-01T04:00:00Z",
    "is_public": true,
    "targets": [{ "target_type": "monitor", "target_id": "<monitor_uuid>" }],
    "recurrence_type": "none"
  }'

Recurring windows: recurrence_type = daily/weekly/monthly, plus recurrence_interval, recurrence_end_date, recurrence_day_of_week/recurrence_day_of_month. Post progress with POST /maintenance/:id/updates (status, message).

Event rules

Event rules (/status-pages/:id/events/rules) trigger custom logic on lifecycle events — e.g. opening an incident from a template or notifying a channel when a specific monitor goes down. Emitted events land in the event log (/status-pages/:id/events/log), and your own systems can emit custom events:

curl -X POST https://api.shxrk.systems/api/v1/uptime/status-pages/<id>/events/emit \
  -H "Authorization: Bearer sk_shx_..." \
  -H "Content-Type: application/json" \
  -d '{
    "event_name": "deploy.started",
    "classification": "public",
    "title": "Deploy v2.4.1",
    "description": "Rolling deploy started",
    "monitor_id": "<monitor_uuid>",
    "payload": "{\"version\":\"2.4.1\"}"
  }'
PreviousStatus PagesNextAgents