Stel: het is 3 uur 's nachts. Je slaapt lekker, maar op kantoorterrein loopt er een kritieke server plat.
▶Inhoudsopgave
Geen mens is er. Niemand pikt op. De eerste melding komt binnen om 03:17, maar pas om 03:52 ziet iemand het — een collega die toevallig nog even in Slack meekijkt. Twee uur verloren. Twee uur waarin klanten klachten indienen en omzet verdwijnt.
Dit scenario klinkt misschien dramatisch, maar het gebeurt elke week bij bedrijven die nog steeds op zoek moeten naar wie er nu precies aan de beurt is.
Een on-call schema voorkomt precijs dit soort situaties. En als je dat schema vervolgens koppelt aan je ticketsysteem, escalaties verdwijnen niet meer in een zwart gat.
Wat is een on-call schema precies?
Een on-call schema — soms ook wel pikchema of standby-rooster genoemd — is een roulatieroster waarbij teamleden om de beurt beschikbaar zijn voor incidenten buiten kantoortijd. Niet 24/7, maar verdeeld over weken of dagen, zodat altijd precies één persoon (of een klein team) de verantwoordelijkheid draagt.
Het verschil met gewoon "even je mail checken in het weekend" is enorm. Een goed on-call schema bevat duidelijke afspraken: Zonder deze afspraken draait alles op informeel vertrouwen. En informeel vertrouwen werkt niet om drie uur 's nachts.
- Wie is aan de beurt — en wie is de backup als die persoon niet bereikbaar is
- Wanneer de dienst start en eindigt (bijvoorbeeld van vrijdag 18:00 tot maandag 08:00)
- Welke kanalen gebruikt worden voor contact (telefoon, Slack, PagerDuty, GSM-nummer)
- Wat de responstijd moet zijn — bijvoorbeeld binnen 10 minuten reageren op P1-incidenten
- Welke escalatiestappen gelden als de eerste persoon niet reageert
Waarom een on-call schema alleen niet genoeg is
Hier begint het interessante. Veel teams hebben een rooster.
Soms in Excel, soms in een Google Sheet, soms gewoon in een vast patroon dat iedereen "uit hoofd" kent. Maar als er dan een incident binnenkomt in je ticketsysteem — denk aan Jira Service Management, Freshservice, Zendesk of TOPdesk — dan staat daar vaak niets over wie er aan de beurt is. Het gevolg? Iemand maakt een ticket aan.
Het ticket landt in een wachtrij. Niemand weet dat Jan het deze week heeft.
Hoe werkt die koppeling in de praktijk?
Jan krijgt geen melding. Het ticket staat een uur onbehandeld.
De klant belt opnieuw. Chaos. Het koppelen van je on-call schema aan je ticketsysteem lost dit probleem op. Het zorgt ervoor dat een inkomend ticket automatisch naar de juiste persoon geroute wordt — op basis van het actieve rooster, het type incident en de ernst, waarbij een goede shift handover met ticketnotes essentieel is voor de continuïteit.
- Trigger: Een nieuw ticket binnenkomt met een bepaalde prioriteit (bijvoorbeeld P1 of P2)
- Routing: De tool controleert het actieve rooster en stuurt een notificatie naar de juiste persoon
- Escalatie: Als de eerste persoon niet reageert binnen de gestelde tijd (vaak 5 tot 15 minuten), schakelt het automatisch door naar de backup persoon of naar een teamlead
Moderne on-call tools zoals PagerDuty, Opsgenie van Atlassian of Splunk On-Call (voorheen VictorOps) kunnen rechtstreeks integreren met ticketsystemen. Je stelt een rooster in, bepaalt escalatieregels en de tool wijst automatisch de juiste on-call persoon toe aan een nieuw incident, wat helpt om echte ticket ownership te bevorderen.
De meeste integraties werken in drie lagen: Tools zoals Jira Service Management hebben zelfs ingebouwde on-call functionaliteit via de integratie met Opsgenie. Dat betekent dat je niet eens een apart systeem nodig heeft — je rooster, je escalaties en je tickets leven in dezelfde omgeving.
De escalatieregels: waar veel teams het fout doen
Een veelgemaakte fout is het opstellen van escalatieregels die te simpel zijn. "Als Jan niet reageert, bel dan Marie" — prima, maar wat als Marie op vakantie is?
Wat als het een P1-incident is en je eigenlijk een architect nodig hebt die de architectuur kent?
- Laag 1: On-call engineer reageert binnen 10 minuten
- Laag 2: Backup engineer wordt gebeld na 10 minuten geen reactie
- Laag 3: Teamlead of engineering manager wordt geïnformeerd na 20 minuten
- Laag 4: Bij P1: direct CTO- of directeurnotificatie, ongeacht reactietijd
Sterkere escalatieregels werken met lagen: Deze lagen programmeer je in je on-call tool. Het systeem werkt ze af, automatisch.
Rotatie en overbelasting: houd rekening met je mensen
Geen mens hoeft na te denken wie er gebeld moet worden — het is geregeld voordat het incident optreedt. Een on-call schema is geen excuus om één persoon permanent op te zadelen. Goede praktijken: Uit onderzoek van Incident.io en PagerDuty's State of Digital Operations rapport blijkt dat teams met een gekoppeld on-call- en escalatiesysteem gemiddeld 50 tot 70 procent sneller reageren op kritieke incidenten dan teams die dit handmatig regelen.
- Maximaal 1 op de 4 tot 5 weken on-call voor dezelfde persoon
- Compensatietijd of vergoeding na een nachtelijk incident
- Oefenincidenten (chaos engineering) zodat maken dat on-call ervaringen minder schrikbarend worden
- Runbooks bij elk kritiek systeem, zodat de persoon aan de beurt niet hoeft te gissen
Aan de slag: je eerste gekoppelde opstelling
Wil je vandaag nog starten? Dit is een simpel stappenplan:
- Documenteer je huidige rooster — ook als het "informeel" is. Maak het expliciet.
- Kies een on-call tool die integreert met je ticketsysteem. Opsgenie voor Jira-gebruikers, PagerDady voor multi-tool omgevingen.
- Definieer je escalatielagen en leg ze vast in de tool.
- Test het. Maak een testincident aan en kijk of de notificatie bij de juiste persoon aankomt. Doe dit minstens één keer per maand.
- Herhaal en verbeter. Na elk incident: wat ging er goed bij escalatie, wat niet? Pas je regels aan.
Een on-call schema is geen bureaucratische exercitie. Het is de laatste verdedigingslijn tegen het scenario van 3 uur 's nachts waar niemand op pikt.
Koppel het aan je ticketsysteem, automatiseer de escalaties, en gebruik gestroomlijnde onboarding procedures zodat jouw team — en jouw klanten — erop kunnen vertrouwen dat er altijd iemand paraat is.