Livelli di escalation in sequenza
Aggiungi tutti i livelli che servono al tuo team. Ogni livello ha i propri destinatari e il proprio timeout. La policy avanza automaticamente se la presa in carico non arriva in tempo.
Policy di escalation
Continua a scalare finché
Continua a scalare finché
qualcuno risponde.
Definisci policy passo dopo passo che avvisano la persona A, attendono, poi avvisano la persona B o chi è reperibile in quel momento, finché qualcuno prende in carico. Policy per servizio, con timeout configurabili a ogni livello.
Free tier included
No credit card
2-minute setup
Un alert che non si arrende.
Gli alert critici non si fermano dopo un tentativo. Una policy di escalation percorre i suoi livelli con metodo. Avvisa ogni destinatario, attende un timeout configurabile e poi passa oltre, finché l'incidente non viene preso in carico o la policy ricomincia.
Timeout per livello
Imposta la finestra di presa in carico per ogni livello, da 1 minuto a 24 ore: 5 minuti all'ingegnere reperibile, poi 10 minuti al team lead, poi all'engineering manager.
Persone o turni come destinatari
Punta ogni livello a persone specifiche, a turni di reperibilità o a entrambi. Quando il destinatario è un turno, viene avvisata la persona reperibile in quel momento secondo il turno, chiunque sia.
Ripetizione automatica
Configura un numero di ripetizioni, fino a 20, così l'intera policy ricomincia se tutti i livelli si esauriscono senza presa in carico.
Assegnazione per servizio
Ogni servizio del catalogo può avere una policy di escalation. Gli incidenti del servizio pagamenti avvisano i reperibili dei pagamenti; quelli della piattaforma avvisano il team piattaforma.
Stato di presa in carico sull'incidente
L'incidente mostra se è stato preso in carico o risolto. Uno storico dell'escalation per livello oggi non è disponibile.
Niente sfugge
Passo dopo passo finché
Passo dopo passo finché
qualcuno risponde.
La maggior parte degli strumenti di alerting invia una sola notifica e si ferma. Le policy di escalation sono diverse: in assenza di risposta avanzano automaticamente tra i livelli, finché l'incidente non viene preso in carico o si raggiunge il limite di ripetizioni configurato.
- Passa al livello successivo dopo un timeout senza presa in carico
- Punta ai turni di reperibilità, così nessun nome è scritto a mano
- Ripete l'intera policy se tutti i livelli restano senza presa in carico
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: manager (pending)20ms
Per servizio, definite nel tuo repo
Una policy per servizio,
Una policy per servizio,
creata via API.
Assegna una policy di escalation a ogni servizio del catalogo e creale tutte tramite la REST API: prima la policy, poi ogni livello con timeout e destinatari. Metti le chiamate in uno script nel tuo repo e le pull request mostrano esattamente quale instradamento è cambiato.
- Ogni servizio punta alla policy da usare
- Policy e livelli creati tramite la REST API
- Le modifiche hanno effetto subito; nessun riavvio necessario
create an escalation policy$ curl -X POST https://api.siteqwality.com/escalation_policy \
-H "Authorization: Bearer $SQ_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"Payments SLA Policy","repeat_count":2}'
$ curl -X POST https://api.siteqwality.com/escalation_policy/$POLICY_ID/level \
-H "Authorization: Bearer $SQ_TOKEN" \
-H "Content-Type: application/json" \
-d '{"timeout_minutes":5,"target_schedule_ids":["$PAYMENTS_ONCALL"]}'
$ curl -X POST https://api.siteqwality.com/escalation_policy/$POLICY_ID/level \
-H "Authorization: Bearer $SQ_TOKEN" \
-H "Content-Type: application/json" \
-d '{"timeout_minutes":10,"target_user_ids":["$PAYMENTS_LEAD"]}'
-H "Authorization: Bearer $SQ_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"Payments SLA Policy","repeat_count":2}'
$ curl -X POST https://api.siteqwality.com/escalation_policy/$POLICY_ID/level \
-H "Authorization: Bearer $SQ_TOKEN" \
-H "Content-Type: application/json" \
-d '{"timeout_minutes":5,"target_schedule_ids":["$PAYMENTS_ONCALL"]}'
$ curl -X POST https://api.siteqwality.com/escalation_policy/$POLICY_ID/level \
-H "Authorization: Bearer $SQ_TOKEN" \
-H "Content-Type: application/json" \
-d '{"timeout_minutes":10,"target_user_ids":["$PAYMENTS_LEAD"]}'
N+1
livelli per policy, quanti ne servono al tuo team
20
ripetizioni massime dell'intera policy, se nessuno prende in carico
1m
timeout minimo configurabile tra livelli di escalation
$0
policy di escalation in ogni piano; il piano gratuito include 1 persona reperibile
FAQ
Non c'è un limite fisso al numero di livelli. In pratica la maggior parte dei team usa da due a quattro livelli (ingegnere reperibile, team lead, poi un manager), ma puoi aggiungerne quanti ne richiedono le tue esigenze operative.
Se la policy ha un numero di ripetizioni maggiore di zero, ricomincia dal livello uno e ripercorre i livelli. Continua finché non si raggiunge il limite di ripetizioni (al massimo 20) o qualcuno prende in carico l'incidente.
Sì, ed è l'approccio consigliato. Punta un livello a un turno di reperibilità e Site Qwality determina chi è reperibile nel momento in cui il livello scatta. Quando le rotazioni cambiano non devi aggiornare la policy.
L'escalation rispetta le regole di notifica personali di ogni membro del team, che usano email, SMS o un messaggio diretto Slack. Se una persona ha impostato SMS per gli incidenti ad alta urgenza ed email per quelli a bassa urgenza, la policy di escalation rispetta questa preferenza. Un messaggio diretto Slack richiede un token del bot Slack incollato nel metodo di contatto.
Sì. Ogni servizio del catalogo può puntare alla propria policy di escalation. I pagamenti possono avere una policy stretta, uno strumento interno una più rilassata. Le modifiche hanno effetto subito.
Related features
Inizia gratis. Nessuna carta di credito.
Uptime, cron, synthetic, log, RUM, incidenti e pagine di stato. Piano gratuito su ogni prodotto.