Services and SLOs

The service catalog is what Ops summaries and SLOs attach to. If a pager event cannot resolve to a service_id, summaries will be weaker and SLO burn will not update.

Register

POST /v1/ops/services
Authorization: Bearer eridian_sk_...

{
  "project_id": "prj_ops_001",
  "name": "payments-api",
  "slug": "payments-api",
  "tier": 1,
  "owner_desk": "payments-sre",
  "region": "eu-west-1",
  "pagerduty_service": "PAYMENTS-API"
}

{
  "id": "svc_payments_api",
  "object": "eridian.ops.service",
  "status": "active"
}

Required scope: ops:write.

SLOs

PUT /v1/ops/services/svc_payments_api/slos

{
  "availability": { "objective": 0.9995, "window_days": 30 },
  "latency_p95_ms": { "objective": 250, "window_days": 30 }
}

Eridian computes burn from the metrics connector. It does not invent uptime. If the connector is silent, slo.status is unknown, not green.

Error budget

GET /v1/ops/services/svc_payments_api/error-budget

{
  "object": "eridian.ops.error_budget",
  "remaining": 0.41,
  "burn_rate_1h": 2.4,
  "state": "alert"
}

state is healthy | alert | exhausted | unknown. Webhook: ops.slo.burn. See Ops Webhooks.

SLA credits

Eridian can compute inputs for customer SLA credits from availability SLOs:

POST /v1/ops/services/svc_payments_api/sla-credits

{
  "customer_id": "cst_bank_12",
  "window_start": "2026-08-01T00:00:00Z",
  "window_end": "2026-08-31T23:59:59Z"
}

The object is eridian.ops.sla_credit.draft. Finance and legal apply the contract. Eridian does not invoice.

Tiering

Tier 1 services should have dual control on SLO objective changes.

See Incidents and Observability for the platform metrics Eridian exposes about itself.