On-call agents vs PagerDuty: scoremethode voor SaaS-teams

Het is 02:14 op een dinsdag. Een Stripe-webhook speelt 600 events per minuut opnieuw af tegen je API. Je twee engineers slapen — één in Utrecht, één op vakantie in Chiang Mai. Je hebt 240 alerts per maand en drie mensen die ze plausibel zouden kunnen oppakken. Je hebt ook een SOC 2 Type II-audit in november en een medeoprichter die je HN-threads blijft doorsturen over agents die om 03:00 de webserver van een klant onderuit haalden omdat niemand de prompt had gelezen.

Dit stuk is de methode die we bij ABN hanteren wanneer een Nederlandse SaaS-oprichter onder €7M ARR ons vraagt of ze de komende twaalf maanden on-call moeten uitbesteden aan een agent, een menselijk rooster, of iets daartussenin. Het is geen pleidooi voor agents. Bij twee van de laatste vier keer dat we deze scoreoefening uitvoerden, kwam het antwoord uit op: neem een derde engineer aan.

De drie vormen op tafel

Je hebt grofweg drie opties. De meeste artikelen zetten ze ideologisch tegenover elkaar; dat hoeft niet.

Vorm A — pure agent. Een door Claude aangedreven worker die abonneert op je alert-pipeline. Hij leest de alert, draait read-only diagnostiek, classificeert, probeert de fix uit een runbook en pagineert pas een mens bij escalatie. De mens slaapt by design.

Vorm B — driepersoonsrooster. De klassieker. PagerDuty (of Grafana OnCall, of Opsgenie) pagineert een mens, de mens draait de runbook uit zijn hoofd plus een terminal. Geen agent in de loop.

Vorm C — agent-first met menselijke goedkeuring. De agent doet de diagnose en stelt de fix voor. Een mens keurt het destructieve deel goed (de restart, de rollback, de WAF-regel). Als geen mens binnen vier minuten ACK't, houdt de agent vast of escaleert, afhankelijk van de klasse incident.

Oprichters willen één antwoord. Wij scoren de drie in plaats daarvan langs drie assen.

Drie assen die echt tellen voor SaaS onder €7M

We negeren vanity metrics: MTTR-distributies die je niet kunt berekenen, 'incident velocity', alles dat eindigt op 'score'. Voor een Nederlandse SaaS onder €7M zijn drie dingen doorslaggevend.

1. MTTA per incident, gewogen

Mean Time To Acknowledge: het gat tussen de alert die afgaat en een mens of agent die zegt 'ik heb 'm'. De referentiedefinitie van PagerDuty is degene die de meeste auditors hanteren.

De weging is belangrijk. Een MTTA van 90 seconden op een 'queue depth op 80%' is irrelevant; een MTTA van 90 seconden op 'payments geven 500' is misschien €30k waard. Wij wegen elke alert-klasse met wat je per minuut niet-geacknowledgde tijd kost. Ruwweg:

ALERT_WEIGHTS = {
    "payments_5xx": 800,        # €/min — Mollie, Stripe, Adyen failures
    "auth_500":      300,
    "search_down":   120,
    "queue_depth":    10,
    "disk_warn":       5,
}

def weighted_mtta(incidents):
    total_cost = sum(
        i.mtta_seconds / 60 * ALERT_WEIGHTS[i.class_]
        for i in incidents
    )
    return total_cost / len(incidents)

Vul je laatste 90 dagen in. Komt het antwoord onder €40 uit, dan heb je geen on-call probleem; dan heb je een CFO die metrics uit context leest. Komt het boven €400 uit, dan heb je er een, ongeacht welke vorm je kiest.

2. Post-mortem-verdedigbaarheid voor een SOC 2-auditor

Dit is de as die oprichters vergeten tot juli van het auditjaar. Je auditor gaat vragen, bij elk incident dat klantdata raakt: wie heeft gedetecteerd, wie heeft gediagnosticeerd, wie heeft de fixende actie besloten, en waar zit het spoor. De AICPA Trust Services Criteria zijn niet specifiek over de vraag of 'wie' een mens moet zijn — CC7.3 gaat over het response-proces, niet over de soort responder — maar auditors zijn conservatief, en het vendor-risk team van je klant is nóg conservatiever.

