Home / Blog / Runbook-gids

Operaties

Wat is een runbook en hoe schrijf je er een die je team echt gebruikt?

Een runbook is een stap-voor-stapgids voor een terugkerende taak of incident. Ontdek het verschil met een SOP, wat erin hoort en hoe je het bruikbaar houdt.

5 oktober 2026 · 6 min lezen

Het is twee uur 's nachts, er is iets kapot en de enige die de oplossing kent zit in een vliegtuig. Of het nu gaat om een mislukte betaalrun, een dode server of een vastgelopen bestelwachtrij: het komende uur hangt af van één ding. Staat de kennis op papier, of alleen in iemands hoofd? Een runbook is de manier om het op te schrijven. Deze gids legt uit wat een runbook is, hoe het verschilt van een SOP en hoe je er een schrijft die mensen echt openen als ze onder druk staan.

Wat is een runbook?

Een runbook is een korte, praktische gids voor een specifieke situatie: een terugkerende taak, een bekende storing of een incident. Het vertelt wie dienst heeft wat de situatie heeft veroorzaakt, wie ervoor verantwoordelijk is, wat precies te doen, hoe je terugdraait als het erger wordt en wie je belt. De test voor een goed runbook is eenvoudig: kan een bekwame collega die deze taak nog nooit heeft gedaan het 's nachts alleen volgen, zonder jou te bellen?

Runbook of SOP: wat is het verschil?

De twee overlappen en veel teams gebruiken de woorden door elkaar. Een bruikbaar onderscheid:

• Een SOP (standaardwerkwijze) beschrijft hoe routinewerk altijd moet gebeuren, zoals een leverancier opvoeren of de maand afsluiten. Het draait om consistentie en naleving, en je leest het meestal vooraf.
• Een runbook beschrijft hoe je op een bepaalde gebeurtenis reageert of een specifieke operationele taak uitvoert, vaak onder tijdsdruk. Het draait om snelheid en veiligheid, en je leest het op het moment zelf.

Een SOP mag uitgebreid en een tikje formeel zijn. Een runbook moet recht voor zijn raap zijn: korte zinnen, exacte commando's, geen achtergrondessays. Verwijs vanuit het runbook naar de SOP als iemand het “waarom” nodig heeft.

Wanneer schrijf je een runbook?

Je kunt niet alles vastleggen, dus begin waar het pijn doet. Schrijf een runbook wanneer:

• een taak vaak terugkomt en fouten duur zijn, zoals de maandelijkse salarisexport of een release.
• een incident twee keer is voorgekomen. De tweede keer is het signaal.
• maar één persoon weet hoe iets moet. Dat is een risico, geen pluspunt.
• een taak zeldzaam maar kritiek is, zoals terugzetten vanuit een back-up. Niemand onthoudt zeldzame procedures.
• nieuwe collega's steeds dezelfde vragen stellen.

Wat hoort er in een runbook?

Houd in elk runbook dezelfde vijf onderdelen aan, zodat iedereen altijd weet waar hij moet kijken.

• Trigger. Wanneer je dit runbook gebruikt: de melding, het symptoom of de datum in de agenda. “Foutpercentage in de checkout boven 5% gedurende tien minuten” is een trigger. “Als het er slecht uitziet” niet.
• Eigenaar. Eén genoemde persoon of rol die het actueel houdt, plus de datum van de laatste controle.
• Stappen. Een genummerde lijst, één handeling per stap, in de juiste volgorde, elk met het verwachte resultaat zodat de lezer weet dat het gelukt is.
• Rollback. Hoe je terugkeert naar de vorige toestand als een stap mislukt of het erger maakt. Schrijf dit voordat je het nodig hebt.
• Escalatie. Wie je contacteert als de stappen het niet oplossen, in welke volgorde, hoe en na hoeveel minuten proberen.

Hoe schrijf je stappen die mensen volgen?

Eén handeling per stap

“Herstart de service en controleer de logs” zijn twee stappen. Splits ze, zodat iemand onder stress niet de helft overslaat.

Wees exact

