Best Practices Incident Response für Solo-Entwickler
Zusammenfassung
Solo-Devs brauchen drei essenzielle Dinge für Incident Response: zuverlässiges Alerting mit Health Checks ohne False Positives, Runbooks für die 3-Uhr-morgens-Momente, und selbst gebaute Status-Pages. Diese drei Basics dauern nur ein Wochenende zum Bauen und ersparen dir später etwa 40 Minuten beim Debuggen von Incidents.
Best Practices Incident Response
Best Practices für Incident Response werden für Enterprise-Teams geschrieben, nicht für Solo-Devs. Du baust eine Seite project, sie findet Nutzer, und eines Morgens tweetet jemand, dass sie seit drei Stunden down ist. Du hast es nicht bemerkt. Kein Alerting. Kein Runbook. Keine Status-Page.
Das ist der Fehlerfall für 90 % der selbst gebauten Produkte. Nicht ein Breach, nicht ein katastrophaler Infrastructure-Event, nur: niemand hat dir gesagt, dass es broken ist, du hattest keinen Plan, und deine Nutzer haben es vor dir bemerkt.
Das erfordert nicht ein 40-seitiges Playbook oder einen Enterprise-Tool-Stack. Es braucht drei Dinge: wissen, wenn etwas broken ist, wissen, was man dagegen tun kann, und Status kommunizieren an jeden, dem es wichtig ist. Dieser Guide behandelt jedes davon aus der Perspektive des Builders, inklusive was man selbst baut und was man aus bestehenden Tools zusammenstöpselt.
Was zuerst kaputtgeht, wenn man solo on-call ist
Das erste Incident, das du solo managst, wirst du 12 Minuten damit verbringen, herauszufinden, wo die Probleme liegen, bevor du 4 Minuten damit verbringst, sie tatsächlich zu fixen.
Das ist der echte Overhead. Nicht Downtime. Der Koordinations-Overhead eines Teams von einer Person, die nichts aufgeschrieben hat. Wo sind die Environment Variables? Welcher Service failet tatsächlich? Betrifft das alle Nutzer oder nur einen Customer? Du verbringst das Golden Window eines Incidents damit, nach Antworten zu suchen, die du hätte pre-answern sollen.
Das Fix ist keine komplexe Tooling. Es ist, diese Fragen beantwortet zu haben, bevor es 3 Uhr morgens ist.
Es gibt einen nützlichen Test: stell dir vor, deine Production API geht jetzt gerade down. Du hast 10 Minuten. Kannst du die relevanten Logs finden, die failing Component identifizieren, und rollback oder hotfix machen, ohne mehr als zwei Tabs aufzumachen, die du nicht schon offen hattest? Wenn die Antwort nein ist, das ist genau das, was Incident Response für dich tut.
Die drei Dinge, die jedes Indie-Incident-Response-Setup wirklich braucht
Bevor du etwas baust, benenne, was das System tun muss:
Das Problem erkennen, bevor ein Nutzer dir eine DM schickt
Dir sagen, was zu tun ist, wenn du halbwach bist und nur Context aus dem Alert hast
Deinen Nutzern sagen, was vor sich geht, ohne es schlimmer zu machen
Jedes Incident-Response-Tool, von PagerDuty bis zu deinem eigenen Cron Job, ordnet sich in einen dieser drei Jobs ein. Baue die simpleste Version, die alle drei macht, dann stopp.
Die Versuchung ist, auf die Enterprise-Version hinzubauen: On-Call-Schedules, Escalation Policies, Severity Levels P0 bis P5, Postmortem-Templates. Das macht Sinn bei 20 Engineers und 500K Nutzern. Bei einem Dev und 500 Nutzern, diese Abstraktion frisst deine Wochenenden und bleibt ungenutzt. Die minimale Version ist an einem Wochenende machbar. Ship die zuerst.
Dein Alerting-Layer bauen: Das False-Positive-Problem kommt zuerst
Jeder Dev, der sein eigenes Alerting gebaut hat, hat die gleiche Story: die erste Rule, die er geschrieben hat, war falsch, und er hat den Pager nach zwei Wochen Noise abgedreht.
Starte mit einer Check, die wirklich wichtig ist. Ein failing Health-Check-Endpoint reicht.
# Einfacher Health-Check-Endpoint (Express/Node)
app.get('/health', (req, res) => {
res.json({ status: 'ok', timestamp: Date.now() });
});Dann wire einen Cron Job, um ihn alle 60 Sekunden zu pingen. Wenn es drei Mal nacheinander failet, bekommst du eine SMS. Das ist dein erstes Alerting-Layer. Es catchet 80 % der Incidents, die Nutzer beeinflussen.
Die False-Positive-Rate in diesem Setup ist nahe null. Du wirst gepaged, wenn der Service wirklich down ist, nicht wenn eine CPU-Spike ein Threshold triggered, das nie kalibriert war. Das ist das Schwierigste zu machen beim Alerting: der Alert muss wahr sein, jedes Mal, oder du trainierst dich selbst, ihn zu ignorieren.
Log-basiertes Alerting kommt, nachdem der Uptime-Check funktioniert und vertraut ist. Für Self-Hosted-Stacks handhabt Grafana das gut zu kleinerem Cost. Datadog fängt Sinn zu machen an, wenn du mehr als zwei, drei Services managst und einen unified View mit einfacher Integration zu deiner Deployment-Pipeline willst.
Runbooks sind das Dokument, das du um 23 Uhr schreibst, um um 3 Uhr morgens zu lesen
Ein Runbook ist keine Dokumentation. Dokumentation erklärt, wie etwas funktioniert. Ein Runbook sagt einer zukünftigen Version von dir, die stressed, kaum wach und unter Druck ist, exakt was du jetzt tun musst.
Das Format, das für Solo-Projekte funktioniert:
Was ist broken? Ein Satz, nur Observable Symptoms
Ist es urgent? Betrifft es zahlende Customers jetzt gerade?
Was tun? Drei bis fünf Nummerpunkte, angefangen mit dem schnellsten zu versuchen
Das ist alles. Schreib es, wenn du nicht in einem Incident bist. Lese und update es nach einem Incident, um zu sehen, ob es tatsächlich nützlich war.
Wo du Runbooks speicherst, spielt weniger Rolle als die Gewohnheit, sie zu schreiben. Eine Notion-Seite, eine Markdown-Datei in deinem Repo, ein geteiltes Doc. Der Test: kannst du es auf deinem Phone in 30 Sekunden öffnen, halbwach, um 3 Uhr morgens?
Das Praktische-Argument für Notion über eine Repo-Datei ist Mobile-Zugang. Wenn du neben deinem Phone schläfst, weil du Production Traffic hast und ein schlechtes Gefühl zu einem Deploy, das du gerade geschippt hast, das zählt. GitBook ist auch eine solide Option, wenn du etwas mehr Struktur bevorzugst, das auch als public Developer Docs funktioniert.
Eine öffentliche Status-Page bauen: Was Nutzer tatsächlich wollen, wenn Dinge brechen
Deine Nutzer brauchen kein Real-Time-Observability-Dashboard. Sie brauchen zwei Dinge: ist es für alle broken, und kennst du es?
Die minimale Status-Page hat drei Elemente:
Einen Status-Indikator mit höchstens drei States: operational, degraded, down
Einen Timestamp für den letzten Update des aktuellen States
Eine Zeile klares Deutsch, wenn etwas nicht stimmt
Nutzer, die während eines Incidents eine Status-Page checken, lesen keine Architecture Diagrams. Sie wollen aufhören, ihre eigene Setup zu debuggen, weil sie jetzt wissen, dass es nicht sie sind.
Das zu bauen dauert unter vier Stunden:
Eine statische HTML-Seite mit einem JavaScript-Snippet, das Status von einem Endpoint holt
Eine Supabase-Tabelle mit zwei Feldern: status (enum) und message (text)
Ein Cron Job, der den Status basierend auf deinem Health-Check-Result updated
Ein Admin-Endpoint hinter Auth, um eine manuelle Message zu schreiben, wenn nötig
Der harte Teil ist nicht das Build. Es ist die Gewohnheit, es während eines Incidents zu updaten, anstatt direkt ins Fix zu gehen. Das Update dauert 30 Sekunden und spart 15 Customer-Support-Emails.
Das andere Argument für das Selberbauen: Commercial Status-Page-Tools costen $30 bis $100 pro Monat für das, was fundamentally ein JSON-Endpoint und eine statische HTML-Seite ist. Baue es einmal, besitze es. Deine Nutzer brauchen kein Statuspage.io. Sie brauchen eine URL, die noch funktioniert, wenn deine Haupt-Domain down ist.
Post-Mortems, wenn du die einzige Person bist, um die Schuld zu geben
Post-Mortems in Enterprise-Settings sind dafür, nicht Individuen zu blamen und systemische Fehler zu identifizieren. Solo, du bist das System. Die Psychologie ist anders, aber die Practice zählt trotzdem.
Der Grund, Post-Mortems solo zu schreiben: du wirst die gleiche Klasse von Problem zweimal lösen, wenn du es nicht tust. Drei Monate später wirst du eine Database Query angucken, die locked hat, weil eines Index, das du nicht addiert hast, und du hast eine vague Memory, fix etwas wie das vorher, aber nicht erinnern, was.
Ein Fünf-Minuten-Format, das hält:
Was ist passiert (ein Absatz, nur Facts, kein Blame-Sprache)
Was du machtest, um es zu fixen
Eine Sache, um im System zu ändern
Eine Sache, um in deinem Process zu ändern
Schreib es an dem gleichen Ort wie deine Runbooks. Es wird der Input für das nächste Runbook-Update. Nach sechs Monaten schafft das einen lightweight Record von deinem System's Failure Modes, das kein Enterprise-Postmortem-Tool für einen Solo-Builder replica.
Sollst du das bauen oder bestehendes Tools zusammenstöpseln?
Die ehrliche Antwort hängt davon ab, wo du bist.
Wenn du null zahlende Customers hast: baue das ganze Ding selbst. Health-Check-Cron, Status-Page, Notion-Runbooks. Das ist das richtige Project, um die Patterns zu lernen. Es shipped an einem Wochenende. Es lehrt dich, was Incident Response wirklich braucht. Und wenn du später decide, es zu bauen und zu verkaufen als Product, du hast die Requirements auf dir selbst validiert, first.
Wenn du zahlende Customers hast, die auf Uptime heute zählen: starte mit bestehendem Tools. Wire Grafana Cloud Free Tier, set up ein Uptime Monitor, und öffne eine Notion-Runbook-Seite diesen Nachmittag. Du brauchst Coverage jetzt, nicht nachdem drei Wochenenden Bauen.
Das Piece, es wert, selbst zu bauen, egal Stage: die Status-Page. Besitze sie, host sie auf einer separaten Domain, baue sie diesen Wochenende. Alles andere kannst du aus bestehendem Free Tiers zusammenstöpseln, bis die Complexity Bauen rechtfertigt.
Die Lücke, die kein Incident-Response-Guide bespricht
Das Problem ist nicht Tooling. Es ist die 48 Stunden zwischen "Ich sollte Alerting setzen" und "Ich habw Alerting tatsächlich gesetzt."
Die meisten Solo-Dev-Stacks haben genug Observability Primitives, um ein erstes Incident-Response-Layer in einem einzelnen Tag zu bauen. Der Health-Check-Endpoint existiert irgendwo. Die Logs sind irgendwo. Die Deployment Pipeline hat etwas Error Handling. Was fehlt ist 90 Minuten focused Wiring: Health-Check zu Uptime-Monitor, Uptime-Monitor zu SMS oder Telegram Alert, eine Notion-Seite mit drei Runbooks, statische Seite mit einem Supabase Status Endpoint.
Das ist nicht das Project, das du zu Nutzern shippst. Das ist das Project, das du für dich shippst.
Baue es diesen Wochenende. Das erste Mal, wenn etwas um 3 Uhr morgens bricht und du es in 4 Minuten fixst anstatt 40 Minuten es zu finden, wirst du verstehen, warum Incident Response Best Practices existieren. Nicht weil Enterprise Teams es mandatierten, sondern weil die Alternative schlimmer ist.