De verdedigbaarheidsvraag reduceert tot één ding: kun je, zes maanden later, een complete keten van alert → diagnose → beslissing → actie → verificatie tonen? Een puur menselijk rooster produceert dit spoor per ongeluk in Slack. Een puur-agent setup produceert een veel beter spoor, mits je het instrumenteert. Een hybride produceert het schoonste spoor van de drie, omdat de menselijke goedkeuringsstap een letterlijk vastgelegde beslissing is met een naam eraan.

3. Wie bezit de runbook als de agent loopt op een feestdag

Elke agent doet ooit met overtuiging het verkeerde. De onze ook. De eerlijke ontwerpvraag is niet 'gaat de agent falen' maar 'wat gebeurt er als hij faalt op 26 december om 14:00 terwijl je enige on-call persoon aan een lange lunch met haar schoonfamilie zit.'

In een puur menselijk rooster is dit niet aan de orde — de mens is de loop. In een puur-agent setup is een onbeheerde loop het ergste failure mode dat je hebt, want de agent blijft acties nemen en credibility (en geld) verbranden sneller dan een vermoeide mens zou doen. In een hybride is de gate het antwoord, maar alleen als de gate een harde timeout heeft en een fallback-eigenaar die niet de agent zelf is.

De drie vormen gescoord

Zo scoren de drie opties in de praktijk, met de caveats die we steeds in productie tegenkomen. Wij hebben veertien agents live; vier daarvan raken op een of andere manier on-call werk.

Vorm A: pure agent

MTTA: op papier het beste. Wij zien de gewogen MTTA met 60–80% dalen ten opzichte van een slapende mens, omdat de agent in ongeveer zes seconden ACK't.

SOC 2-verdedigbaarheid: goed als je elke tool-call, prompt, modelversie en beslissing naar onveranderlijke opslag logt en je ze bewaart voor het auditvenster. Slecht als je 'gewoon de API gebruikt en het later wel uitzoekt'. De auditor wil een afspeelbaar spoor; dat bouw je nu, of je bouwt het onder een deadline.

Feestdagloop-eigenaarschap: hier vallen pure agents om in echte trajecten. Er zit geen mens in de loop, dus de failure mode is dat de agent een uur lang stil productie-state staat te slopen terwijl het kantoor bij Sinterklaas zit. Pure agent is alleen verdedigbaar voor read-only en notify-only acties. Zodra je runbook productie-state raakt, wil je een gate.

Vorm B: driepersoonsrooster

MTTA: gemiddeld het slechtst — vier tot elf minuten voor een middernachtelijke melding is gangbaar, langer als de on-call persoon een baby heeft. Maar de lange staart is korter, omdat mensen ambiguïteit beter triageren dan de huidige modellen.

SOC 2-verdedigbaarheid: prima, met discipline. Het spoor leeft in Slack en de PagerDuty-tijdlijn, beide accepteren auditors zonder commentaar.

Feestdagloop-eigenaarschap: dit is de hele clou van het model. De mens is de loop. De kost is menselijke kost — een driepersoonsrooster met een eerlijke vergoeding in NL is grofweg €18k/jaar aan alleen on-call premie, plus de stille belasting van twee mensen die met hun telefoon naar boven slapen.

Vorm C: hybride, agent-first met goedkeuringsgate

MTTA: bijna net zo goed als pure agent voor de ack, iets slechter voor actietijd omdat de menselijke goedkeuring op het kritieke pad zit.

SOC 2-verdedigbaarheid: het beste van de drie. Elk incident heeft een machine-gegenereerde diagnose, een door een mens vastgelegde beslissing, en een geautomatiseerde actie met een hash van de goedkeuring. Auditors merken het op; we hebben een senior van een Big Four-kantoor zien pauzeren om de oprichter te vertellen dat het de schoonste IR-log was die hij in het traject had gezien.

Feestdagloop-eigenaarschap: werkt alleen als de geen-goedkeuring-tak escaleert naar een tweede mens, niet naar de agent. Dit is de belangrijkste ontwerpbeslissing in het hybride model.

De beslisregel die we daadwerkelijk hanteren

Na een dozijn van deze reviews komt de regel neer op vier vragen. Beantwoord ze op volgorde.

