Incident Severity Classification with Escalation Logic
Operations teams need to auto-classify incidents and escalate critical issues immediately while avoiding alert fatigue.
El problema
Incident metadata is evaluated by Corules to determine severity and escalation path. P1 incidents auto-page the VP of Engineering. P2 triggers on-call. P3 and below create tickets without paging. Severity is computed dynamically based on current system state — a payment system impact is always P1 regardless of user count. Every classification decision is logged.
Cómo lo resuelve Corules
ESCALATE: system_impacted 'payment-service' is in critical_systems. Auto-classified P1. Paging VP Engineering.
Ejemplo de política
// Incident severity policy (CEL)
context.system_impacted in params.critical_systems
? "P1"
: context.users_affected >= params.p1_user_threshold
? "P1"
: context.users_affected >= params.p2_user_threshold
? "P2"
: "P3"Opciones de integración
REST APISlack
Frequently Asked Questions
Can the critical systems list be updated without deploying code?
Yes. params.critical_systems is a tenant-configurable parameter. Operations teams update it via the admin console without touching policy logic.