SLO's voor interne tools, eenvoudig uitgelegd: stel meetbare uptime- en latencydoelen in en koppel ze aan alerts die een klein team kan onderhouden zonder burn-out.
Interne tools voelen klein omdat het publiek klein is. De impact is dat vaak niet: als je ops-dashboard down is, liggen orders stil; als je supportconsole traag is, wachten klanten; als je adminpaneel crasht, stapelen fixes zich op.
Zonder duidelijke betrouwbaarheidsdoelen wordt elke storing een discussie. De één haalt zijn schouders op bij een glitch van 10 minuten, de ander maakt er een crisis van. Je verliest tijd aan lawaaiige chats, onduidelijke prioriteiten en verrassend werk op het slechtste moment.
SLO's lossen dat op door simpele verwachtingen te stellen die je kunt meten. Ze beantwoorden twee praktische vragen: wat moet er werken, en hoe goed moet het werken zodat mensen hun werk kunnen doen.
De verborgen kosten van “we houden het redelijk stabiel” verschijnen snel. Werk stopt terwijl teams wachten tot een tool herstelt. Support-berichten nemen toe omdat niemand weet wat normaal is. Engineers worden meegesleurd in urgente fixes in plaats van geplande verbeteringen. Producteigenaren verliezen vertrouwen en vragen om handmatige backups. Kleine problemen blijven liggen omdat ze nooit een duidelijke grens overschrijden.
Je hebt geen volledig reliability-programma nodig. Een klein team kan beginnen met een paar gebruikersgerichte doelen zoals “inloggen werkt” of “zoekresultaten laden snel”, plus een kleine set alerts gekoppeld aan echte acties.
Dit geldt ongeacht hoe de tool gebouwd is. Als je AppMaster (appmaster.io) gebruikt om interne apps te maken, kies dan de acties waarop mensen vertrouwen, meet uptime en responstijd, en waarschuw alleen wanneer het werk erdoor wordt beïnvloed.
Deze drie termen klinken vergelijkbaar, maar ze zijn verschillende soorten taal over betrouwbaarheid. Ze door elkaar halen is een veelvoorkomende bron van verwarring.
Een SLI (Service Level Indicator) is een meting. Het is iets dat je kunt tellen, zoals “percentage verzoeken dat slaagt” of “hoe lang de pagina nodig had om te laden.” Als je het niet betrouwbaar kunt meten, is het geen goede SLI.
Een SLO (Service Level Objective) is het doel voor die meting. Het beantwoordt: welk niveau is goed genoeg voor gebruikers het grootste deel van de tijd? SLO's helpen je beslissen wat je eerst repareert en wat kan wachten.
Een SLA (Service Level Agreement) is een belofte, meestal op papier, vaak met consequenties. Veel interne tools hebben geen SLA nodig. Ze hebben duidelijke doelen nodig, geen juridische verplichtingen.
Een kort voorbeeld:
Let op wat ontbreekt: “nooit down” of “altijd snel.” SLO's gaan niet over perfectie. Ze maken afwegingen zichtbaar zodat een klein team kan kiezen tussen features, betrouwbaarheidswerk en het vermijden van onnodig zwoegen.
Een praktische regel: als het halen van het doel heldenacties vereist, is het geen SLO maar wensdenken. Begin met iets dat je team kalm kan onderhouden en verscherp het later als gebruikers nog pijn voelen.
Interne tools falen op specifieke manieren: het adminpaneel laadt maar opslaan draait eeuwig; een ops-dashboard opent maar grafieken verversen nooit; een staff-portal werkt behalve dat inloggen na een update faalt. Je haalt de meeste waarde door te focussen op de acties waar mensen dagelijks op vertrouwen, niet op elke pagina en knop.
Begin met het benoemen van het type tool, want dat hint naar de kritieke paden. Adminpanelen gaan over “iets veilig veranderen.” Ops-dashboards gaan over “zien wat er nu gebeurt.” Portals gaan over “inloggen, informatie vinden en een verzoek indienen.”
Schrijf dan de belangrijkste gebruikersreizen in gewone taal op. Een goed startsetje:
Voor elke reis, definieer wat als falen telt. Wees strikt en meetbaar: een 500-fout is een failure, maar ook een timeout, een pagina die nooit klaar is met laden, of een formulier dat succes retourneert terwijl de data ontbreekt.
Houd de scope klein in het begin. Kies 1 tot 3 reizen die overeenkomen met echte pijn en echt risico. Als de on-call pagina's meestal “niemand kan inloggen” en “de opslaan-knop hangt”, begin dan met Inloggen en Formulier indienen. Voeg Zoeken later toe zodra je de metingen en alerts vertrouwt.
Goede SLIs zijn saai. Ze komen uit data die je al hebt en ze matchen wat gebruikers voelen als de tool werkt of faalt. Als je een compleet nieuw monitoring-systeem nodig hebt alleen om ze te meten, kies dan eenvoudigere SLIs.
Begin met beschikbaarheid in termen die mensen begrijpen: kan ik de tool openen en kan ik de taak afronden? Voor veel interne tools dekken twee SLIs het grootste deel van de pijn:
Voeg dan latency toe, maar houd het beperkt. Kies één of twee schermen of endpoints die representatief zijn voor de wachttijd waar gebruikers over klagen, zoals het dashboard laden of een formulier indienen. Alles meten creëert meestal ruis en ruzie.
Bepaal het meetvenster van tevoren. Een rollend venster van 30 dagen is gebruikelijk voor stabiele tools; wekelijks kan werken wanneer je vaak releaset en snel feedback wilt. Wat je ook kiest, houd je eraan zodat trends betekenis krijgen.
Kies ten slotte één enkele bron van waarheid per SLI en noteer die:
Voorbeeld: als je interne app is gebouwd op AppMaster, kun je uptime meten met een synthetische ping naar de backend, succesratio uit API-responses en latency uit backend request-timings. Het belangrijkste is consistentie, niet perfectie.
Begin met een uptime-getal dat je kunt verdedigen in een slechte week. Voor veel interne tools is 99,5% een goed eerste SLO. Het klinkt hoog, maar het laat ruimte voor normale wijzigingswerkzaamheden. Direct naar 99,9% gaan betekent vaak pagingen buiten werktijd en tragere releases.
Vertaal uptime naar tijd om het tastbaar te maken. Een maand van 30 dagen heeft ongeveer 43.200 minuten:
Die toegestane downtime is je errorbudget. Als je het vroegtijdig verbrandt, pauzeer je risicovolle wijzigingen en richt je je op betrouwbaarheid totdat je weer op schema zit.
Voor latency, vermijd gemiddelden. Die verbergen de trage momenten die gebruikers onthouden. Gebruik een percentiel (meestal p95) en stel een duidelijke grens vast gekoppeld aan een echte actie. Voorbeelden: “p95 paginalaadtijd voor het dashboard onder 2 seconden” of “p95 Opslaan afgerond onder 800 ms.”
Een eenvoudige manier om het eerste getal vast te stellen is een week naar echt verkeer kijken en een target kiezen dat iets beter is dan vandaag maar niet fantastisch. Als p95 al 1,9 seconden is, is een 2,0-seconde SLO veilig en nuttig. Een 500 ms SLO veroorzaakt alleen maar ruis.
Koppel SLO's aan je support-capaciteit. Een klein team kiest beter voor een paar haalbare doelen dan voor vele strikte. Als niemand binnen een uur kan reageren, stel dan geen doelen die uitgaan van snellere reactietijden.
Een strakker SLO klinkt geruststellend, maar het heeft een prijs. Als je een tool van 99,5% naar 99,9% uptime brengt, zeg je ook “we accepteren veel minder slechte minuten”, wat meestal meer pagingen en meer tijd aan betrouwbaarheid betekent in plaats van nieuwe features.
De eenvoudigste manier om dit zichtbaar te maken is praten in errorbudgeten. Met 99,5% maandelijk target kun je ongeveer 3,6 uur downtime “uitgeven” in een maand van 30 dagen. Met 99,9% heb je slechts ongeveer 43 minuten. Dat verschil verandert hoe vaak je featurewerk stopt om aan betrouwbaarheid te werken.
Het helpt ook om verwachtingen af te stemmen op wanneer mensen de tool echt gebruiken. Een 24/7-target is duur als de tool alleen kritisch is van 9:00–18:00. Je kunt één SLO voor kantooruren (strikter) en een lossere voor buiten kantooruren instellen zodat het team kan slapen.
Gepland onderhoud telt niet als falen zolang het gecommuniceerd en begrensd is. Behandel het als een expliciete uitzondering (onderhoudsvenster) in plaats van alerts achteraf negeren.
Schrijf de basisregels op zodat iedereen de afwegingen ziet:
Na 4 tot 6 weken echte data, evalueer het doel. Als je nooit errorbudget verbrandt, is de SLO mogelijk te ruim. Als je het snel verbrandt en features stagneren, is het waarschijnlijk te strak.
Alerts zijn niet je SLO's. Alerts zijn het signaal “er gaat nu iets mis” dat het SLO beschermt. Een simpele regel: maak voor elk SLO één alert die ertoe doet en weersta de verleiding om er meer bij te zetten tenzij je kunt aantonen dat ze downtime verminderen.
Een praktische aanpak is alarmeren bij snelle SLO-verbranding (hoe snel je errorbudget opgaat) of bij één duidelijke drempel die gebruikerspijn reflecteert. Als je latency-SLO “p95 onder 800 ms” is, page dan niet bij elke trage piek. Page alleen wanneer het aanhoudt.
Een eenvoudige verdeling die ruis laag houdt:
Concrete drempels (pas aan op jouw verkeer): als je uptime-SLO 99,5% per maand is, page dan wanneer beschikbaarheid onder 99% zakt gedurende 10 minuten (duidelijke outage). Creëer een ticket wanneer het onder 99,4% zakt over 6 uur (langzame verbranding). Voor latency, page wanneer p95 > 1,5 s voor 15 minuten; ticket wanneer p95 > 1,0 s voor 2 uur.
Maak eigenaarschap expliciet. Bepaal wie on-call is (zelfs als het “iemand deze week” is), wat acknowledge betekent (bijv. binnen 10 minuten) en wat de eerste actie is. Voor een klein team dat een interne app op AppMaster draait, kan die eerste actie zijn: controleer recente deployments, kijk naar API-fouten en rol terug of redeploy indien nodig.
Doe na elke echte alert één kleine follow-up: repareer de oorzaak of stem de alert af zodat hij minder vaak page maar nog steeds echte gebruikersimpact opvangt.
Alert fatigue begint meestal met goed bedoelde stappen. Een klein team voegt “even snel” een paar alerts toe en vervolgens elke week nog één. Voor je het weet vertrouwen mensen notificaties niet meer en worden echte outages gemist.
Een grote valkuil is alerten op elke piek. Interne tools hebben vaak bursty traffic (loonrondes, einde-van-de-maandrapporten). Als een alert afgaat op een piek van 2 minuten, leert het team die te negeren. Koppel alerts aan signalen van gebruikersimpact, niet aan ruwe metric-ruis.
Een andere val is denken “meer metrics = veiliger.” Meestal betekent het meer pagingen. Houd je aan een kleine set signalen die gebruikers echt voelen: inloggen faalt, pagina laadt te langzaam, belangrijke jobs ronden niet af.
Fouten die de meeste ruis veroorzaken:
Dashboards blijven belangrijk, maar ze moeten helpen bij diagnose nadat een alert is afgegaan, niet de alert vervangen.
Als je nog geen schone metingen hebt, doe niet alsof je die wel hebt. Voeg eerst basisinstrumentatie toe (succesratio, p95-latency en een “kan een gebruiker de taak voltooien”-check) en stel drempels op basis van een week of twee echte data.
Voer voor je alerts inschakelt een korte pre-flight uit. De meeste alert fatigue komt doordat één van deze basics wordt overgeslagen en later onder druk geprobeerd wordt te repareren.
Een praktische checklist voor een klein team:
Zorg er vervolgens voor dat de alert daadwerkelijk te handelen is. Een alert die afgaat wanneer niemand beschikbaar is, leert mensen hem te negeren.
Bepaal deze operationele details voordat de eerste page komt:
Als je de tool bouwt of verandert (ook in AppMaster), doorloop de checklist opnieuw. Gehergenerate code en nieuwe flows kunnen latency en foutpatronen verschuiven, en je alerts moeten bijblijven.
Een ops-team van 18 mensen gebruikt een intern dashboard de hele dag om orderstatus te checken, gefaalde notificaties opnieuw te versturen en refunds goed te keuren. Als het down of traag is, stopt het werk snel.
Ze kiezen twee SLO's:
Nu voegen ze drie alerts toe die een klein team kan afhandelen:
Wat telt is wat er volgende week gebeurt. Als de error budget-alert twee keer afging, neemt het team een duidelijke maatregel: vertraag een nieuwe feature en besteed twee dagen aan het repareren van de grootste latency-oorzaak (bijv. een niet-geïndexeerde tabelscan). Als ze de tool in AppMaster bouwden, kunnen ze het datamodel aanpassen, regenereren en clean code redeployen in plaats van snelle lapmiddelen.
SLO's helpen alleen als ze verbonden blijven met echt werk. Het geheim is ze als een kleine gewoonte te behandelen, niet als een nieuw programma.
Gebruik een cadans die past bij een klein team en koppel het aan een bestaande meeting. Een korte wekelijkse blik vangt drift, en een maandelijkse aanpassing is genoeg zodra je echte data hebt.
Een licht proces dat standhoudt:
Houd verbeteringen klein en zichtbaar. Als “trage paginaloads elke maandagmorgen” drie keer verschijnt, voer dan één concrete wijziging uit (cache één rapport, voeg een index toe, plan een zware job later) en kijk volgende week naar de SLI.
Gebruik SLO's om netjes en duidelijk nee te zeggen. Als er een verzoek komt voor een lage-waarde feature, verwijs dan naar het huidige errorbudget en vraag: “Zal deze verandering onze save- of goedkeuringsflow in gevaar brengen?” Als je al budget verbrandt, wint betrouwbaarheid. Dat is niet blokkeren, dat is prioriteren.
Houd documentatie minimaal: één pagina per tool. Vermeld de sleutelgebruikersacties, de SLO-getallen, de paar alerts die eraan gekoppeld zijn en de eigenaar. Als de tool in AppMaster gebouwd is, voeg toe waar je logs/metrics bekijkt en wie kan deployen, en stop dan.
De makkelijkste manier om betrouwbaarheid echt te maken is het eerste setupje klein te houden. Kies één interne tool die echte pijn veroorzaakt als hij faalt (on-call handoffs, ordergoedkeuringen, refunds, inventory-edits) en stel doelen rond de paar acties die mensen dagelijks doen.
Een minimaal werkbare setup die de meeste teams kunnen kopiëren:
Als dat stabiel is, breid langzaam uit: voeg één actie toe, of één extra tool per maand. Als je niet kunt zeggen wie een alert zal bezitten, maak hem dan nog niet.
Als je interne tools bouwt of herbouwt, kan AppMaster het onderhoud eenvoudiger maken. Je kunt datamodellen en businesslogica visueel updaten en clean code regenereren zodra behoeften verschuiven, wat helpt SLO's in lijn te houden met wat de tool vandaag daadwerkelijk doet.
Probeer één interne tool te bouwen en voeg vanaf dag één basis-SLO's toe. Je krijgt duidelijkere verwachtingen, minder verrassingen en alerts die je kleine team kan bijbenen.
Hebben interne tools echt SLO's nodig als er maar een klein team mee werkt?SLO's halen de vaagheid weg door “redelijk stabiel” om te zetten in een duidelijk meetbaar doel. Zelfs met 20 gebruikers kan een storing bestellingen stilleggen, support vertragen of goedkeuringen blokkeren; kleine tools kunnen dus grote impact hebben.
Wat moeten we als eerste meten voor een adminpanel of ops-dashboard?Kies een paar gebruikersacties die mensen dagelijks doen en die het werk blokkeren wanneer ze falen. Veelvoorkomende starters zijn inloggen, het hoofd-dashboard met actuele data laden, zoeken/filteren en het succesvol indienen van een create/update-formulier.
Wat is het verschil tussen een SLI, een SLO en een SLA?Een SLI is de metric die je meet (zoals succespercentage of p95-latency). Een SLO is het doel voor die metric (bijv. 99,5% succes over 30 dagen). Een SLA is een formele belofte met consequenties — de meeste interne tools hebben dat niet nodig.
Wat is een realistisch uptime-SLO voor een klein team?Een goed startpunt voor uptime voor veel interne tools is 99,5% per maand, omdat dat haalbaar is zonder voortdurend heldendom. Als een tool echt cruciaal is tijdens kantooruren kun je het later aanscherpen op basis van data.
Hoe vertalen we uptime-percentages naar downtime die mensen begrijpen?Vertaal het uptime-percentage naar minuten zodat iedereen de afweging begrijpt. In een maand van 30 dagen staat 99,5% ongeveer 216 minuten downtime toe, terwijl 99,9% ongeveer 43 minuten toestaat — wat vaak meer pagingen en meer nood aan betrouwbaarheid betekent.
Hoe stellen we latency-SLO's in zonder veel ruis te creëren?Gebruik een percentiel zoals p95, niet het gemiddelde, omdat gemiddelden de trage momenten verbergen die gebruikers zich herinneren. Zet het doel op een echte actie (bijv. “p95 dashboard-load < 2s tijdens kantooruren”) en kies een grens die je kalm kunt handhaven.
Welke SLIs zijn het makkelijkst te meten zonder een groot monitoringsysteem?Begin met server-metrics en logs die je al hebt: beschikbaarheid (bereikbaar en reagerend), succespercentage voor sleutelacties en p95-latency voor één of twee kritieke endpoints of schermen. Voeg synthetische checks alleen toe voor de belangrijkste flows zodat meting consistent en eenvoudig blijft.
Hoeveel alerts moeten we instellen voor één interne tool?Beperk je tot een klein aantal alerts gekoppeld aan gebruikersimpact en page alleen bij aanhoudende problemen. Een nuttige verdeling is één urgente pagina voor “tool is feitelijk kapot” en één niet-dringende ticket voor “langzame achteruitgang” die je tijdens werkuren kunt afhandelen.
Wat veroorzaakt alert fatigue bij interne tools en hoe voorkomen we dat?Alert fatigue ontstaat vaak door te page-en bij elke piek of bij symptomen zoals CPU in plaats van bij echte gebruikersimpact zoals fouten en latency. Houd alerts beperkt, wijs voor elke alert een eigenaar aan en repareer of stem na elke echte alert de oorzaak of drempel af zodat hij minder vaak valse meldingen geeft.
Hoe passen we SLO's toe als we onze interne tools in AppMaster bouwen?Kies de sleutelacties in je app en meet uptime, succespercentage en p95-latency voor die acties met één consistente bron van waarheid. Als je interne tools bouwt in AppMaster, richt je doelen op wat gebruikers doen (login, save, search) en pas metingen en alerts aan na grote wijzigingen of regeneraties zodat ze aansluiten op het huidige gedrag.
21 jan 2026
8 min
20 jan 20268 min
20 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
