Best practices voor incidentrespons solo developers
Samenvatting
Solo developers hebben niet meer nodig dan alerting, runbooks en een status page. Bouw een health check cron, een beslisdocument voor 3 uur 's nachts, en één HTML pagina voor gebruikers. Veel enterprise tools zijn overkill; dit weekend volstaat om alles op te zetten.
Best practices voor incidentrespons
Incident response best practices worden geschreven voor enterprise teams, niet voor solo developers. Je bouwt een side project, het vindt gebruikers, en op een ochtend tweet iemand dat het drie uur offline was. Je wist het niet. Geen alerting. Geen runbook. Geen status page.
Dat is het faalpatroon voor 90% van door solo's gebouwde producten. Niet een beveiligingsinbreuk, niet een catastrofaal infrastructuurgebeuren, simpelweg: niemand zei je dat het kapot was, je had geen plan, en je gebruikers ontdekten het eerder dan jij.
Dit vraagt niet om een 40 pagina's playbook of een enterprise toolstack. Het vraagt om drie dingen: weten wanneer iets kapot gaat, weten wat je eraan doet, en de status communiceren naar wie het aangaat. Deze gids behandelt elk onderdeel vanuit het perspectief van een builder, inclusief wat je zelf bouwt en wat je uit bestaande tools samenvoegt.
Wat gaat eerst kapot als je solo bent en on-call
De eerste incident die je solo beheert, zul je 12 minuten doorbrengen met uitzoeken waar dingen zijn voordat je 4 minuten daadwerkelijk iets fixes.
Dat is de echte kost. Niet de downtime. De coördinatieoverhead van een one-person team die niets opgeschreven heeft. Waar zitten de environment variables? Welke service valt werkelijk uit? Raakt dit alle gebruikers of slechts één klant? Je brengt het gulden moment van een incident door met zoeken naar antwoorden die je al lang vooraf had moeten geven.
De oplossing is niet complexe tooling. Het is die vragen beantwoord hebben voordat het 3 uur 's nachts is.
Er is een nuttige test: stel je voor dat je production API nu meteen uitvalt. Je hebt 10 minuten. Kun je de relevante logs vinden, de kapotte component identificeren, en terugdraaien of hotfixen zonder meer dan twee tabbladen te openen die je niet al open had? Als het antwoord nee is, dat is precies wat incident response oplost.
De drie dingen die elke indie incident response setup werkelijk nodig heeft
Voordat je iets bouwt, noem wat het systeem moet doen:
Het probleem opsporen voordat een gebruiker je erover dmt
Je vertellen wat je moet doen wanneer je half in slaap bent en alleen context hebt van de alert
Je gebruikers vertellen wat er gebeurt zonder het erger te maken
Elk incident response tool, van PagerDuty tot je eigen cron job, werkt toe naar één van deze drie taken. Bouw de eenvoudigste versie die al drie doet, stop dan.
De verleiding is om te bouwen naar de enterprise versie: on-call schedules, escalation policies, severity levels P0 tot P5, postmortem templates. Dat is passend bij 20 engineers en 500K users. Bij één dev en 500 users branden die abstracties je weekends op en blijven ongebruikt. De minimale versie is dit weekend haalbaar. Ship dat eerst.
Je alerting layer bouwen: het false positive probleem komt eerst
Elke dev die zijn eigen alerting gebouwd heeft, heeft hetzelfde verhaal: de eerste rule die hij schreef was fout, en na twee weken herrie zette hij de pager uit.
Begin met één check die telt. Een falende health check endpoint is genoeg.
# Simple health check endpoint (Express/Node)
app.get('/health', (req, res) => {
res.json({ status: 'ok', timestamp: Date.now() });
});Draai dan een cron job die het elke 60 seconden pingt. Als het drie keer na elkaar faalt, krijg je een text. Dat is je eerste alerting layer. Het vangt 80% van de incidents op die gebruikers raken.
Het false positive rate op deze setup is bijna nul. Je krijgt paged wanneer de service werkelijk uit is, niet wanneer een CPU spike een threshold triggerde die nooit gekalibreerd was. Dat is het moeilijkste om goed te krijgen in alerting: de alert moet waar zijn, elke keer, of je traint jezelf om het te negeren.
Log-based alerting komt daarna, als de uptime check werkt en vertrouwd wordt. Voor self-hosted stacks werkt Grafana hier goed tegen lagere kosten. Datadog begint zinvol te worden wanneer je meer dan twee of drie services beheert en een unified view wilt met makkelijke integratie naar je deployment pipeline.
Runbooks zijn het document dat je om 23 uur schrijft om om 3 uur 's nachts te lezen
Een runbook is geen documentatie. Documentatie legt uit hoe iets werkt. Een runbook vertelt een toekomstige versie van jou die gestresst, nauwelijks wakker, en onder druk staat precies wat je nu moet doen.
Het format dat werkt voor solo projects:
Wat is kapot? Één zin, enkel waarneembare symptomen
Is het urgent? Raakt het betalende klanten nu meteen?
Wat doe ik? Drie tot vijf genummerde stappen, startend met het snelste om eerst te proberen
Dat is het. Schrijf het wanneer je niet in een incident zit. Lees en update het na een incident om te zien of het werkelijk nuttig was.
Waar je runbooks opslaat, telt minder dan de gewoonte ze te schrijven. Een Notion pagina, een Markdown bestand in je repo, een gedeeld document. De test: kun je het op je telefoon openen in 30 seconden, half wakker, om 3 uur 's nachts?
Het praktische argument voor Notion boven een repo bestand is mobiele toegang. Als je slaapt naast je telefoon omdat je production traffic hebt en een slecht gevoel over een deploy die je net verzonden hebt, dat telt. GitBook is nog een solide optie als je iets gestructureerder voorkeur geeft dat ook als publieke developer docs fungeert.
Een publieke status page bouwen: wat gebruikers werkelijk willen wanneer dingen kapot gaan
Je gebruikers hebben geen real-time observability dashboard nodig. Ze moeten twee dingen weten: is het kapot voor iedereen, en ben je ervan op de hoogte?
De minimale viable status page heeft drie elementen:
Een status indicator met op zijn hoogst drie toestanden: operational, degraded, down
Een timestamp voor wanneer de huidige toestand voor het laatst bijgewerkt werd
Een zin platte Nederlands wanneer iets fout gaat
Gebruikers die een status page checken tijdens een incident, lezen geen architecture diagrammen. Ze willen stoppen troubleshooten van hun eigen setup omdat ze nu weten dat het niet aan hen ligt.
Dit bouwen duurt minder dan vier uur:
Een statische HTML pagina met een JavaScript snippet dat status ophaalt van een endpoint
Een Supabase tabel met twee fields: status (enum) en message (text)
Een cron job die de status bijwerkt op basis van je health check resultaat
Een admin endpoint achter auth om een handgeschreven bericht te schrijven wanneer nodig
Het moeilijke deel is niet het bouwen. Het is de gewoonte het bij te werken tijdens een incident in plaats van recht in de fix te duiken. De update kost 30 seconden en bespaart 15 customer support e-mails.
Het ander argument voor dit zelf bouwen: commercial status page tools rekenen $30 tot $100 per maand voor wat fundamenteel een JSON endpoint en een statische HTML pagina is. Bouw het eens, hou het. Je gebruikers hebben Statuspage.io niet nodig. Ze hebben een URL die nog werkt wanneer je main domain uitvalt.
Post-mortems wanneer jij de enige bent om de schuld te geven
Post-mortems in enterprise settings gaan over geen individuen te blamen en systeemfalen op te sporen. Solo ben je het systeem. De psychologie is anders, maar de praktijk telt nog steeds.
De reden om post-mortems alleen te schrijven: je zult dezelfde klasse van probleem twee keer oplossen als je dat niet doet. Drie maanden later kijk je naar een database query die lockde vanwege een index die je niet toevoegde, en je hebt een vage herinnering aan het herstellen van iets dergelijks eerder, maar je herinnert je niet wat.
Een vijf-minuten format dat standhoudend is:
Wat gebeurde er (één alinea, feiten alleen, geen blaamtaal)
Wat deed je om het te fixen
Eén ding om in het systeem te veranderen
Eén ding om in je proces te veranderen
Schrijf het op dezelfde plek als je runbooks. Het wordt de input voor de volgende runbook update. Over zes maanden creëert dit een licht record van je systeem's faalwijzen dat geen enterprise postmortem tool voor een solo builder repliceert.
Moet je dit bouwen of bestaande tools samenvoegen?
Het eerlijke antwoord hangt af van waar je bent.
Als je nul betalende klanten hebt: bouw het geheel zelf. Health check cron, status page, Notion runbooks. Dit is het juiste project om de patronen te leren. Het werkt dit weekend. Het leert je wat incident response werkelijk vereist. En als je later besluit dit als product te bouwen en verkopen, hebt je de vereisten voor jezelf gevalideerd.
Als je betalende klanten hebt die op uptime rekenen vandaag: begin met bestaande tools. Draai Grafana Cloud free tier samen, zet een uptime monitor op, en open vandaag deze middag een Notion runbook pagina. Je hebt dekking nu nodig, niet na drie weekends bouwen.
Het onderdeel dat waard is je zelf te bouwen ongeacht fase: de status page. Hou het, host het op een apart domein, bouw het dit weekend. Al het ander kun je samenvoegen uit bestaande free tiers totdat complexiteit het bouwen rechtvaardigt.
De kloof waar geen incident response gids over spreekt
Het probleem is niet tooling. Het is de 48 uur tussen 'ik zou alerting moeten opzetten' en 'ik zet werkelijk alerting op.'
De meeste solo dev stacks hebben genoeg observability primitives om een eerste incident response layer in één dag te bouwen. De health check endpoint bestaat ergens. De logs zijn ergens. De deploy pipeline heeft wat error handling. Wat ontbreekt is 90 minuten gefocust wiring: health check naar uptime monitor, uptime monitor naar SMS of Telegram alert, één Notion pagina met drie runbooks, statische pagina met een Supabase status endpoint.
Dit is niet het project dat je naar gebruikers shipped. Dit is het project dat je voor jezelf shipped.
Bouw het dit weekend. De eerste keer dat iets om 3 uur 's nachts kapot gaat en je 4 minuten nodig hebt om het te fixen in plaats van 40 minuten het te zoeken, zul je begrijpen waarom incident response best practices bestaan. Niet omdat enterprise teams het mandateerden, maar omdat het alternatief erger is.