3:17 Uhr. Das Handy summt. Der Uptime-Monitor — ein Service, der deine Webseite alle paar Minuten anpingt und dich benachrichtigt, wenn sie nicht mehr reagiert — sagt, dass deine App tot ist. Kein Team. Keine Bereitschaftsdienst. Kein SRE (Site Reliability Engineer, die Person, deren gesamte Aufgabe darin besteht, Dienste am Leben zu halten). Nur du, dein Laptop und Adrenalin.

Das ist kein hypothetischer Fall. Am 1. März erlitt AWS einen kaskadierenden Ausfall, der in der Region VAE begann und sich über US-EAST-1 ausbreitete, 38 Dienste lahmlegte und Solo-Gründern nur Fehler-Dashboards hinterließ, ohne jemanden anrufen zu können. Dann, am 27. März, verpatzte Cloudflare Pages die Verwaltung von benutzerdefinierten Domains für Stunden — was bedeutete, dass Gründer, die ihre Marketingseiten über Pages bereitgestellt hatten, zusehen mussten, wie ihre Domains mitten am Arbeitstag aus dem Internet verschwanden.

Ich war da. Mehrmals, als ein Capybara zugeben sollte. Bei den ersten Vorfällen habe ich Panik bekommen und es schlimmer gemacht. Jetzt habe ich ein Playbook. Es entfernt die Panik aus der Gleichung und ersetzt sie durch Schritte. Hier ist das ganze Ding. 📋

Schritt 0: Noch nichts reparieren

Kontraintuitiv. Deine App ist ausgefallen. Jede Sekunde kostet Geld, Ruf oder beides. Dein Instinkt schreit: Repariere es jetzt.

Aber das Gefährlichste, was du während eines Vorfalls tun kannst, ist, ohne Verständnis dafür zu handeln, was kaputt ist.

Ich habe Solo-Gründer beim SSH beobachtet — einer sicheren Terminalverbindung zu ihrem Server — die um 3 Uhr morgens einen Befehl aus dem Gedächtnis ausführen und dabei die Datenbank neben der App abstürzen ließen. Ein Problem wurde zu zwei. Der ursprüngliche Fix dauerte 20 Minuten. Die Datenbankwiederherstellung dauerte 6 Stunden.

Regel Null: Bevor du etwas anfasst, verbringe 2 Minuten damit, die Situation zu verstehen. Nicht 20 Minuten. Zwei. Lies den Fehler. Überprüfe die Logs. Formuliere eine Hypothese. Dann handle.

Schritt 1: Triage — 2 Minuten

Stelle drei Fragen:

Ist der Dienst vollständig ausgefallen oder teilweise beeinträchtigt? Schlage dein Gesundheitselement an — eine spezielle URL, die berichtet, ob die Kernelemente deines Apps funktionieren, wie ein eingebauter Herzschlag-Check. Wenn die App lädt, aber API-Aufrufe (Anfragen vom Frontend an dein Backend) fehlschlagen, ist das partiell. Wenn nichts lädt, dann vollständig. Dies bestimmt die Dringlichkeit.

Sind derzeit Nutzer betroffen? Überprüfe deine Analysen. Wenn es 3 Uhr morgens in deiner Zeitzone ist und deine Nutzer in derselben Zeitzone sind, haben es vielleicht fünf Leute bemerkt. Wenn deine Nutzer global sind, könnten Hunderte gerade auf eine Fehlerseite starren.

Wann hat es begonnen? Überprüfe dein Überwachungs-Dashboard. Wenn es vor 5 Minuten kaputt gegangen ist, ist es wahrscheinlich mit der letzten Änderung verbunden. Wenn der Dienst seit 3 Stunden schwankt und du gerade erst die Warnung erhalten hast, hast du eine Lücke in der Überwachung, die du morgen beheben musst.

Schreibe die Antworten auf. Ein Notizbuch, eine Nachricht an dich selbst, eine Textdatei. Dies wird zu deinem Vorfallsprotokoll — dem einzigen Dokument, das alles zu diesem Ausfall verfolgt. Du wirst dir am Morgen dafür danken.

Schritt 2: Kommunikation — 1 Minute

Selbst wenn niemand wach ist, poste ein Status-Update. Deine Statusseite, deine sozialen Medien, dein Discord — wo immer deine Nutzer nachsehen. Ein Satz:

"Wir sind uns eines Problems bewusst, das [Dienst] betrifft. Untersuchen es jetzt. Wird innerhalb von 30 Minuten aktualisiert."

Schweigen ist beängstigender als ein bekannter Ausfall. Nutzer, die "Untersuchung" sehen, warten geduldig. Nutzer, die nichts sehen, vermuten das Schlimmste und beginnen darüber zu posten. Eine Minute Kommunikation verschafft dir 30 Minuten ruhige Untersuchung. ⚙️