Geef het echte commando, het precieze menupad of de werkelijke link. “Open het beheerpaneel” dwingt tot raden. Om twee uur 's nachts wint kopiëren en plakken het van interpreteren.

Beschrijf hoe succes eruitziet

Schrijf na elke belangrijke stap wat de lezer hoort te zien: “De statuspagina toont Actief.” Zo niet, dan weet hij dat hij moet stoppen en escaleren in plaats van blind door te gaan.

Een kort voorbeeld

Hier de opzet van een runbook voor een vastgelopen bestelwachtrij:

• Trigger: meer dan 50 bestellingen wachten langer dan 15 minuten.
• Eigenaar: de operationsmanager; laatst gecontroleerd in september.
• Stappen: statuspagina van de betaalprovider controleren; de queue-worker herstarten; bevestigen dat het aantal wachtende bestellingen binnen vijf minuten daalt.
• Rollback: als de herstart dubbele bestellingen maakt, de worker pauzeren en de handleiding voor het opschonen van dubbelen volgen.
• Escalatie: beweegt de wachtrij na 20 minuten niet, bel dan de piketingenieur en daarna de directeur operations.

Hoe test je een runbook?

Een ongetest runbook is een gok. Geef het aan iemand die het niet heeft geschreven en laat die het volgen, bij voorkeur in een veilige omgeving of tijdens een oefening, terwijl jij zwijgend toekijkt. Elke plek waar die persoon aarzelt, een vraag stelt of improviseert is een gat dat je moet dichten. Doe deze oefeningen een of twee keer per jaar voor kritieke runbooks. Stel na elk echt incident nog een vraag in de evaluatie: heeft het runbook geholpen, en wat had het beter gemaakt?

Hoe houd je een runbook actueel?

• Geef elk runbook een eigenaar en een controledatum. Per kwartaal voor kritieke, twee keer per jaar voor de rest.
• Werk het bij na elk gebruik. Wie het net heeft gevolgd weet het best wat er niet klopte of ontbrak, dus maak het herstellen onderdeel van het afsluiten van het incident.
• Koppel het aan verandering. Verandert een systeem, hulpmiddel of leverancier, zet het bijwerken van de bijbehorende runbooks dan op dezelfde checklist.
• Houd het vindbaar. Een perfect runbook in een vergeten map is nutteloos. Bewaar ze op één plek, met duidelijke namen, en waar mogelijk gelinkt vanuit de melding zelf.

Waar bewaar je je runbooks?

Een gedeeld document of wiki is genoeg om te beginnen. Belangrijker dan het hulpmiddel is dat runbooks dicht bij het werk liggen. Als je je operatie, taken en KPI's al volgt in FulcrumGrid Command Center, kun je elk runbook koppelen aan het project of de meetwaarde die het beschermt en controledata net als elke andere taak aan eigenaren toewijzen, zodat ze niet ongemerkt verlopen. Begin echter met wat je team echt zal openen.

Kies het incident dat vorig kwartaal het meeste pijn deed, schrijf deze week het runbook en test het met iemand nieuws. Eén goed runbook doet meer voor je team dan een map vol ongetesten.

Veelgestelde vragen

Is een runbook hetzelfde als een playbook?

De termen overlappen. Veel teams gebruiken een runbook voor exacte, stapsgewijze technische of operationele handelingen en een playbook voor bredere strategie, zoals het aanpakken van een groot incident of een klantescalatie, dat naar meerdere runbooks kan verwijzen.

Hoe lang moet een runbook zijn?

Zo kort mogelijk, bij voorkeur een of twee pagina's. Heb je meer nodig, splits het dan in kleinere runbooks of verwijs naar achtergrondmateriaal in plaats van de stappen te begraven.

Wie moet het runbook schrijven?

Wie de taak nu uitvoert, moet het concept schrijven, want die kent de details. Daarna moet iemand die het nooit heeft gedaan het testen en bijwerken, want die ziet de ontbrekende aannames.

Hoe vaak moeten runbooks worden herzien?

Controleer kritieke runbooks elk kwartaal en de rest twee keer per jaar. Werk elk runbook direct bij na gebruik bij een echt incident of wanneer het systeem dat het dekt verandert.

← Terug naar de blog