Letzte Woche hat ein Fortune-500-Unternehmen geschätzte 14 Millionen Dollar in rund sechs Stunden verloren, weil ein einziges SSL-Zertifikat leise abgelaufen ist und es niemand bemerkt hat, bis Kunden auf Twitter zu meckern anfingen. Die Renewal-E-Mail wurde verschickt. Sie ging an einen geteilten Posteingang, den der vorherige DevOps-Lead besessen hatte. Er hatte das Unternehmen im März verlassen. Das Zertifikat lief an einem Samstag um 02:14 UTC ab. Der On-Call-Engineer des Plattform-Teams wurde nicht gepiepst, weil technisch nichts „down" war — die Seite lieferte Traffic aus, nur eben mit einer riesigen roten Browser-Warnung, die jeden zahlenden Kunden vergrault hat.

Das ist keine ungewöhnliche Geschichte. Es ist der häufigste vermeidbare Ausfall, den wir sehen, und er hat nichts mit Cloud-Architektur oder Container-Orchestrierung zu tun. Er passiert, weil die meisten Teams Domain-Monitoring, SSL-Monitoring und Uptime-Monitoring als drei separate Probleme behandeln, die von drei separaten Tools — oder, häufiger, von niemandem — gelöst werden. Dieser Guide führt dich durch den vollständigen 3-Schichten-Stack: was du auf jeder Schicht überwachen musst und wie du das verdrahtest, damit du nie wieder kalt erwischt wirst.

Der 3-Schichten-Monitoring-Stack#

Jede öffentlich erreichbare Web-Property hat drei unabhängige Failure-Modes, die alle Symptome wie „die Seite ist down" verursachen, aber komplett unterschiedliche Behebung verlangen:

Domain-Expiry — deine Registrierung läuft aus, der Registrar holt sich die Domain zurück und dein DNS löst nicht mehr auf. Recovery-Zeit: Stunden bis Tage. Kosten: katastrophal.
SSL-Zertifikats-Expiry — DNS löst noch auf, der Server läuft noch, aber das Zertifikat ist über sein notAfter-Datum hinaus. Browser blockieren die Verbindung. Recovery-Zeit: Minuten bei Automatisierung, Stunden bei Handarbeit.
Uptime / HTTP-Failure — DNS löst auf, das Cert ist gültig, aber der Server gibt 5xx zurück, läuft in einen Timeout oder wurde vom Hoster auf eine Parking-Page umgeleitet. Recovery-Zeit: hängt komplett von der Ursache ab.

Alle drei Schichten sind nötig, weil jede einen Failure abfängt, den die anderen verpassen. Uptime-Monitoring sagt dir, dass die Seite kaputt ist — aber erst, nachdem das SSL-Cert schon abgelaufen ist und Kunden schon abgewandert sind. Domain-Monitoring fängt die Registrierungs-Aussetzung Wochen ab, bevor die Domain tatsächlich fällt. SSL-Monitoring fängt das Cert-Problem 30 Tage ab, bevor die Browser-Warnung erscheint. Stapele alle drei und du hast geschichtete Verteidigung; lass eine weg und du hast ein Loch, durch das ein Lkw passt.

Schicht 1: Domain-Expiry-Monitoring#

Domain-Expiry ist der vermeidbarste Ausfall im Internet und gleichzeitig der peinlichste. Microsoft hat es geschafft. Google hat es geschafft (zweimal). Foursquare hat es geschafft. Sorenson Media hat es geschafft. Jeder dieser Vorfälle war ein mehrstündiger Ausfall, verursacht durch eine abgelaufene Kreditkarte oder eine Renewal-E-Mail, die in der falschen Mailbox landete.

Warum Registrar-E-Mails nicht reichen#

Registrare schicken Renewal-Erinnerungen. Sie gehen an die E-Mail-Adresse, die hinterlegt war, als die Domain zuerst registriert wurde — häufig das private Gmail eines Freelancers, der vor drei Jahren weg ist. Selbst wenn die Adresse stimmt, landen Registrar-E-Mails routinemäßig im Spam, und selbst wenn nicht, sehen sie genau wie die Phishing-E-Mails aus, die Renewal-Hinweise vortäuschen, also löschen Leute sie.

