Incidents represent events on the platform that require a response — SLA breaches, infrastructure failures, delivery blockers, agent errors, and compliance violations. Alerts are the detection layer: they monitor signals across Service Lines and trigger incident creation or notifications when thresholds are crossed.Incidents are not the same as tasks or risks. A risk is a forward-looking signal on the Observability API. An incident is a live event requiring active resolution.
An alert is a rule that watches a metric or signal and fires an incident or sends a notification when a threshold is met. Alerts are configured per workspace or per Service Line.
{ "service_line_id": "LIN-26-084729", "type": "delivery_blocker", "severity": "p2", "title": "Blocked: awaiting client API credentials to proceed with integration", "description": "The team cannot proceed with the payments integration without the production API keys from the client. Escalation to account manager required.", "assigned_to": "USR-26-000044"}
{ "status": "resolved", "resolution_note": "SLA committed response added to the process checklist. Recurrence prevention measures in place.", "resolved_at": "2026-04-15T10:30:00Z"}
Wire critical Service Lines to P1/P2 alert rules at activation. Do not wait for an incident to discover that you have no alerting. Create alert rules when you create the Service Line.
Use incidents as the authoritative resolution record. When something goes wrong with a managed or ODS Service Line, the incident record is the audit trail. Resolution notes should be factual, not CYA prose.
Distinguish delivery blockers from infrastructure failures. They have different owners and different escalation paths. Miscategorizing an incident slows resolution.
