SLA Policies & Reports

Named SLA policies, per-severity targets, live tracking and exportable reports.

What an SLA policy is

A named, reusable definition of your service-level commitments: uptime percentage targets, response-time targets per incident severity, and the measurement window. Assign a policy to a status page and every monitor/incident on it is measured against the same contract — no per-monitor spreadsheets.

Creating a policy

curl -X POST https://api.shxrk.systems/api/v1/uptime/sla-policies \
  -H "Authorization: Bearer sk_shx_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "customer-facing-999",
    "uptime_target": 99.9,
    "response_targets": [
      { "severity": "critical", "response_minutes": 15 },
      { "severity": "major", "response_minutes": 60 },
      { "severity": "minor", "response_minutes": 480 }
    ]
  }'

GET /sla-policies              # list
GET/PUT/DELETE /sla-policies/:id
GET /sla-policies/export       # backup all policies as JSON/YAML
POST /sla-policies/import      # restore or copy across accounts

Assigning and tracking

PUT /status-pages/:id/sla-policy   # assign a policy to a page
GET /status-pages/:id/sla-policy   # current assignment
GET /status-pages/:id/sla          # live summary — uptime %, time-to-acknowledge vs targets
PUT /status-pages/:id/sla-targets  # per-page target overrides
GET /status-pages/:id/sla/export   # exportable SLA report

The summary compares measured uptime and incident response times against the policy — breaches show up as they happen, not at the end of the quarter.

Typical use

  • Customer contracts — attach the contracted SLA to the public status page and share periodic exports
  • Internal SLOs — a stricter internal policy on the same monitors, so you see an SLO burn before it becomes a customer-facing SLA breach
  • Multi-tenant — different customers get different policies on their own status pages while sharing monitor infrastructure
PreviousEvent Rules & Automation