En alarm skal ende hos en ansvarlig
Når en kritisk tjeneste fejler, er det ikke nok, at en besked lander i en fælles kanal. Der skal være en ansvarlig på vagt, en vej videre ved manglende svar og et fælles billede af, hvad der er sket. Vagt- og hændelsesstyring forbinder disse dele, så teamet kan reagere og lære af forløbet.
Guiden sammenligner incident.io, PagerDuty og Rootly til danske drifts- og udviklingsteams. Den handler om at fordele og håndtere hændelser. Selve opdagelsen behandles i guiden om oppetidsovervågning, mens statussider handler om at informere berørte brugere.
Kort fortalt
- incident.io: Undersøg det, hvis hændelsesarbejdet skal foregå tæt på Slack eller Teams, med mulighed for særskilt on-call.
- PagerDuty: Undersøg det, hvis tjenester, vagtplaner og eskalering skal samles, og I vil sammenligne enkel Incident Management med platformspakker.
- Rootly: Undersøg det, hvis vagtstyring og samarbejde under hændelser skal kunne købes som separate produkter.
Sammenligning
Stryg tabellen til siden for at se alle kolonner.
| Platform | Dokumenteret opdeling | Købsgrænse | Prøve, der bør bestå |
|---|---|---|---|
| incident.io | Incident Response og on-call, også separat on-call | Flere teams og avancerede processer ændrer pakke | Ferieafløser modtager den rette alarm |
| PagerDuty | Incident Management og PD Reliability Platform | Brugerlicenser er ikke samme model som seats, events og AI-handlinger | Manglende kvittering eskalerer korrekt |
| Rootly | Incident Response, On-Call og AI SRE | AI SRE kræver Incident Response | Gentagne alarmer bevarer et forståeligt hændelsesforløb |
On-call betyder her den tekniske vagtordning. At købe et værktøj etablerer ikke i sig selv bemanding eller en aftale om responstid.
incident.io
incident.io beskriver hændelseshåndtering i Slack og Microsoft Teams. Basic omfatter vagt for ét team, mens Team beskriver flere teams og on-call som et pristillæg. Pro tilføjer blandt andet mere tilpassede efterbehandlingsforløb og private hændelser. On-call kan også købes separat og beskrives med routing, gruppering, vagtplaner og afløsninger. Planer
Vores vurdering: Afprøv incident.io, når samarbejdet i chat er centralt. Opret en testhændelse, tildel en ansvarlig og kontrollér overdragelsen til næste vagt. Test også den aftalte reservevej, hvis chat ikke er tilgængelig. En platform med chatintegration bør ikke efterlade teamet uden en kendt kontaktvej, når selve chatmiljøet er problemet.
PagerDuty
PagerDutys aktuelle prisside viser både Incident Management og PD Reliability Platform. Gratis Incident Management er begrænset til fem brugere, én vagtplan og én eskaleringspolitik med begrænsede notifikationer. Platformspakkerne kombinerer seats, Signal Intelligence Events og AI-handlinger med mulighed for ekstra kreditter. Det er forskellige prisgrundlag, som ikke bør sammenlignes som én pris pr. medarbejder. Planer og kapacitet
Vores vurdering: Tag PagerDuty med, hvis flere tjenester skal have tydeligt ejerskab og kontrolleret eskalering. Bed leverandøren beregne både en normal måned og en periode med mange indgående events. Lad den første testvagt undlade at kvittere, og kontrollér, at næste person får besked med den nødvendige kontekst. Få samtidig afklaret, hvilke tillæg tilbuddet omfatter.
Rootly
Rootly beskriver Incident Response og On-Call som selvstændige produkter. On-Call omfatter blandt andet alarmgruppering, rotationer og vagtskift, mens Incident Response omfatter samarbejde, tidslinjer og efterbehandling. AI SRE kræver Incident Response. Enterprise beskriver yderligere administrationsfunktioner som SCIM, auditlogs og tilpasset dataopbevaring. Produktpakker
Vores vurdering: Undersøg Rootly, når I vil adskille køb af vagtfunktion fra organisering af hændelsesarbejdet. Afprøv en serie ens alarmer og derefter en lignende alarm fra en anden tjeneste. Bed om at se, hvorfor de samles eller holdes adskilt. Automatisk gruppering skal hjælpe den ansvarlige uden at skjule en selvstændig fejl.
En kontrolleret vagtprøve
Aftal et testvindue og brug en særskilt testtjeneste med deltagere, der kender øvelsen. Prøven skal ikke skabe kundealarmer eller rigtige driftsændringer. Gennemfør en alarm, en manglende kvittering, en eskalering og en normalisering. Notér tidspunkter og modtagere for hvert trin.
Gentag omkring et vagtskifte, og prøv en midlertidig afløser. Kontrollér tidszone og en dato omkring skift mellem sommer- og vintertid i den viste plan. Se efter huller og overlap. Den ansvarlige skal kunne afgøre, hvem der har vagten, uden at regne ud fra et skærmbillede i en anden tidszone.
Lad derefter to personer samarbejde om hændelsen. Én leder arbejdet; den anden registrerer beslutninger og næste opdatering. Kontrollér, om hændelsen stadig kan forstås efter afslutningen, og om handlinger fra efterbehandlingen får en ejer. En automatisk opsummering skal kontrolleres mod de faktiske observationer, før den bruges som forklaring på årsagen.
Køb efter jeres vagtmodel
Lav en liste over responders, øvrige læsere, teams, tjenester, alarmkilder og kommunikationskanaler. Få skriftlig afklaring af, hvem der kræver licens, og hvordan SMS, opkald, events, historik og ekstra produkter indgår. Afklar også eksport af vagtplaner og hændelser ved et senere skifte.
Definér, hvilke alarmer der skal vække nogen, og hvilke der kan vente til næste arbejdsdag. Et værktøj kan følge reglerne, men kan ikke beslutte virksomhedens prioriteringer eller skabe en bemandet reservevagt. Brug prøvens observerede forløb som acceptkriterium i købet.
Metode og kilder
Primærkilderne er kontrolleret 15. oktober 2026. Vi har ikke fastslået prissidernes oprindelige publiceringsdatoer. Leverandørerne står alfabetisk og er udvalgt for at belyse forskellige pakke- og arbejdsformer. Vurderinger og øvelser er redaktionelle forslag. Vi har ikke udført produkttest eller verificeret faktisk alarmlevering, dansk support, tilbud eller kommercielle relationer.