Schritt 3: Offensichtliches überprüfen — 5 Minuten

80% der Vorfälle bei kleinen Unternehmen lassen sich auf eine von fünf Ursachen zurückführen:

1. Festplatte voll. Führe df -h aus (zeigt den Festplattenspeicher in einem für Menschen lesbaren Format an). Wenn ein Dateisystem 100% liest, ist das dein Übeltäter. Schneller Fix: Finde und lösche übergroße Logdateien. du -sh /var/log/* zeigt die Verursacher.

2. Kein Speicher mehr. Führe free -h aus (zeigt den RAM-Verbrauch). Wenn der verfügbare Speicher nahe null ist, hortet etwas ihn. ps aux --sort=-%mem | head -10 listet die Top-Speicherverbraucher auf — das digitale Äquivalent zu der Suche, wer alle Lichter angelassen hat. Beende den aufgeblähten Prozess, starte den Dienst neu.

3. Prozess abgestürzt. Führe systemctl status dein-app aus — systemctl ist der Dienst-Manager von Linux, das Tool, das deine Anwendungen startet, stoppt und überwacht. Wenn es "inaktiv (tot)" oder "fehlgeschlagen" sagt, starte es neu: systemctl restart dein-app. Dann prüfe, warum es abgestürzt ist: journalctl -u dein-app --since "1 hour ago" (journalctl liest das Ereignistagebuch des Systems).

4. SSL-Zertifikat abgelaufen. SSL (Secure Sockets Layer) ist das Vorhängeschloss-Symbol in deinem Browser — es bedeutet, dass die Verbindung verschlüsselt ist. Diese Zertifikate laufen ab. Let's Encrypt Zertifikate halten 90 Tage. Wenn du die automatische Erneuerung vergessen hast, ist dies ein 3 Uhr morgens Problem, das darauf wartet, zu passieren. Fix: certbot renew && systemctl reload nginx. Richte die automatische Erneuerung mit Certbot an diesem Wochenende ein, damit dies nie wieder passiert.

5. DNS-Problem. DNS (Domain Name System) ist das Telefonbuch des Internets — es konvertiert "deineseite.com" in eine Serveradresse, die Computer finden können. Führe dig deineseite.com aus, um zu prüfen. Wenn es nicht aufgelöst wird, könnte es sein, dass dein DNS-Anbieter Probleme hat. Oder deine Domain ist abgelaufen. Ja, Domains laufen ab. Ich habe es bei finanzierten Startups gesehen.

Wenn keiner dieser fünf Fälle zutrifft, gehörst du zu den 20%, die echtes Debugging benötigen. Weiter zu Schritt 4.

Schritt 4: Das Überprüfung kürzlicher Änderungen — 5 Minuten

Etwas hat sich geändert. Dienste brechen nicht spontan — wie bei der Sanitärinstallation versagen sie, weil sich etwas verschoben hat. Frage dich:

  • Habe ich kürzlich etwas bereitgestellt? Bereitstellen bedeutet, neuen Code auf deinen Live-Server zu bringen. Überprüfe git log --since="24 hours ago", um kürzliche Codeänderungen zu sehen.
  • Habe ich eine Konfiguration geändert? Überprüfe die Änderungszeitstempel deiner Konfigurationsdateien.
  • Hat sich eine Abhängigkeit aktualisiert? Eine Abhängigkeit ist der Code eines anderen, auf den deine App baut — eine Bibliothek, ein Framework. Überprüfe deine Paket-Sperrdatei auf kürzliche Änderungen.
  • Hatte der Hosting-Anbieter ein Problem? Überprüfe deren Statusseite.

Die häufigste Antwort: Du hast etwas bereitgestellt. Der Fix: Zurücksetzen — zur vorherigen funktionierenden Version zurückkehren. Nicht debuggen. Zurücksetzen. Den Service zum Laufen bringen, morgen debuggen.

# Wenn du deine Releases taggst (Versionslabels wie v1.2.3):
git checkout v1.2.3
bash deploy.sh

# Wenn du noch keine Versionen taggst (heute damit anfangen):
git revert HEAD
bash deploy.sh

Das Zurücksetzen fühlt sich an, als gäbe man auf. Das tut es nicht. Es ist die professionellste Reaktion, die du machen kannst: Verfügbarkeit über Ego stellen. Den Code morgen mit Kaffee und Tageslicht fixen. 🍵

Schritt 5: Die 30-Minuten-Regel

Wenn du die Ursache — den eigentlichen Grund, warum etwas kaputtgegangen ist, nicht nur das Symptom — innerhalb von 30 Minuten nicht gefunden hast, eskaliere. "Aber ich bin ein Solo-Gründer. Eskalieren zu wem?"

  • Deinem Support des Hosting-Anbieters. Wenn du für verwaltetes Hosting zahlst, nutze es. Genau dafür ist es da.
  • Einem beauftragten Berater. Selbst $200 im Monat für "Ich kann dich zweimal im Jahr um 3 Uhr morgens anrufen" sind es wert.
  • Deiner Community. Ein relevanter Discord-Server, eine Slack-Gruppe, ein Forum. Poste den Fehler, deine Logs, was du versucht hast. Gute Communities reagieren schnell.
  • Einem AI-Assistenten. Füge den Fehler in Claude oder ChatGPT ein: "Hier ist mein Server-Fehlerprotokoll. Der Dienst ist um 3:17 Uhr abgestürzt. Hier ist, was ich überprüft habe: [Liste]. Was sollte ich noch prüfen?" Es wird nicht SSH in deinen Server, aber es kann diagnostische Schritte vorschlagen, die du übersehen hast.

Die 30-Minuten-Regel existiert, weil nach einer halben Stunde alleinigen Debuggings um 3 Uhr morgens dein Urteilsvermögen nachlässt. Du beginnst, zufällige Dinge zu versuchen. Zufällige Änderungen auf einem Live-Produktionsserver um 3 Uhr morgens — so verschwinden Daten dauerhaft.

Schritt 6: Der Morgen nach dem Vorfall

Du hast die Krise überlebt. Geh zurück ins Bett. Ernsthaft. Die Nachbesprechung — die strukturierte Analyse dessen, was schiefgelaufen ist und wie man es verhindert — passiert morgen. Mit Kaffee. Mit klarem Kopf. 🛁

Die Checkliste für morgen:

  1. Was ist kaputt gegangen? Ein Satz.
  2. Was war die Ursache? Nicht "Der Server ist abgestürzt", sondern "Falsch konfiguriertes Protokollrotation füllte die Festplatte zu 100%."
  3. Was war die Auswirkung? Dauer, betroffene Nutzer, verloren gegangene Einnahmen, wenn messbar.
  4. Was verhinderte eine schnellere Erkennung? Behebe diese Überwachungslücke.
  5. Was verhinderte eine schnellere Wiederherstellung? Füge diesen Schritt deinem Playbook hinzu.
  6. Was verhindert, dass dies erneut passiert? Diese Woche umsetzen. Nicht "eines Tages". Diese Woche.

Schreibe dies in eine Datei. incidents/2026-03-27.md. Du baust institutionelles Wissen auf — eine durchsuchbare Geschichte dessen, was vorher kaputt gegangen ist und was es repariert hat. Wenn der nächste Vorfall eintritt, hat dein vergangenes Ich bereits Notizen hinterlassen.

Die Vorfall-Vorbereitung

Die beste Vorfallreaktion erfolgt vor dem Vorfall. Hier ist, was du an diesem Wochenende einrichten solltest:

  • Uptime-Monitoring. UptimeRobot bietet eine kostenlose Version: 50 Monitore, 5-Minuten-Intervalle. Es pingt deine Seite und sendet dir eine SMS, wenn sie ausfällt. Einmal einrichten, vergessen. ✅
  • Protokollrotation. Konfiguriere logrotate — ein Linux-Dienstprogramm, das alte Protokolldateien automatisch komprimiert und löscht — für jedes Protokoll, das deine App erstellt. Festplatten füllen sich nicht, wenn Protokolle verwaltet werden.
  • Automatische SSL-Erneuerung. Certbot mit einem Cron-Job (eine geplante Aufgabe, die automatisch nach einem Zeitplan ausgeführt wird). Erneuere nie wieder manuell ein Zertifikat.
  • Automatische Backups. Datenbank-Dump zu S3 (Amazon's cloud storage) oder einem anderen Object Storage, alle 6 Stunden. Teste den Wiederherstellungsprozess mindestens einmal. Ein Backup, das du nie wiederhergestellt hast, ist eine Hoffnung, kein Backup.
  • Ein Zurücksetz-Skript. Ein Befehl, um zur vorherigen Version zurückzukehren. Kein Denken erforderlich um 3 Uhr morgens.

Gesamtdauer der Einrichtung: ungefähr 3 Stunden an einem ruhigen Samstagnachmittag. Diese 3 Stunden schützen dein Unternehmen, wenn das nächste Mal etwas im Dunkeln kaputt geht.

Die ruhigsten Gründer, die ich kenne, sind nicht ruhig, weil nichts kaputt geht. Es geht bei allen etwas kaputt. Sie sind ruhig, weil sie ein Playbook haben. Sie haben das schon durchgemacht. Sie wissen, was sie als nächstes tun sollen. Und sie wissen — aus Erfahrung tief in sich — dass Panik noch nie, nicht ein einziges Mal, einen Server repariert hat. 🫶

incident-response, devops, automation, solo-founder, infrastructure