Livelli di escalation sequenziali
Aggiungi tutti i livelli di cui il tuo team ha bisogno. Ogni livello ha i propri destinatari e finestra di timeout. La policy avanza automaticamente quando un riconoscimento non viene ricevuto in tempo.
Policy di escalation
Continua a escalare finché
Continua a escalare finché
qualcuno risponde.
Definisci policy step-by-step che notificano prima la persona A, aspettano, poi notificano la persona B, poi l'intero team — finché qualcuno riconosce. Policy per servizio, multi-canale, con timeout configurabili a ogni livello.
Free tier included
No credit card
2-minute setup
payments-svc policy EscalatingLIVE
CURRENT LEVEL2 of 3
TIMEOUT5 min
ACKNOWLEDGEDNo
Level 1 — On-call (notified)100ms
Level 2 — Lead (notifying)80ms
Level 3 — Whole team60ms
Repeat 1×40ms
—8ms
Cosa ottieni
Un alert che non si arrende.
Gli alert critici non si fermano dopo un solo tentativo. Una policy di escalation avanza attraverso i suoi livelli in modo metodico — notificando ogni destinatario, aspettando un timeout configurabile, poi passando avanti — finché l'incidente viene riconosciuto o la policy si ripete.
Controllo del timeout per livello
Imposta la finestra di riconoscimento in modo indipendente per ogni livello — 5 minuti per l'ingegnere di reperibilità, poi 10 minuti per il team lead, poi pagina immediata all'intero team.
Destinatari: utenti o calendari
Punta qualsiasi livello su una persona specifica o su un calendario di reperibilità. Quando viene puntato un calendario, viene cercato il responsabile di reperibilità corrente per quel calendario — chiunque sia in quel momento.
Re-escalation automatica
Configura un contatore di ripetizioni così l'intera policy riparte se tutti i livelli si esauriscono senza riconoscimento. Gli alert critici continuano a ciclare finché qualcuno risponde.
Assegnazione per servizio
Ogni servizio nel tuo catalogo ha la propria policy di escalation. Gli alert dei pagamenti vengono instradati alla reperibilità dei pagamenti; gli alert della piattaforma al team di piattaforma. Nessun routing manuale.
Visibilità sullo stato dell'escalation
Vedi esattamente dove si trova un'escalation attiva — quale livello ha scattato, chi è stato notificato, chi ha riconosciuto e quanto tempo ha richiesto ogni step — in tempo reale sul registro dell'incidente.
01 · Nulla cade tra le crepe
Step dopo step finché
Step dopo step finché
qualcuno risponde.
La maggior parte degli strumenti di alerting invia una singola notifica e la considera finita. Le policy di escalation sono diverse: avanzano automaticamente attraverso i livelli, tenendo conto del silenzio, finché l'incidente viene riconosciuto — o finché viene raggiunto il limite di ripetizioni configurato.
- Avanza al livello successivo dopo un timeout non riconosciuto
- Punta i calendari di reperibilità così nessun nome è mai codificato a mano
- Ripete l'intera policy se tutti i livelli si esauriscono senza riconoscimento
payments-svc policy Level 2 ActiveLIVE
LEVEL 1 TIMEOUT5m — elapsed
LEVEL 2 TIMEOUT10m — running
INCIDENTS THIS WEEK3
L1 — on-call paged100ms
L1 — timeout elapsed85ms
L2 — lead paged70ms
L2 — awaiting ack50ms
L3 — team (pending)20ms
02 · Per servizio, definito nel tuo repo
Una policy per servizio,
Una policy per servizio,
provisioning via API.
Assegna una policy di escalation diversa a ogni servizio nel tuo catalogo e fai il provisioning di tutte tramite la REST API. Inserisci le chiamate in uno script nel tuo repo e le pull request ti mostrano esattamente quali servizi hanno cambiato il loro routing — nessuna sorpresa durante un incidente.
- Ogni servizio ha la propria policy — nessun default condiviso
- Policy create e versionate tramite REST API
- Le modifiche hanno effetto immediato; nessun riavvio richiesto
create an escalation policy$ curl -X POST https://api.siteqwality.com/escalation_policy/ \
-H "Authorization: Bearer $SQ_TOKEN" \
-d '{"name":"Payments SLA Policy","repeat":2,"levels":[{"timeout_minutes":5,"target":"schedule:payments-oncall"},{"timeout_minutes":10,"target":"user:payments-lead"},{"timeout_minutes":5,"target":"team:payments"}]}'
-H "Authorization: Bearer $SQ_TOKEN" \
-d '{"name":"Payments SLA Policy","repeat":2,"levels":[{"timeout_minutes":5,"target":"schedule:payments-oncall"},{"timeout_minutes":10,"target":"user:payments-lead"},{"timeout_minutes":5,"target":"team:payments"}]}'
N+1
livelli per policy — quanti ne ha bisogno il tuo team
0
alert persi — la policy si ripete finché non viene riconosciuta
5m
timeout minimo configurabile tra i livelli di escalation
$0
piano gratuito — policy di escalation incluse dall'inizio
FAQ
Questions, answered.
Non c'è un limite massimo al numero di livelli. In pratica, la maggior parte dei team usa da due a quattro livelli — ingegnere di reperibilità, team lead, poi l'intero team — ma puoi aggiungerne quanti ne richiedono i tuoi requisiti operativi.
Se una policy è configurata con un contatore di ripetizioni maggiore di zero, riparte dal livello uno e scorre di nuovo attraverso i livelli. Questo continua finché viene raggiunto il limite di ripetizioni o qualcuno riconosce l'incidente.
Sì — e questo è l'approccio consigliato. Punta un livello su un calendario di reperibilità e Site Qwality determina chi è attualmente in reperibilità nel momento in cui il livello scatta. Non dovrai mai aggiornare la policy quando cambiano le rotazioni.
L'escalation rispetta le regole di notifica personali di ogni membro del team. Se un responsabile ha configurato SMS per alert urgenti e Slack per quelli a bassa urgenza, quella preferenza viene rispettata quando la policy di escalation lo cerca.
Sì — questo è esattamente lo scopo. A ogni servizio nel tuo catalogo viene assegnata la propria policy di escalation. I pagamenti possono avere una policy SLA rigida; uno strumento interno può averne una rilassata. Le modifiche sono per servizio e hanno effetto immediato.
More of the platform
Explore the rest of the platform
Pronto?
Inizia a monitorare in meno di un minuto.
Ogni prodotto parte gratuitamente — uptime, cron, synthetic, log, RUM, incidenti e pagine di stato. Nessuna carta di credito richiesta.