Was ich vor dem Schlafengehen ausführe
Jeden Abend, bevor ich meinen Laptop zuklappe, führe ich einen einzigen Befehl aus. Er prüft 15.000 Seiten meiner Produktionsumgebung: jeden Blogbeitrag, jede Unternehmensseite, jeden programmatischen Leitfaden, jede Lokalisierungsvariante. Für jede Seite verifiziert er den HTTP-Status, misst die TTFB, überprüft den Cloudflare-Cache-Status und protokolliert sämtliche Fehler. Die vollständige Prüfung dauert etwa 6 Stunden. Sie läuft im Hintergrund, während ich schlafe.
Zusätzlich führe ich eine schnelle Prüfung der kritischen Pfade durch, die in 2 Minuten abgeschlossen ist: Health-Endpunkte, Sitemaps, umsatzrelevante Seiten, S-Tier-Unternehmenshubs, Marktseiten, programmatische Inhaltsindizes, i18n-Blogarchive. Diese beobachte ich aktiv. Schlägt etwas fehl, untersuche ich es, bevor ich schlafen gehe.
Die Routine erzeugt einen Bericht, der etwa so aussieht:
NIGHTCHECK -- 2026-03-27 (morning)
Overnight comprehensive: 16,228/16,602 ok (97.7%)
Avg TTFB: 715ms
S-tier companies: ALL PASS, ALL HIT
Markets: ALL PASS (89-175ms HIT)
i18n blogs: es 95ms HIT | ja 196ms HIT | de 181ms HIT
Niemand verlangt das von mir. Kein Ticket fordert es. Kein Sprint enthält „Nightcheck ausführen”. Die Routine existiert, weil es mir wichtig ist, ob die Seite funktioniert, wenn ich nicht hinschaue.
Warum jede Nacht
Die Seite ändert sich täglich. An einem einzigen Tag deploye ich mitunter 87 Commits: i18n-Übersetzungen, Crawl-Provider-Updates, CRO-Experimente, Performance-Fixes, Logo-Korrekturen. Jeder Commit wird einzeln getestet. Doch die Komposition von 87 Commits kann Fehler erzeugen, die kein einzelner Commit offenlegt.
Ein Übersetzungsbatch könnte die Blog-Sitemap über eine Rendering-Schwelle treiben. Ein neuer Provider könnte eine Unternehmensseite einführen, deren Rendering 14 Sekunden dauert. Eine Änderung der Cache-Header könnte dazu führen, dass Cloudflare eine zuvor schnelle Route nicht mehr zwischenspeichert. Ein CSS-Refactoring könnte ein Template in einer Sprache brechen, in anderen jedoch nicht.
Der Nightcheck fängt Kompositionsfehler ab. Nicht „Hat dieser Commit etwas kaputt gemacht”, sondern „Funktioniert die Seite, nachdem heute alles gelandet ist”. Die Unterscheidung ist entscheidend, denn Kompositionsfehler sind in CI unsichtbar. Jeder Commit besteht seine eigenen Tests. Dass 87 Commits ihre jeweiligen Tests bestehen, garantiert nicht, dass das Gesamtsystem funktioniert.
Was gemessen wird
Die Prüfung hat vier Stufen:
P0 Infrastruktur. Der Health-Endpunkt meldet sich als gesund mit verbundener Datenbank. Sitemaps liefern gültiges XML. Robots.txt und llms.txt sind vorhanden. Der RSS-Feed ist valide. Das sind die Dinge, die – wenn defekt – die Seite für Suchmaschinen unsichtbar machen.
P0 Umsatz. Startseite, Lebenslauf-Builder, Analyzer und Preisseite laden vollständig. Das sind die Seiten, deren Ausfall direkt Geld kostet. Der Lebenslauf-Builder ist historisch die langsamste Seite und erhält eine WARN-Schwelle bei 5 Sekunden.
P1 SEO-Oberfläche. Blogarchiv, Pillar-Hub-Seiten, Unternehmensverzeichnis, Stellensuche, alle fünf programmatischen Inhaltsindizes (Lebenslauf-Leitfäden, Gehaltsleitfäden, Anschreiben-Leitfäden, Interviewfragen, ATS-Keywords), vier i18n-Blog-Stichproben und alle 20 S-Tier-Unternehmenshubs. Das sind die Seiten, die organischen Traffic generieren. Ein 404 auf der Google-Unternehmensseite ist ein SEO-Vorfall.
P2 Vollständig. Jede URL in den Blog- und Unternehmens-Sitemaps. Das ist die 6-Stunden-Hintergrundprüfung. Sie fängt die Long-Tail-Fehler ab: ein einzelner Blogbeitrag, der wegen einer fehlerhaften Quellenangabe einen 500er wirft, eine Unternehmensseite, die wegen einer N+1-Abfrage bei einem großen Unternehmen in ein Timeout läuft.
Jede Seite wird mit curl und einem realistischen User-Agent-Header geprüft. Nacktes curl bekommt von Cloudflare einen 403. Der Cache-Status-Header wird zusammen mit dem HTTP-Status und der TTFB erfasst. Eine Seite kann 200 zurückgeben, aber DYNAMIC anzeigen, wo HIT stehen sollte – das bedeutet, die Cache-Regel ist falsch konfiguriert. Die TTFB-Messung bildet die tatsächliche serverseitige Latenz ab, nicht die Browser-Renderingzeit.
Der TTFB-Trend
Ich führe diese Prüfung seit März 2026 durch. Der TTFB-Trend erzählt die Performance-Geschichte:
| Datum | Avg TTFB | Langsamste Seite | Cache-Status |
|---|---|---|---|
| 21. Mär (nach Purge) | 1.156ms | Austin-Markt 14.290ms | ALL DYNAMIC |
| 23. Mär (Cache live) | 958ms | Märkte 2-3s | Meist HIT |
| 25. Mär (Query-Fix) | 715ms | ats-optimization 6,3s | Alle HIT |
| 27. Mär (stabil) | 715ms | zh-hans/blog 3,7s | 34/36 HIT |
Der Trend erfasst die Performance-Reise der Marktseiten: Der Cache-Purge legte das Problem offen (14,3s), Edge-Caching kaschierte es (89–175ms HIT), der Query-Shape-Fix behob die eigentliche Ursache (108ms Origin). Ohne den nächtlichen Trend hätte ich geglaubt, der Edge-Cache sei die Lösung. Die TTFB-Messungen bewiesen, dass das Origin-Rendering bei der Revalidierung immer noch langsam war – was das Query-Refactoring rechtfertigte.
Der Nightcheck hat das Performance-Problem nicht behoben. Er hat das Performance-Problem messbar gemacht, wodurch es behebbar wurde.
Was niemand sieht
Das Wertvollste am Nightcheck ist, dass er läuft, wenn niemand hinschaut. Es gibt keine Slack-Benachrichtigung für „16.228 Seiten über Nacht bestanden”. Kein Dashboard springt auf Grün. Der Bericht existiert in einer Logdatei, die ich am nächsten Morgen beim Kaffee lese.
Das Fehlen jeglicher Inszenierung ist der Punkt. Der Nightcheck ist keine performative Qualitätssicherung. Er ist keine Kennzahl fürs Standup. Er ist eine private Disziplin: Hat alles funktioniert, während ich geschlafen habe? Wenn ja, gut. Wenn nein, weiß ich genau, was wann fehlgeschlagen ist.
Die Disziplin wirkt kumulativ. Jede nächtliche Prüfung etabliert eine Baseline für den Vergleich am nächsten Tag. Ein TTFB-Anstieg von 50ms auf einer bestimmten Seite löst eine Untersuchung aus – nicht weil 50ms für Nutzer relevant wären, sondern weil der Anstieg darauf hinweist, dass sich etwas verändert hat. Vielleicht hat eine neue Abhängigkeit Latenz eingeführt. Vielleicht ist eine Cache-Regel abgelaufen. Vielleicht ist eine Datenbankabfrage mit dem Datenbestand gewachsen. Die nächtliche Baseline macht Drift sichtbar, bevor er zum Problem wird.
Das ist Compound Context angewandt auf den Betrieb. Jede nächtliche Prüfung hinterlegt einen Datenpunkt. Die Datenpunkte akkumulieren sich zu einem Trend. Der Trend macht Probleme sichtbar, die keine einzelne Prüfung offenlegen würde.
Die Routine ist der Standard
Ich könnte den Nightcheck als Cron-Job automatisieren und ein Dashboard überprüfen. Ich entscheide mich bewusst dafür, ihn manuell auszuführen, weil der Akt des Ausführens die Gewohnheit des Sich-Kümmerns aufrechterhält. In dem Moment, in dem die Prüfung zum Job eines anderen wird, zu einer Benachrichtigung, die ich wegwische, oder zu einem Dashboard, das ich nicht mehr prüfe, erodiert der Standard.
Der Standard ist nicht „Die Seite besteht automatisierte Prüfungen”. Der Standard ist „Ich habe persönlich verifiziert, dass die Seite funktioniert, bevor ich schlafen gegangen bin”. Der Unterschied liegt in der Verantwortlichkeit. Eine automatisierte Prüfung, die stillschweigend fehlschlägt, ist ein Bug in der Automatisierung. Eine manuelle Prüfung, die ich auslasse, ist eine Entscheidung darüber, was mir wichtig ist.
Ich führe sie jede Nacht aus, weil die Alternative darin besteht, darauf zu vertrauen, dass noch alles funktioniert. Vertrauen ohne Verifizierung ist Hoffnung. Hoffnung ist keine Betriebsstrategie.
FAQ
Wie lange dauert die vollständige Prüfung?
Die schnelle Prüfung der kritischen Pfade dauert 2–3 Minuten (36 Seiten mit TTFB- und Cache-Messung). Die umfassende Sitemap-Prüfung dauert 5–7 Stunden (über 15.000 Seiten). Die schnelle Prüfung läuft synchron; die umfassende Prüfung läuft im Hintergrund.
Warum kein Uptime-Monitoring-Dienst?
Uptime-Dienste prüfen, ob eine Seite 200 zurückgibt. Der Nightcheck prüft, ob eine Seite 200 mit dem korrekten Cache-Status, akzeptabler TTFB und erwarteter Inhaltsstruktur zurückgibt. Eine Seite, die 200 zurückgibt, aber 14 Sekunden mit DYNAMIC-Cache braucht, ist technisch erreichbar und betrieblich defekt.
Was passiert, wenn etwas fehlschlägt?
Bei Fehlern auf umsatzrelevanten Seiten oder Infrastrukturseiten untersuche ich die Ursache vor dem Schlafengehen. Bei Fehlern in der umfassenden Prüfung sichte ich das Protokoll am nächsten Morgen und priorisiere nach Seitentyp. Ein fehlerhafter Blogbeitrag hat niedrigere Priorität als ein fehlerhafter Unternehmenshub. Ein DYNAMIC-Cache auf einer hochfrequentierten Seite hat höhere Priorität als eine langsame TTFB auf einer wenig besuchten Seite.
Skaliert das?
15.000 Seiten sind der aktuelle Umfang. Die umfassende Prüfung ist I/O-gebunden (sequenzielle curl-Anfragen), nicht rechengebunden. Eine Verdoppelung der Seitenzahl verdoppelt die Laufzeit. Bei 30.000 Seiten würde die Prüfung 12 Stunden dauern, was immer noch in ein Nachtfenster passt. Darüber hinaus wäre paralleles Prüfen mit Rate-Limiting erforderlich.