1. Raakt meer dan 30% van je alerts productie-state? Zo nee, ship een pure agent; de upside is reëel en de downside is begrensd. Zo ja, ga verder.
2. Heb je SOC 2 (of zit je in een sales cycle die het vereist)? Zo ja, sla pure agent over. Kies rooster of hybride.
3. Zit je gewogen MTTA-kost boven €200? Zo ja, dan wint hybride op verwachte waarde. Zo nee, dan is een rooster prima en waarschijnlijk goedkoper dan de engineering-tijd om de agent te bouwen.
4. Heb je twee mensen die om 02:00 betrouwbaar binnen vier minuten ACK'en? Zo nee, dan heb je geen rooster; dan heb je één persoon en een fictie. Hybride is dan het enige eerlijke antwoord.

Meer niet. Het raamwerk draait in vijf minuten op een whiteboard.

Een minimale hybride loop, in code

Voor oprichters die uitkomen op Vorm C en willen zien hoe een 'goedkeuringsgate' er in de praktijk uitziet: de loop is korter dan mensen verwachten. Hieronder de vorm die wij als startpunt gebruiken, gestript tot de essentie en zonder de vendor-specifieke details.

import anthropic

client = anthropic.Anthropic()
APPROVAL_TIMEOUT_S = 240  # 4 minutes

def handle_alert(alert):
    diagnosis = client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=1024,
        tools=READ_ONLY_TOOLS,   # logs, metrics, traces — never writes
        messages=[{"role": "user", "content": render(alert)}],
    )

    if diagnosis.proposed_action is None:
        return notify_humans(diagnosis, severity="info")

    request_id = post_to_slack_with_buttons(
        channel="#oncall-gate",
        diagnosis=diagnosis,
        actions=["approve", "deny", "page_human"],
    )

    decision = wait_for_decision(request_id, timeout=APPROVAL_TIMEOUT_S)

    if decision == "approve":
        execute(diagnosis.proposed_action, audit_trail=diagnosis.trace_id)
    elif decision == "timeout":
        page_secondary_oncall(alert, diagnosis)   # never let the agent decide here
    else:
        log_denied(diagnosis, decision)

Drie details tellen zwaarder dan de rest van de code. De tools van de agent zijn read-only op het moment van diagnose, dus het worst case vóór goedkeuring is een verkeerde aanbeveling, geen verkeerde actie. Het Slack-bericht bevat de volledige voorgestelde actie en de modelversie, zodat de goedkeurder precies weet waar hij voor tekent. De timeout-tak pagineert een mens; hij valt nooit terug op autonome uitvoering. Verander je één van deze drie, dan heb je geen Vorm C meer — dan heb je Vorm A in een kostuum.

Wat we hebben geleerd door deze te bouwen

Twee dingen hebben ons verrast in de trajecten waar we de hybride versie bouwden.

Het eerste is dat de menselijke goedkeuringsratio stabiliseert rond 92–96% nadat de runbook een maand is aangescherpt. Engineers die het project sceptisch begonnen, keuren uiteindelijk bijna elk eerste voorstel van de agent goed. Dat is het moment om je gate dubbel te checken. Hoge goedkeuringsratio's zijn geen signaal dat je de mens kunt weghalen; ze zijn een signaal dat de mens nu stempelt, wat een ander SOC 2-probleem is en een ander post-mortem-verhaal.

Het tweede is dat de runbook zelf het artefact wordt dat ertoe doet. De agent dwingt je om op te schrijven wat je daadwerkelijk om 03:00 doet, en dat document — niet de agent — blijkt uiteindelijk de meest waardevolle output van het project. Oprichters die naast de runbook ook een rooster opzetten, zagen hun menselijke MTTA óók verbeteren, omdat het rooster nu uit dezelfde bron las als de agent.

Toen we eerder dit jaar de on-call hybride bouwden voor een Rotterdams payments-SaaS, liepen we ertegenaan dat hun alert-pipeline geen concept van 'klasse' kende — elke alert had dezelfde severity, waardoor de gewogen MTTA-oefening onmogelijk was tot we er een classifier voor zetten. We hebben het uiteindelijk opgelost door elke alert door een kleine AI-agent te routeren die labelt en weegt voordat er iets anders afgaat.

Het vijfminuten-ding om vandaag te doen

Open je incident tracker, neem de laatste 60 alerts, en label elk met een euro-kost per minuut van niet-geacknowledged zijn. Lukt het niet, dan is je probleem niet de on-call vorm — dan is het dat je nog niet weet wat je alerts waard zijn. Fix dat eerst, kom dan terug naar dit stuk.