Auto-Renewal soll das lösen, aber Auto-Renewal scheitert auf drei stille Arten:

Die hinterlegte Kreditkarte läuft ab.
Die Karte wird wegen Betrugsverdacht abgelehnt (jährliche Renewals sehen für die ausstellende Bank ungewöhnlich aus).
Der Auto-Renewal-Toggle des Registrars wird bei einer Account-Migration oder einem Control-Panel-Redesign umgelegt.

Externes Monitoring ist der einzige verlässliche Backstop.

Wie man Domain-Expiry überwacht#

Das Protokoll ist RDAP (der moderne Ersatz für WHOIS) mit WHOIS-Fallback für TLDs, die RDAP noch nicht unterstützen. Ein täglicher Check reicht — Domain-Expiry-Daten ändern sich nicht im Minutentakt, und Registrare kümmern sich noch um eigene Grace Periods obendrauf.

# Schneller manueller Check via Kommandozeile
curl -s "https://rdap.org/domain/example.com" | jq '.events[] | select(.eventAction=="expiration")'

Steck das in einen Cron-Job und du hast einen einfachen Monitor. Aber du brauchst auch Alert-Schwellen, Retry-Logik für transiente WHOIS-Fehler und einen Weg, den Unterschied zwischen „abgelaufen" und „erneuert, aber das Datum hat sich noch nicht propagiert" zu erkennen. Deshalb ist ein gehostetes Tool meist schneller, als selbst zu bauen.

Die 30/14/7/2-Tage-Alert-Kadenz#

Sende Alerts zu vier Zeitpunkten: 30 Tage davor (Planung), 14 Tage davor (Aktion), 7 Tage davor (Eskalation) und 2 Tage davor (Panik). Häufiger erzeugt Müdigkeit. Seltener lässt keinen Puffer, falls der erste Alert verpasst wurde.

Was „abgelaufen" tatsächlich bedeutet#

Domains fallen nicht in der Sekunde, in der sie ablaufen. Die meisten TLDs haben eine mehrstufige Zeitleiste:

Tag 0–30 nach Ablauf: Grace Period. Die Domain ist suspendiert (kein DNS), aber der Inhaber kann zum normalen Preis erneuern.
Tag 30–60: Redemption Period. Renewal noch möglich, aber mit einer Redemption-Gebühr von $80–$200.
Tag 60–90: Pending Delete. Die Domain ist gesperrt und kann nicht erneuert werden.
Tag 90+: Dropped. Jeder kann sie registrieren.

Wenn eine deiner Domains in Redemption geht, wirst du wahrscheinlich dafür zahlen, kannst sie aber noch retten. Sobald sie in Pending Delete ist, rennst du gegen professionelle Drop-Catcher. Lass es nicht so weit kommen.

Nova Uptime hat einen kostenlosen Domain-Expiry-Checker für einmalige Lookups, und das Dashboard lässt RDAP täglich auf jeder überwachten Domain laufen — mit eingebauter 30/14/7/2-Tage-Alert-Kadenz.

Schicht 2: SSL-Zertifikats-Monitoring#

SSL-Zertifikats-Expiry ist mit Abstand die häufigste einzelne Ursache für „die Seite ist down"-Ausfälle. Microsoft Teams ging im Februar 2020 dunkel wegen eines abgelaufenen Auth-Zertifikats. Microsoft Azure hatte 2021 einen mehrstündigen Ausfall aus demselben Grund. Spotify hat es geschafft. LinkedIn hat es geschafft. Google Voice hat es geschafft. Roter Faden: Lets Encrypts 90-Tage-Rotationskadenz hat die ganze Industrie auf Automatisierung trainiert, und wenn die Automatisierung bricht, bricht sie leise.

Was du tatsächlich an einem Zertifikat überwachen musst#

Ein Zertifikat hat mehr Failure-Modes als nur notAfter. Ein vollständiger Monitor prüft:

notBefore und notAfter — das Gültigkeitsfenster. Alarmiere bei 30, 14, 7 und 2 Tagen vor notAfter.
Issuer-Chain-Vollständigkeit — dein Server muss die vollständige Intermediate-Chain ausliefern. Ein häufiger Deployment-Bug ist, nur das Leaf-Zertifikat zu schicken; das funktioniert in Chrome (das Intermediates cached), bricht aber in Firefox, mobilen Browsern und den meisten API-Clients.
Subject- und SAN-Match — die Subject Alternative Names des Zertifikats müssen den angefragten Hostname enthalten. Wildcard-Certs sind okay, aber stell sicher, dass der Wildcard die getroffene Subdomain tatsächlich abdeckt.
Cipher-Suite und TLS-Version — TLS 1.0 und 1.1 sind veraltet. TLS 1.2 ist die Untergrenze; TLS 1.3 ist bevorzugt. Schwache Cipher (RC4, 3DES) sollten deinen Check scheitern lassen.
OCSP-Staple-Anwesenheit — wenn du OCSP-Stapling konfiguriert hast und es aufhört zu funktionieren, siehst du Browser-Warnungen selbst bei gültigem Cert.

Häufige SSL-Failure-Modes#

In grober Reihenfolge der Häufigkeit, die Failures, die wir in Produktion sehen:

Zertifikat abgelaufen. Auto-Renewal-Hook hat nicht gefeuert. Cron-Job ist gestorben. Renewal hat geklappt, aber das neue Cert wurde vom Webserver nicht neu geladen.
Intermediate-Zertifikat fehlt oder falsch. Certbot generiert die Chain, aber ein Deploy-Skript überschreibt sie, oder ein Reverse-Proxy ist mit ssl_certificate statt ssl_certificate fullchain.pem konfiguriert.
Hostname-Mismatch. Cert wurde für example.com ausgestellt, aber der Nutzer trifft www.example.com und der SAN enthält kein www.
Falsches Cert ausgeliefert (SNI-Bug). Server hostet mehrere Sites und das Default-VHost-Cert wird statt des Per-Site-Certs ausgeliefert.
Clock-Drift. Server-Uhr ist mehr als ein paar Minuten daneben, sodass gültige Certs als abgelaufen oder noch nicht gültig erscheinen.

Empfohlene Check-Frequenz#

Täglich ist das Minimum. Für umsatzkritische Endpoints — Payment-APIs, Login-Flows, eingebettete Widgets — ist stündlich vernünftig. Der Check ist günstig (ein einzelner TLS-Handshake pro Endpoint), Frequenz ist also selten der Engpass.

Reale Cert-Disaster#

Das Muster wiederholt sich jedes Jahr:

Microsoft Teams, Feb 2020 — abgelaufenes internes Zertifikat hat Teams für Stunden während der Kernarbeitszeit lahmgelegt.
Microsoft Azure, März 2021 — TLS-Cert-Expiry verursachte einen 14-stündigen Ausfall, der die Authentifizierung über mehrere Microsoft-Properties hinweg betroffen hat.
Spotify, mehrere Jahre — abgelaufene Zertifikate haben mindestens drei öffentlich sichtbare Ausfälle verursacht.
GitHub-Status-Page — irgendwann hat die Status-Page selbst ein abgelaufenes Cert ausgeliefert, was die Art Ironie ist, bei der Engineers nervös lachen.

Keiner dieser Firmen fehlte das Engineering-Talent, Expiry zu verhindern. Ihnen fehlte das geschichtete Monitoring, das es abgefangen hätte. Nova Uptimes kostenloser SSL-Expiry-Checker macht einen einmaligen Check; das Dashboard läuft denselben Check planmäßig und alarmiert bei 30/14/7/2 Tagen.

Schicht 3: Uptime / HTTP-Monitoring#

Uptime-Monitoring ist die Schicht, die alles fängt, was die ersten beiden Schichten nicht antizipieren können: Server-Crashes, schiefgelaufene Deploys, Memory-Lecks, erschöpfte Database-Connection-Pools, DDoS, Hosting-Provider-Probleme, DNS-Fehlkonfiguration, CDN-Cache-Poisoning und die fünfzig anderen Failure-Modes, die nicht in einem Cert oder einem Registrar-Record auftauchen.

Was zu prüfen ist#

Ein nützlicher HTTP-Monitor prüft mehr als nur „hat der Request 200 zurückgegeben?". Konkret:

Status-Code — alles im 2xx-Bereich ist gesund, 3xx könnte ein Redirect auf eine Parking-Page sein (verdächtig), 4xx und 5xx sind Failures.
Response-Zeit — p95-Latenz, die nach oben kriecht, ist der frühste Indikator für ein Datenbank- oder CPU-Problem.
Response-Body-Inhalt — idealerweise prüfst du auf einen bekannten guten String (ein Heartbeat-Endpoint, der {"status":"ok"} zurückgibt), damit du den Fall erwischst, in dem der Server 200 zurückgibt, aber die Anwendung gecrasht ist und eine Fehlerseite ausliefert.
TLS-Handshake-Erfolg — faltet einen Teil von Schicht 2 in denselben Check.
DNS-Auflösungszeit — eine langsame DNS-Auflösung ist oft das erste Zeichen eines CDN- oder Upstream-Problems.

Warum Multi-Region zählt#

Ein Single-Region-Monitor ist eine Maschine für falsches Vertrauen. Dein Monitor lebt in us-east-1. Deine Anwendung auch. AWS hat ein regionales Problem. Beide gehen down. Dein Monitor meldet „Site up", weil der Monitor tot ist. Multi-Region-Monitoring (oder mindestens Cross-Region — Monitor in us-west, wenn deine App in us-east ist) eliminiert diese Klasse von False Negative.

Failure-Screenshots aufnehmen#

Wenn ein Check fehlschlägt, mach einen Screenshot der gerenderten Seite. Der ist Gold wert in Postmortems, weil er exakt festhält, was der Nutzer im Moment des Failures gesehen hat — nicht, was die Logs sagen, nicht, was der synthetische Monitor denkt, sondern was auf dem Bildschirm war. War es ein 502? Eine Wartungsseite? Ein leerer weißer Bildschirm? Ein Cloudflare-Challenge? Du weißt es in zwei Sekunden statt in zwei Stunden.

Multi-Channel-Alerts#

E-Mail ist nötig, aber nicht ausreichend. E-Mail wird gepuffert, gebatcht und ignoriert. Kritische Alerts müssen E-Mail umgehen und einen Menschen direkt erreichen. Nova Uptime unterstützt E-Mail, WhatsApp (Baileys, keine Per-Message-Gebühren) und ausgehende Webhooks (HMAC-signiert), um sich in PagerDuty, Opsgenie, Slack oder dein Incident-Tooling zu integrieren.

Den vollen Stack mit Nova Uptime einrichten#

Hier das praktische Setup von vorne nach hinten, ungefähr in der Reihenfolge, in der du es machen würdest.

1. Domain hinzufügen#

Füg die URL in das Dashboard ein. Nova Uptime macht sofort einen HTTP-Check, einen SSL-Handshake, einen RDAP/WHOIS-Lookup für Domain-Expiry und einen Favicon-Fetch. Du siehst alle vier Ergebnisse innerhalb von 60 Sekunden.

2. Check-Intervall konfigurieren#

Free-Plan: 15-Minuten-Intervall. Pro-Plan: bis runter auf 59 Sekunden. Agency-Plan: dieselbe 59-Sekunden-Untergrenze mit höheren Domain-Limits. Für die meisten Marketing-Sites sind 5-Minuten-Checks okay. Für Payment-APIs sind 59-Sekunden-Checks richtig.

3. WhatsApp verbinden#

Unter Settings → WhatsApp scannst du einmal den QR-Code. Ab dann kann jeder Alert an deine WhatsApp-Nummer gesendet werden, ohne Per-Message-Kosten (Free-Plan = 1 Nummer, Pro = 3, Agency = 5). WhatsApp-Zustellung ist schneller und schwerer zu ignorieren als E-Mail.

4. CC-E-Mails fürs Team hinzufügen#

Auf der Settings-Seite jeder Domain fügst du bis zu 5 CC-E-Mails hinzu. Das ist die Team-Verteilerliste für diese spezifische Domain — die Homepage alarmiert vielleicht den Marketing-Lead, die API alarmiert den On-Call-Engineer.

5. Alerts mit einem absichtlichen Failure testen#

