Gebruik dit incident-runbook voor no-code apps om problemen snel te detecteren, impact te triageren, veilig terug te rollen, duidelijk te communiceren en herhaling te voorkomen.
Een incident is elk onverwacht probleem dat mensen ervan weerhoudt je app te gebruiken, de app pijnlijk traag maakt of data in gevaar brengt. Bij no-code apps kan dat eruitzien als plotselinge inlogfouten, kapotte schermen na een wijziging, achtergrondautomatiseringen die stoppen, API-fouten, of ‘geslaagde’ workflows die stilletjes verkeerde waarden naar de database schrijven.
Een geschreven runbook verandert een stressmoment in een reeks kleine, duidelijke acties. Het vermindert giswerk, versnelt beslissingen (zoals wanneer te rollbacken) en zorgt dat iedereen dezelfde feiten deelt. De meeste vertragingen tijdens incidenten zijn niet technisch; ze komen door onduidelijkheid: is het echt? Wie leidt? Wat is er veranderd? Wat vertellen we gebruikers?
Dit playbook is voor iedereen die de app aanraakt als er iets misgaat: builders die wijzigingen uitrollen, ops of platform-eigenaren die deployments en toegang beheren, supportteams die de eerste meldingen horen, en product- of business-eigenaren die impact en prioriteiten beoordelen.
Het is bewust lichtgewicht, ook geschikt voor teams die bouwen op platforms zoals AppMaster waar je visuele logica, gegenereerde services en meerdere deploy-opties hebt.
Het dekt de volledige incidentloop: detecteren en bevestigen dat er echt een probleem is, snel triageren, stabiliseren en herstellen (inclusief rollback-beslissingen), communiceren tijdens de storing, en daarna een korte post-incident review om herhaling te voorkomen.
Het behandelt geen langetermijn-architectuurherontwerp, diepe security-forensiek of complexe complianceprocedures. Werk je met gereguleerde data of kritieke infrastructuur, voeg dan strengere stappen toe bovenop dit runbook.
Incidenten voelen chaotisch als je niet weet hoe “normaal” eruitziet. Definieer je baseline zodat het team echte problemen snel herkent. Voor een no-code app komen vroege signalen meestal uit een mix van platformgezondheid, businessmetric en mensen.
Schrijf de signalen op die je elke dag bewaakt, niet alleen tijdens storingen. Veelvoorkomende zijn uptime, foutpercentages, trage schermen, mislukte logins, betaalfouten en pieken in supporttickets of gebruikersberichten.
Definieer severity in duidelijke taal zodat iedereen het kan gebruiken:
Stel responstargets die momentum creëren. Voorbeeldtargets: erken binnen 5 minuten, post de eerste update binnen 15 minuten, en probeer binnen 60 minuten te stabiliseren (ook al duurt de volledige fix langer).
Bepaal rollen voordat je ze nodig hebt. Noem wie een incident kan uitroepen, wie het leidt en wie backup is als die persoon offline is. Bij AppMaster-teams is dat vaak degene die de Business Process-logica beheert, plus een backup die deployments of exports kan uitvoeren.
Houd ten slotte één gedeelde plek voor incidentnotities. Gebruik tijdstempels voor elke actie (wat veranderde, wanneer, door wie) zodat je later het verhaal kunt reconstrueren zonder te gokken.
Bevestig de impact voordat je naar dashboards staart. Stel één duidelijke vraag: wie kan nu niet wat doen? “Support kan geen tickets openen” is nuttiger dan “de app is traag.” Reproduceer het probleem indien mogelijk met dezelfde rol en hetzelfde apparaat als de getroffen gebruiker.
Werk daarna uit hoe wijdverspreid het is. Is het één account, een klantsegment of iedereen? Maak snelle splits: regio, accounttype, web versus mobiel, en één feature versus de hele app. In no-code tools kan iets globaal lijken terwijl het eigenlijk een permissieregel of één kapot scherm is.
Controleer vervolgens wat er is veranderd. Kijk 1–2 uur terug naar een release, een config-toggle, een database-schemawijziging of een data-import. Op platforms zoals AppMaster kunnen wijzigingen in business processes, datamodellen of auth-instellingen veel flows tegelijk beïnvloeden, zelfs als de UI er prima uitziet.
Voordat je de schuld bij je app legt, sluit externe afhankelijkheden uit. Email/SMS-providers, betalingen (zoals Stripe) en integraties (Telegram, AWS-services, AI-API's) kunnen falen of rate-limiten. Als de app alleen faalt bij het sturen van berichten of incasseren, kan de oorzaak upstream liggen.
Gebruik een eenvoudige beslis-checklist:
Zodra je severity en scope klasseert, kun je van “is het echt?” naar “wat doen we eerst?” zonder te gokken.
Open onmiddellijk een incidentrecord. Geef het een duidelijke titel die de gebruikersimpact benoemt, niet de vermoedelijke oorzaak (bijvoorbeeld: “Checkout faalt voor EU-klanten”). Noteer de starttijd (eerste alert of eerste melding). Dit wordt de enige plek voor besluiten, tijdstempels en wat er veranderde.
Wijs rollen toe zodat werk niet overlapt. Zelfs in een klein team vermindert het benoemen van eigenaren fouten onder stress. Minimaal wil je:
Stel twee dingen schriftelijk vast: wat je zeker weet, en je huidige hypothese. “Bekend” kan zijn: foutpercentage is gestegen, een specifiek endpoint faalt, alleen mobiel is geraakt. De hypothese kan fout blijken, maar moet de volgende test sturen. Houd beide bijgewerkt terwijl je leert.
Terwijl dingen onstabiel zijn, houd een updatecadans van 15 minuten aan. Als er niets veranderde, zeg dat. Regelmatige updates stoppen zij-discussies en voorkomen dubbele “nog nieuws?”-vragen.
Kies de eerste containment-actie. Het doel is snel schade beperken, ook als de oorzaak nog niet duidelijk is. Typische eerste stappen zijn het pauzeren van achtergrondjobs, het uitschakelen van een risicovolle featureflag, het beperken van verkeer naar een module, of overschakelen naar een bekende-veilige configuratie. In AppMaster betekent dit vaak het uitzetten van een specifieke flow in de Business Process Editor of tijdelijk verbergen van een UI-pad dat fouten triggert.
Als containment binnen één cadans-venster de metrics niet verbetert, begin dan parallel met rollback-planning.
Zodra je bevestigd hebt dat het echt een incident is, schakel je van “de bug zoeken” naar “het bloeden stoppen.” Stabiliseren koopt tijd. Het beschermt ook gebruikers, omzet en data terwijl je onderzoekt.
Begin met de kleinste wijziging die schade vermindert. Containment is vaak sneller dan een volledige fix omdat je een nieuwe feature kunt uitschakelen, een workflow kunt pauzeren of een risicovolle invoerroute kunt blokkeren zonder te hoeven rebuilden.
Als je vermoedt dat data wordt beschadigd, stop dan eerst writes. Dat kan betekenen: formulieren tijdelijk uitschakelen, automatiseringen die records bijwerken pauzeren, of een API-endpoint blokkeren dat updates accepteert. Slechte data lezen is pijnlijk, maar slechte data schrijven vermenigvuldigt het schoonmaakwerk.
Als gebruikers zijn buitengesloten, behandel inloggen als topprioriteit. Controleer authenticatie-instellingen en de loginflow vóór alles. Elke andere fix is trager als gebruikers (en je eigen team) geen toegang tot de app hebben.
Als de app traag is of timeouts geeft, verlaag dan de load en verwijder dure paden. Schakel zware schermen uit, pauzeer achtergrondjobs en zet nieuwe integraties uit die requests pieken. In AppMaster kan containment zo simpel zijn als het uitschakelen van een probleemveroorzakend business process of tijdelijk verwijderen van een UI-actie die een kostbare keten triggert.
Houd acties bedachtzaam en gedocumenteerd. Onder druk herhalen teams stappen of draaien per ongeluk een fix terug. Schrijf elke wijziging op en noteer het resultaat.
Een eenvoudige stabilisatievolgorde:
Het doel is “veilig en bruikbaar”, niet “volledig opgelost”. Zodra de impact beperkt is, kun je rustig diagnosticeren en de juiste rollback of fix kiezen.
Als iets faalt, telt snelheid, maar wint veiligheid. Je hebt meestal drie praktische opties: rollbacken, een fix naar voren shippen, of een gedeeltelijke revert (één feature uitschakelen terwijl de rest blijft draaien).
Wees eerst duidelijk wat “rollback” betekent in jouw omgeving. Het kan betekenen: de vorige appversie deployen, een configwijziging terugdraaien of een database-state herstellen. Op platforms zoals AppMaster kan een “versie” backend-logica, web-UI, mobiele builds en omgevingsinstellingen bevatten.
Gebruik deze risicochecks om te beslissen of rollback veilig is:
Stel een eenvoudige go/no-go regel voor je iets aanraakt. Kies 2–3 metrics die binnen 10–15 minuten na de actie moeten verbeteren, zoals foutpercentage, inlogsucces, checkout-completie of API-latency. Als ze niet de juiste kant op bewegen, stop dan en switch van strategie.
Plan ook de backout van de rollback. Weet hoe je die ongedaan maakt als de oudere versie nieuwe problemen veroorzaakt: welke build je opnieuw uitrolt, welke config terug moet, en wie die tweede wijziging goedkeurt. Hou één persoon verantwoordelijk voor de uiteindelijke “ship”-beslissing zodat je niet halverwege van koers verandert.
Zwijgen maakt incidenten erger. Gebruik een simpele, herhaalbare manier om mensen geïnformeerd te houden terwijl het team onderzoekt.
Begin met interne updates. Informeer de mensen die als eerste vragen krijgen en de mensen die blokkades kunnen wegnemen. Houd het kort en feitelijk. Je hebt meestal nodig:
Voor externe updates: houd je aan wat je zeker weet. Vermijd het raden naar de oorzaak of het de schuld geven aan een leverancier. Gebruikers willen meestal drie dingen: bevestiging, impact en wanneer je ze weer updatet.
Houd één statusregel consistent over kanalen:
Als gebruikers boos zijn, erken dat eerst en wees daarna specifiek: “We weten dat checkout faalt voor sommige klanten. We rollen nu de laatste wijziging terug. Volgende update over 30 minuten.” Beloof geen deadlines, credits of permanente fixes tijdens het incident.
Roep resolved alleen uit wanneer het hoofdsymptoom weg is en sleutelchecks schoon zijn (logins, kerntaken, foutpercentages). Gebruik monitoring wanneer je een fix hebt toegepast (bijvoorbeeld rollback of configuratiewijziging) maar nog tijd nodig hebt om herhaling uit te sluiten. Geef altijd aan wat je monitort, hoe lang en wanneer de definitieve update volgt.
Zodra dingen stabiel zijn, schakel je van brandjes blussen naar het verzamelen van de kleinste set feiten die de symptomen verklaart. Het doel is niet de perfecte root cause; het is een waarschijnlijke oorzaak waar je op kunt handelen zonder het incident erger te maken.
Verschillende symptomen wijzen op verschillende verdachten. Trage pagina’s duiden vaak op langzame database-queries, een plotselinge trafficpiek of een externe service die traag reageert. Timeouts kunnen komen door een vastgelopen proces, een overbelaste backend of een integratie die te lang wacht. Een piek in errors of retries volgt vaak op een recente wijziging, slechte input of een upstream outage.
Doorloop één echte gebruikersreis end-to-end met een normaal testaccount. Dit is vaak het snelste signaal omdat het UI, logica, database en integraties raakt.
Focus op een handvol checks:
Als je op AppMaster werkt, past dit vaak netjes op een Business Process-stap, een Data Designer-wijziging of een deployment-config.
Als de snelle checks wijzen op een duidelijke oorzaak, kies dan de veiligste stap: houd de huidige mitigatie aan, of pas een kleine permanente fix toe. Verwijder rate limits, feature toggles of manuele workarounds alleen nadat de reis twee keer succesvol is verlopen en het foutpercentage enkele minuten stabiel blijft.
Het is dinsdag 10:15. Het team rolt een kleine wijziging uit naar een klantenportal gebouwd op AppMaster. Binnen enkele minuten zien gebruikers blanco pagina’s na inloggen en stoppen nieuwe bestellingen binnen te komen.
Support ziet drie tickets met hetzelfde bericht: “Inloggen werkt, maar daarna laadt het portaal nooit.” Tegelijk toont monitoring een piek in 500-errors op de webapp en een daling in succesvolle API-calls. Je behandelt het als een echt incident.
De incidentlead doet een snelle bevestiging: inloggen als testgebruiker op desktop en mobiel proberen, en de tijd van de laatste deployment checken. De timing komt overeen met de release, dus je gaat ervan uit dat de laatste wijziging betrokken is totdat het tegendeel bewezen is.
De eerste 30 minuten kunnen er zo uitzien:
Om 10:40 zijn de fouten weer normaal. Je houdt metrics in de gaten terwijl support bevestigt dat nieuwe tickets afnemen.
Achteraf doet het team een korte review: wat ving dit eerst op (alerts vs support), wat vertraagde jullie (ontbrekende owner, onduidelijke rollback-stappen), en wat te veranderen. Een gebruikelijke verbetering is het toevoegen van een release smoke-test checklist voor de top drie flows van het portal en het documenteren van rollback als één-actie stap.
De meeste incidenten worden erger om één van twee redenen: teams laten het systeem schade blijven doen terwijl ze onderzoeken, of ze veranderen te veel dingen te snel. Dit runbook is bedoeld om je tegen beide te beschermen.
Een veelvalkuil is onderzoeken terwijl de app nog slechte data schrijft. Als een workflow in een loop zit, een integratie duplicaten post of een permissiebug de verkeerde gebruikers records laat bewerken, pauzeer dan eerst het proces. In AppMaster kan dat betekenen: een Business Process uitschakelen, een module-integratie uitzetten of tijdelijk toegang beperken zodat het probleem niet verder verspreidt.
Een andere valkuil is gokken bij het fixen. Als meerdere mensen klikken en instellingen veranderen, verlies je de tijdlijn. Zelfs kleine aanpassingen tellen tijdens een incident. Spreek één bestuurder af, houd een eenvoudige changelog bij en vermijd het stapelen van tweaks boven onbekenden.
Fouten die herhaaldelijk tot langere outages leiden:
Communicatie is onderdeel van herstel. Deel wat je weet, wat je niet weet en wanneer de volgende update komt. “We rollen terug en bevestigen binnen 15 minuten dat billing-events correct zijn” is beter dan “We kijken ernaar.”
Sluit het incident niet alleen omdat errors stopten. Verifieer met een korte checklist: belangrijke schermen laden, nieuwe records worden correct opgeslagen, kritieke automatiseringen lopen één keer en backlogs (queues, retries, scheduled jobs) zijn leeg of veilig gepauzeerd.
Als er iets faalt, probeert je brein tegelijk tien dingen te doen. Gebruik dit om rustig te blijven, mensen te beschermen en de service terug te krijgen.
Pin deze sectie waar je team het echt ziet.
Neem één minuut om een incident-eigenaar te benoemen. Eén persoon beslist, de rest ondersteunt.
Stabiliseer en contain (10 minuten): Stop het bloeden voordat je de root cause jaagt. Schakel het risicovolle pad uit (feature-toggle, tijdelijke banner, queue-pauzes) en test één sleutelreis end-to-end. Kies de reis die het meest belangrijk is voor het bedrijf, niet de gemakkelijkste om te testen.
Herstel de service (10–20 minuten): Kies de veiligste actie: rollback naar de laatst bekende goede versie of een minimale fix toepassen. Op platforms zoals AppMaster kan dat betekenen: een vorige build redeployen of de laatste wijziging terugdraaien, en dan bevestigen dat foutpercentages en responstijden weer normaal zijn.
Communiceer (gedurende): Plaats korte statusupdates met wat geraakt is, wat gebruikers moeten doen en wanneer de volgende update komt. Voorzie support van een tweezins-script zodat iedereen hetzelfde zegt.
Rond netjes af (zodat je het niet vergeet): Leg vast wat er gebeurde, wat je wijzigde en wanneer de service hersteld was. Wijs vervolgstappen toe met eigenaar en deadline (monitoring tweak, testgap, datacleanup, follow-up fix).
Een incident is niet volledig “klaar” wanneer de app weer werkt. De snelste manier om toekomstige downtime te verminderen is vastleggen wat er gebeurde terwijl het nog vers is, en die leerpunten omzetten in kleine, reële wijzigingen.
Plan binnen 2–5 dagen een korte post-incident review. Houd het blame-free en praktisch. Het doel is niet iemand te vinden om de schuld te geven, maar het volgende incident makkelijker te maken.
Schrijf een verslag dat iemand maanden later kan lezen: wat gebruikers zagen, wanneer je het ontdekte, wat je probeerde, wat werkte en wanneer de service terugkeerde. Neem de root cause op als je die kent, en noteer bijdragers zoals ontbrekende alerts, onduidelijke ownership of verwarrende rollout-stappen.
Zet leerpunten om in taken met eigenaren en deadlines. Focus op de kleinste veranderingen die dezelfde fout voorkomen:
Kies per incident één preventiemaatregel, zelfs als die klein is. “Elke wijziging in rollen vereist een tweede reviewer” of “Datamigraties eerst in een staging-kopie draaien” kan herhaling voorkomen.
Houd dit runbook naast je build- en releaseproces. Als je met AppMaster bouwt, noteer waar elke app draait (AppMaster Cloud, AWS, Azure, Google Cloud of self-hosted), wie snel kan redeployen en wie kan rollbacken. Wil je één centrale plek voor die documentatie, dan maakt het bijhouden naast je AppMaster-projectnotities (appmaster.io) het makkelijker te vinden als minuten tellen.
When should we treat a problem as an incident for a no-code app?Gebruik het altijd wanneer een onverwacht probleem kernactiviteiten blokkeert, de app onbruikbaar traag maakt of risico geeft op onjuiste of onveilige dataveranderingen. Als gebruikers niet kunnen inloggen, betalingen mislukken, automatiseringen stoppen of records verkeerd worden weggeschreven, behandel het als een incident en volg dit runbook.
What’s the fastest way to confirm an incident is real and measure impact?Begin met de gebruikersimpact: wie kan nu niet wat doen, en sinds wanneer. Reproduceer het daarna met dezelfde rol en hetzelfde apparaat en controleer of het één account, een segment of iedereen betreft, zodat je niet naar de verkeerde oorzaak gaat zoeken.
How do we quickly decide SEV1 vs SEV2 vs SEV3?Declareer SEV1 wanneer de meeste gebruikers worden geblokkeerd of geld/veiligheid/data in gevaar is. Gebruik SEV2 wanneer een belangrijke feature kapot is maar er een workaround is, en SEV3 voor kleine of beperkte problemen; snel beslissen is belangrijker dan perfect zijn.
Who should do what during an incident, especially in a small team?Kies één incidentlead die de uiteindelijke beslissingen neemt, wijs daarna een fixer, een comms-eigenaar en een notulist aan zodat mensen elkaar niet overlappen of per ongeluk dingen aanpassen. In een klein team kan één persoon twee rollen combineren, maar de incidentlead moet duidelijk zijn.
What does “containment” look like in AppMaster or similar no-code platforms?Containment draait om snel schade stoppen, ook als de oorzaak nog onduidelijk is. In AppMaster betekent dat vaak het uitschakelen van een specifieke Business Process, tijdelijk verbergen van een UI-actie die fouten triggert, of het pauzeren van een automatisering die in een loop zit of corrupte data schrijft.
When should we roll back versus ship a quick fix forward?Rollback wanneer het probleem direct na een release begon en je een known-good versie hebt die de service snel herstelt. Kies een forward fix alleen als je een kleine, laag-risico wijziging kunt doorvoeren en snel verifiëren zonder extra downtime te riskeren.
What makes a rollback unsafe in no-code apps?Beschouw rollback als risicovol als het databasemodel is veranderd, als er onomkeerbare writes zijn gedaan, of als queued jobs en webhooks mogelijk opnieuw verwerkt worden door oudere logica. Als dat zo is, stabiliseer eerst en bevestig wat de oudere versie verwacht voordat je her-deployt.
If we suspect data corruption, what should we do first?Stop eerst writes als je data-corruptie vermoedt, want slechte writes maken het opruimwerk veel groter. In de praktijk betekent dit formulieren uitschakelen, update-automatiseringen pauzeren of update-endpoints blokkeren totdat je kunt bevestigen dat nieuwe records niet langer verkeerd worden gewijzigd.
What should we say during an outage, and how often should we update?Stuur korte feitelijke updates op vaste intervallen met wat er geraakt is, wat je doet en wanneer de volgende update volgt. Vermijd speculatie over de oorzaak of het beschuldigen van leveranciers; gebruikers en stakeholders willen vooral duidelijkheid en voorspelbare updates.
When is it okay to call an incident “resolved” versus “monitoring”?Noem het ‘resolved’ pas wanneer het belangrijkste symptoom is verdwenen en sleutelchecks schoon zijn, zoals login, primaire workflows en error rates. Als je iets hebt gefixt maar nog moet monitoren op herhaling, noem het dan ‘monitoring’ en vermeld wat je controleert en hoe lang.
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.