Das Beste, was du nach dem Verdrahten von Monitoring tun kannst, ist, es einmal absichtlich kaputtzumachen. Zeig eine überwachte URL auf einen Hostname, der nicht existiert, oder zieh kurzzeitig das Cert zurück, und sieh zu, wie der Alert feuert. Tut er das nicht, hast du gerade einen Config-Bug zum günstigstmöglichen Zeitpunkt entdeckt.

6. Wann upgraden#

Free-Tier deckt 5 Domains ab und reicht für persönliche Projekte und kleine Teams. Die zwei Gründe zum Upgrade sind: (a) du bist über 5 Domains hinausgewachsen, oder (b) du brauchst Check-Intervalle unter 15 Minuten. Preisdetails auf der Pricing-Seite.

Alert-Strategie: Müdigkeit vermeiden#

Der schnellste Weg, einen Monitoring-Stack zu ruinieren, ist überzualarmieren. Nach drei False Positives in einer Woche fängt jeder Engineer im Team an, den Channel zu ignorieren, und jetzt hast du Monitoring mit negativem Wert.

Drei Faustregeln:

Schweregrad staffeln. Domain-Expiry-Warnungen 30 Tage davor sind informativ — sie gehen nur an E-Mail. SSL-Warnungen 7 Tage davor sind Warnungen — E-Mail plus ein Slack-Channel. Site down für 2+ Minuten ist kritisch — WhatsApp, Telefon-Vibrieren, On-Call piepsen. Schick nicht alles an jeden Channel.

Pause bei geplanter Wartung. Wenn du deployst, eine Datenbank-Migration durchschiebst oder ein Cert rotierst, pausiere den relevanten Monitor für das Wartungsfenster. Nova Uptime hat Per-Domain-Pause und einen globalen „Pause all notifications"-Toggle in den Settings. (Monitoring läuft weiter — nur Benachrichtigungen werden pausiert, du kannst die Logs danach reviewen.)

Ongoing-Down-Alerts ratenlimitieren. Sobald eine Domain als down gemeldet wurde, brauchst du nicht jede Minute eine Benachrichtigung. Nova Uptime sendet den Initial-Alert, dann einmal pro Stunde Ongoing-Erinnerungen (über E-Mail und WhatsApp), bis die Domain sich erholt. Der Recovery-Alert feuert immer sofort.

Per Channel routen. E-Mail ist gut für Digests, Wochenreports und informative Alerts. WhatsApp ist gut für kritische Alerts, die in den nächsten 5 Minuten einen Menschen brauchen. Webhooks sind gut für Automatisierung (PagerDuty-Incidents auto-erstellen, in Slack posten, Runbooks triggern).

Ein paar bemerkenswerte Fälle, die du kennen solltest:

LinkedIn, Oktober 2022 — mehrstündige SSL-Expiry auf einer Subdomain, die die Nachrichten-Zustellung betroffen hat. Die Hauptseite blieb up; das Problem war versteckt, bis Kunden es meldeten.
Cloudflare, 2021 — eine Fehlkonfiguration der Intermediate-Zertifikatskette verursachte breite Probleme für Sites, die Cloudflares Edge-Cert-Service nutzten. Das Leaf-Cert war gültig; die Chain war unvollständig.
GitHub Status, mehrere Incidents — die Status-Page selbst hat zu verschiedenen Zeitpunkten abgelaufene Certs ausgeliefert oder Domain-Registrierungs-Probleme gehabt. Lektion: Das Meta-Monitoring (das Ding, das dir sagt, wann das Monitoring kaputt ist) ist selbst etwas, das überwacht werden muss.

Setup-Checkliste#

Geh diese Liste durch und du hast geschichtete Verteidigung:

Fazit#

Domain-Monitoring, SSL-Alerts und Uptime-Monitoring sind nicht drei Tools, die du zusammenschraubst. Sie sind drei Schichten einer Defense-in-Depth-Strategie, und jeder Monitoring-Stack, der nur eine oder zwei davon abdeckt, lässt dich irgendwann im schlechtesten Moment im Stich. Nova Uptime gibt dir alle drei in einem Dashboard mit E-Mail- und WhatsApp-Alerts auf dem Free-Plan. Kostenlos anmelden und in unter fünf Minuten bis zu fünf Domains überwachen.

Domain-Monitoring mit SSL-Alerts: Der komplette 2026er-Setup-Guide