Zum Hauptinhalt springen

Kostenloses Website-Monitoring mit Echtzeit-Alarmen

Das HTTP-Monitoring-Tool, das Ihre URL alle 5 Minuten prüft

Eine Uptime von 99,9 % lässt 43 Minuten Ausfall pro Monat zu. Man muss nur wissen, wann sie anfallen. CaptainDNS führt alle 5 Minuten einen HTTP-Check auf jedem Ihrer Endpunkte aus, von Probes in der Europäischen Union, meldet sich per E-Mail, sobald eine Antwort aus dem Rahmen fällt, und zeigt Uptime, p95-Latenz und eine 30-Tage-Heatmap. 1 überwachte URL im kostenlosen Plan, ohne Kreditkarte.

Weiterführende Tools

Ergänzen Sie die laufende Überwachung durch eine punktuelle Prüfung Ihrer Endpunkte.

Wichtige Funktionen

Check alle 5 Minuten

Ihre URLs werden kontinuierlich aus unseren europäischen Regionen geprüft. Die Latenz wird bei jedem Check gemessen, die HTTP-Codes werden erfasst und Timeouts erkannt, sobald die konfigurierte Wartezeit überschritten ist.

E-Mail-Alarme bei jedem Vorfall

Benachrichtigung, sobald ein Fehlschlag bestätigt ist: 5xx-Code, Timeout, DNS-Fehler, abgelaufenes TLS-Zertifikat. Die Erinnerungen folgen mit mindestens einer Stunde Abstand, niemals ein Alarm pro fehlgeschlagenem Check.

Uptime % und p95-Latenz

Metriken über 24 Stunden, 7 Tage und 30 Tage. Heatmap, die jeden Zeitraum je nach Check-Status grün, orange oder rot färbt.

Auto-Deaktivierung nach 7 Tagen

Nach 5 aufeinanderfolgenden Tagen ohne einen einzigen erfolgreichen Check sendet CaptainDNS eine Warnung und deaktiviert den Monitor am 7. Tag. Keine Alarme mehr auf dauerhaft toten URLs.

Anpassbarer Cron

Definieren Sie einen Cron-Ausdruck für fortgeschrittene Fälle: Check jede Minute während der Geschäftszeiten, punktuelle Überwachung, ausgeschlossenes Wartungsfenster.

Hosting und Verarbeitung in der EU

Die Checks werden aus der Europäischen Union ausgeführt, Datenbank und Backups liegen in Frankreich, das Dashboard setzt keine Tracking-Cookies.

Sicherheitslage des Ziels

Regelmäßige Analyse des SSL/TLS-Zertifikats, des HSTS, der Sicherheits-Header, des Gewichts Ihrer Seiten und der Phishing-Reputation. Eine 100-Punkte-Bewertung macht jede Verschlechterung sichtbar. Ab dem Solo-Plan.

Multi-Regionen-Überwachung

Ihre Checks werden aus Europa, den USA und Asien-Pazifik ausgeführt. Die Erkennungsstrategie Konsens gleicht die Regionen ab und unterscheidet so einen globalen Ausfall von einer lokalen Netzwerkstörung.

Warum die Verfügbarkeit Ihrer URLs überwachen?

Eine Uptime von 99,9 % lässt 43 Minuten Ausfall pro Monat zu. Man muss nur wissen, wann sie anfallen. Ohne automatische Überwachung fällt eine Störung erst durch die E-Mail eines Kunden auf, oft mehrere Stunden nach ihrem Beginn. In dieser Zeit ist der Conversion-Funnel unterbrochen, Formulare werden nicht mehr versendet und der Googlebot sammelt 5xx-Antworten ein.

Der Mechanismus ist einfach: eine Anfrage in regelmäßigen Abständen, eine erfasste Antwort, ein Alarm, sobald sie aus dem Rahmen fällt.

Vier Gründe, Ihre Endpunkte zu überwachen:

  • Vor den Nutzern erkennen: ein Anwendungsabsturz oder ein Ausfall beim Hoster fällt innerhalb weniger Minuten auf, nicht erst beim ersten Support-Ticket.
  • Das Ranking schützen: anhaltende 5xx-Fehler auf indexierten Seiten verschlechtern Crawling und Platzierung.
  • Kritische Pfade abdecken: Checkout-Seite, REST-Endpunkt, Kontaktformular.
  • Migrationen absichern: der Check-Verlauf zeigt, wann die Regression aufgetreten ist.

So nutzen Sie das HTTP-Monitoring in 3 Schritten

Schritt 1: URL zur Überwachung hinzufügen

Geben Sie die vollständige URL des Endpunkts ein, inklusive Protokoll:

https://captaindns.com/de/pricing

Beginnen Sie mit den URLs, deren Ausfall sofort Geld kostet: Startseite, Checkout, öffentliche API.

Schritt 2: Intervall und Alarmbedingungen festlegen

Drei Einstellungen genügen in den meisten Fällen:

  • Intervall: standardmäßig 5 Minuten. Für Sonderfälle übernimmt ein Cron-Ausdruck (nur Geschäftszeiten, ausgeschlossenes Wartungsfenster).
  • Erwarteter HTTP-Code: standardmäßig jeder 2xx-Code. Tragen Sie einen genauen Code ein, wenn der Endpunkt exakt diesen liefern soll, etwa 301 für eine Weiterleitung oder 401 für einen geschützten Endpunkt.
  • E-Mail-Alarme: ein Schalter pro Monitor. Die E-Mails gehen an die Adresse Ihres CaptainDNS-Kontos, eine Empfängeradresse pro Monitor gibt es nicht. In den kostenpflichtigen Plänen kann ein HTTPS-Webhook zusätzlich nach Slack, Discord oder PagerDuty routen.

Schritt 3: Check starten und Metriken lesen

Lösen Sie einen sofortigen Check aus, um die Konfiguration zu prüfen. Das Ergebnis erscheint innerhalb weniger Sekunden mit HTTP-Code, gesamter Antwortzeit und gegebenenfalls Fehlercode. Danach aggregiert das Dashboard die Uptime über 24 Stunden, 7 Tage und 30 Tage, die durchschnittliche Antwortzeit und den p95, die Heatmap und die Liste der Vorfälle.


So funktioniert ein HTTP-Check

Jeder Check läuft in vier Phasen ab, und jede davon kann unabhängig von den anderen fehlschlagen.

1. DNS-Auflösung

Zuerst wird der Domainname der URL aufgelöst. Eine fehlgeschlagene Auflösung (NXDOMAIN, SERVFAIL, Timeout) markiert den Check als dns_error und löst einen Alarm aus.

2. TCP-Aufbau und TLS-Handshake

Zur aufgelösten IP-Adresse wird eine TCP-Verbindung aufgebaut. Bei HTTPS prüft der TLS-Handshake die Zertifikatskette, das Ablaufdatum und die Übereinstimmung mit dem Hostnamen. Ein abgelaufenes oder ungültiges Zertifikat markiert den Check als tls_invalid.

3. HTTP-Anfrage und Lesen der Antwort

Die Anfrage wird gesendet (standardmäßig GET oder die konfigurierte Methode). CaptainDNS wartet bis zur konfigurierten Frist, standardmäßig 10 Sekunden und höchstens 30. Danach gilt der Check als timeout. Erfasst werden der HTTP-Code und die gesamte Antwortzeit.

4. Auswertung und Alerting

Ein Check gilt als up, wenn der HTTP-Code ein 2xx ist oder wenn er exakt dem erwarteten Code entspricht, sofern Sie einen angegeben haben. Ein 5xx, ein Code außerhalb des Erwarteten, ein Timeout oder ein Netzwerkfehler markieren ihn als down. Ein bestätigter Wechsel von up zu down löst einen Alarm aus, die Rückkehr zu up eine Recovery-E-Mail, die den Vorfall abschließt.


Ihre Website aus mehreren Regionen überwachen

Ein Monitor mit nur einer Region erzählt bloß die halbe Wahrheit. Liegt Ihre einzige Probe in Europa und hat ein transatlantischer Transit-Anbieter ein Problem, erscheint die Website als up, während Ihre amerikanischen Kunden sie nicht mehr erreichen. Umgekehrt lässt eine lokale Netzwerkstörung in der Nähe der Probe einen globalen Ausfall vermuten.

CaptainDNS führt die Checks aus drei Zonen auf der Infrastruktur von Fly.io aus: Europa (eu) für die EU, das Vereinigte Königreich und Nordafrika, USA (us) für Nordamerika und einen Teil Lateinamerikas, Asien-Pazifik (apac) für Japan, Korea, Südostasien und Ozeanien. Wie viele Regionen sich aktivieren lassen, hängt vom Plan ab: eine einzige (Europa) in den Einstiegsplänen, bis zu drei darüber. Siehe Pläne und Preise.

Drei Strategien zur Ausfallerkennung

Mehrere Probes werfen eine Frage auf: ab wie vielen fehlgeschlagenen Regionen gilt die Website als DOWN?

  • Konsens (Standard): der Monitor gilt als DOWN, wenn mindestens die Hälfte der Regionen fehlschlägt. Fehlalarme durch eine isolierte Netzwerkstörung werden gefiltert, ein echter Ausfall wird trotzdem schnell gemeldet.
  • Strikt: eine einzige fehlgeschlagene Region genügt. Passend für kritische Monitore (Zahlung, Echtzeit-API), bei denen jedes regionale Flapping gemeldet werden soll, auch ein kurzes.
  • Einstimmig: der Monitor gilt erst dann als DOWN, wenn alle Regionen fehlschlagen. Passend für verteilte Infrastrukturen (Active-Active-CDN, Edge Compute), die regionale Flaps verkraften.

Mit einer einzigen aktiven Region liefern alle drei Strategien dasselbe Ergebnis: die Wahl wird erst ab zwei Regionen relevant.


Die Sicherheitslage Ihrer Website analysieren

Ein Uptime-Monitor beantwortet nur eine Frage: antwortet die Website? Über die Qualität dessen, was sie ausliefert, sagt er nichts. Eine Website kann monatelang 200 in 80 ms zurückliefern, mit einem Zertifikat kurz vor dem Ablauf, mit einem HSTS-Header, den ein Reverse-Proxy-Deployment entfernt hat, oder mit einer wieder auf unsafe-inline gestellten CSP. Die Sicherheitslage-Überwachung schließt diese Lücke: Sie berechnet in regelmäßigen Abständen eine Bewertung für die bereits überwachten URLs und schlägt Alarm, sobald diese sich verschlechtert.

Die fünf analysierten Komponenten

  • SSL/TLS-Zertifikat: Gültigkeit, Zertifikatskette, Ablaufdatum, akzeptierte TLS-Versionen.
  • HSTS: Vorhandensein des Headers, max-age-Dauer, Abdeckung der Subdomains, Preload-Status.
  • Sicherheits-Header: CSP, X-Frame-Options, Referrer-Policy und die weiteren Header der mehrschichtigen Verteidigung.
  • Seitengewicht: Umfang der geladenen Ressourcen, ein Signal für Performance-Hygiene.
  • Phishing-Reputation: Abgleich der überwachten URL mit Bedrohungsdatenbanken (Google Web Risk, URLhaus, VirusTotal), einmal pro Tag durchgeführt.

Sie wählen die zu überwachenden Komponenten aus, mindestens eine. Das Abwählen einer Komponente schließt sie aus der Berechnung aus, ohne die Bewertung zu verfälschen: ihr Gewicht wird auf die verbleibenden Komponenten umverteilt.

Die 100-Punkte-Bewertung in zwei Bereichen

Die Gesamtbewertung ist ein gewichteter Durchschnitt aus Sicherheit (80 Punkte), die Zertifikat, HSTS, Header und Reputation abdeckt, und Performance (20 Punkte), die das Seitengewicht abdeckt. Jede Komponente wird in eine lesbare Stufe eingeordnet: Hervorragend, Gut, Verbesserungswürdig oder Kritisch. Die Sicherheit wiegt viermal so schwer, denn ein defektes Zertifikat setzt Ihre Besucher einem Risiko aus, während eine schwere Seite sie nur ausbremst.

Häufigkeit, Referenzwert und Alarme

Bei der ersten Analyse legt CaptainDNS einen Referenzwert fest, ohne einen Alarm zu senden. Danach löst jede nennenswerte Änderung eine Zusammenfassung Komponente für Komponente aus, und vor dem Ablauf des Zertifikats wird ein präventiver Alarm versendet, gestuft 30, 14, 7, 3 und 1 Tag vorher. Ein eigener Tab zeigt die aktuelle Bewertung und den Änderungsverlauf über 180 Tage.

Die Analyse läuft ausschließlich aus Europa, denn Zertifikat, HSTS und Header hängen nicht vom Beobachtungspunkt ab. Sie ist ab dem Solo-Plan verfügbar; die kürzeste wählbare Analysehäufigkeit und die Anzahl der Monitore pro Root-Domain hängen vom Plan ab (siehe Pläne und Preise).

Die Bewertung und ihre Komponenten lassen sich auch auf einer öffentlichen Statusseite veröffentlichen: Sie wählen Monitor für Monitor, welche Elemente sichtbar sind (100-Punkte-Bewertung, Zertifikat, HSTS, Header, Seitengewicht, Reputation). Standardmäßig wird nichts veröffentlicht.


E-Mail-Alarme und Webhooks

Ein Alarm wird ausgelöst, sobald ein Check die erwarteten Bedingungen verlässt. Die folgende Tabelle fasst zusammen, was einen Alarm auslöst und was nicht.

FehlertypBeschreibungAlarm
5xxHTTP-Code 500-599 (Serverfehler)Ja
Unerwarteter 4xxHTTP-Code 400-499, der nicht dem erwarteten Code entsprichtJa
TimeoutKeine Antwort innerhalb der konfigurierten WartezeitJa
DNS-FehlerNXDOMAIN, SERVFAIL oder DNS-TimeoutJa
TLS-FehlerAbgelaufenes Zertifikat, Hostname-Mismatch, unvollständige KetteJa
TCP refusedConnection refused am ZielportJa
Konforme Antwort2xx-Code oder exakt der erwartete Code, falls konfiguriertNein

Drei Schutzmechanismen gegen Rauschen

Eine flatternde Website kann Dutzende Alarme pro Stunde erzeugen. Drei Mechanismen verhindern das:

  1. Bestätigung durch 2 aufeinanderfolgende Fehlschläge: standardmäßig geht kein Alarm heraus, bevor zwei Checks in Folge fehlgeschlagen sind. Die Schwelle lässt sich in der Konfiguration des Monitors von 1 bis 10 Fehlschlägen einstellen.
  2. Progressiver Abstand der Erinnerungen: ein Alarm zu Beginn der Downtime, danach höchstens eine Erinnerung pro Stunde während der ersten 24 Stunden des Vorfalls und eine Erinnerung pro 24 Stunden darüber hinaus. Eine Recovery-Meldung schließt den Vorfall bei der Rückkehr ab.
  3. Auto-Deaktivierung: ein Tag gilt als verloren, wenn an diesem Tag kein einziger Check erfolgreich war. Am 5. verlorenen Tag in Folge geht eine Warn-E-Mail heraus, am 7. wird der Monitor deaktiviert.

Die Alarm-E-Mail enthält die betroffene URL, den HTTP-Code oder Fehlertyp, die Latenz des letzten gültigen Checks, den Zeitstempel in UTC und Ortszeit sowie einen Link zum Dashboard. Kein Tracking-Pixel.

HTTP-Webhooks

Für das Routing nach Slack, Discord, PagerDuty oder in ein internes Incident-Management-System ist E-Mail nicht der passende Kanal. In den kostenpflichtigen Plänen empfangen ein oder mehrere HTTPS-Endpunkte die Events als JSON-POST, signiert über ein gemeinsames Secret, damit die Herkunft auf der Empfängerseite geprüft werden kann. Jeder Webhook abonniert die Kategorien, die ihn betreffen, insgesamt drei: Monitoring, Deployment und DNS. Die Verfügbarkeitsalarme gehören zu Monitoring und können in einen Slack-Ops-Channel gehen, während ein zweiter Webhook ausschließlich die Deployment-Ereignisse empfängt. Schlägt die Zustellung fehl, versucht CaptainDNS es mit exponentiellem Backoff erneut und protokolliert jeden Versuch.


Uptime-Metriken, p95-Latenz und 30-Tage-Heatmap

Das Dashboard aggregiert die einzelnen Checks zu sechs Metriken.

MetrikZeitraumBeschreibung
Uptime %24 h / 7 T / 30 TProzentsatz erfolgreicher Checks im Zeitraum
Durchschnittliche Latenz24 h / 7 T / 30 TDurchschnittliche Antwortzeit in Millisekunden
p95-Latenz24 h / 7 T / 30 T95. Perzentil: 95 % der Checks antworten unter diesem Wert
Minimale und maximale Latenz24 h / 7 T / 30 TSchnellste und langsamste Antwortzeit im Zeitraum
Gesamtchecks24 h / 7 T / 30 TAbsolute Anzahl ausgeführter Prüfungen
Vorfälle30 TageDowntime-Bereiche mit Dauer und Fehlercode

Die p95-Latenz ist der richtige Indikator für die wahrgenommene Performance. Der Durchschnitt verdeckt die Spitzen, p95 zeigt, was Ihre Nutzer in den 5 % schlechtesten Fällen erleben.

30-Tage-Heatmap

Die Heatmap stellt die letzten 30 Tage als farbiges Raster dar. Jede Zelle deckt immer einen vollen UTC-Tag ab, nie ein feineres Fenster, und nimmt ihre Farbe von der Uptime des Tages: grün ab 99,5 %, orange zwischen 90 und 99,5 %, rot unter 90 %, grau, wenn keine Daten vorliegen.

Verlauf und Aufbewahrung

Jeder einzelne Check bleibt im kostenlosen Plan 30 Tage lang einsehbar: Zeitstempel, HTTP-Code, gesamte Antwortzeit und gegebenenfalls Fehlercode. Danach werden die Einzelchecks automatisch gelöscht. In höheren Plänen verlängert sich die detaillierte Aufbewahrung, gedeckelt auf 90 Tage in allen Plänen. Die Tagesaggregate (Uptime, durchschnittliche Latenz) werden nicht bereinigt; wie weit eine öffentliche Statusseite zurückblicken darf, hängt vom Plan ab, von 30 Tagen im kostenlosen Plan bis zu mehreren Hundert Tagen darüber. Wird ein Monitor gelöscht, verschwinden alle seine Daten.


Konkrete Anwendungsfälle

Fall 1: Deployment legt die Startseite lahm

Symptom: Ein Deployment am Freitagabend geht in Produktion. Am Montagmorgen meldet ein Kunde, dass das Kontaktformular seit dem Wochenende einen Fehler zurückgibt.

Diagnose: Der Check-Verlauf zeigt den Wechsel auf down mit 500er-Codes um 21:12 Uhr am Freitag, danach 61 Stunden durchgehende Downtime. Der Alarm zum Statuswechsel war sehr wohl versendet worden, an eine Adresse, die niemand mehr abrief.

Maßnahme: Die Alarme der Kategorie Monitoring zusätzlich zur E-Mail an einen Slack-Webhook routen und einen eigenen Monitor auf den Endpunkt des Formulars legen, statt nur auf die Startseite.

Fall 2: Fehlalarm durch eine regionale Netzwerkstörung

Symptom: Um 3 Uhr nachts kommt ein DOWN-Alarm. Vom eigenen Rechner aus antwortet die Website normal.

Diagnose: Der Monitor läuft über drei Regionen mit der Strategie Strikt. Die Aufschlüsselung nach Region zeigt 12 Minuten lang timeout ausschließlich von der Probe apac, während eu und us 200 liefern. Das ist kein Ausfall der Website, sondern eine lokale Transit-Störung.

Maßnahme: Diesen Monitor auf Konsens umstellen, der mindestens die Hälfte der Regionen im Fehlerzustand verlangt. Strikt bleibt den Endpunkten vorbehalten, bei denen ein regionales Flapping bereits ein Kundenvorfall ist, etwa einer Zahlungs-API.

Fall 3: Abgelaufenes Zertifikat an einem Sonntag

Symptom: Die Website antwortet seit Wochen mit 200, die Uptime liegt bei 100 %, und trotzdem zeigen die Browser eine Sicherheitswarnung.

Diagnose: Die automatische Zertifikatserneuerung ist nach einer Konfigurationsänderung am Reverse Proxy stillschweigend fehlgeschlagen. Der Uptime-Monitor hat vor dem Ablauf nichts gemeldet: Er stellt ein ungültiges Zertifikat erst fest, wenn das Datum überschritten ist, nie in den Wochen davor.

Maßnahme: Die Sicherheitslage-Überwachung für diesen Monitor aktivieren. Der Ablaufalarm wird gestuft 30, 14, 7, 3 und 1 Tag vorher versendet, und die Bewertung fällt, sobald Zertifikat oder HSTS zurückfallen.


Vergleich der Website-Monitoring-Tools

CaptainDNS ist kein spezialisiertes Monitoring-Tool: Es ist ein Dashboard für DNS, SPF, DKIM, DMARC und Blacklists, ergänzt um HTTP-Monitoring und Sicherheitslage-Überwachung, mit einer in der Europäischen Union betriebenen Datenebene. Die Wahl entscheidet sich also am Umfang. Wenn Sie ausschließlich Uptime überwachen und Dutzende kostenlose Monitore brauchen, deckt ein Spezialist wie UptimeRobot den Bedarf besser ab. Wenn Sie stark anpassbare Statusseiten suchen, ist BetterStack auf diesem Feld weiter. CaptainDNS ergibt Sinn, wenn die HTTP-Überwachung eine bereits vorhandene DNS- und E-Mail-Überwachung fortsetzt und wenn die europäische Verortung der Verarbeitung zählt. Genaue Quoten und Preise auf der Seite Pläne und Preise.


Quoten, Limits und verfügbare Pläne

Der kostenlose Plan enthält 1 HTTP-Monitor mit Checks alle 5 Minuten aus Europa, also 288 Checks pro Tag, dazu unbegrenzte E-Mail-Alarme, 30 Tage detaillierten Verlauf, Heatmap, p95-Latenz und 1 öffentliche Statusseite, ohne Kreditkarte. Die kostenpflichtigen Pläne erhöhen die Anzahl der Monitore, der aktivierbaren Regionen, die Aufbewahrungsdauer und die Anzahl gleichzeitiger Webhooks und schalten ab Solo die Sicherheitslage-Überwachung frei. Die vollständige Übersicht wird auf der Seite Pläne und Preise gepflegt, die bei Abweichungen zu dieser Seite maßgeblich ist.


Ihre Website aus Europa überwachen: DSGVO und Souveränität

HTTP-Monitoring ist eine Datenverarbeitung: Sie übermitteln URLs, teilweise auch Authentifizierungs-Header. CaptainDNS betreibt seine Datenebene aus der Europäischen Union, mit Europa-Probes in Frankreich und Deutschland, einer PostgreSQL-Datenbank und Backups in Frankreich sowie einem europäischen Technikteam. Die Probes in den USA und in Asien-Pazifik sind optional und führen ausschließlich die Checks aus: die Ergebnisse werden in die europäische Datenbank zurückgeführt, die unabhängig vom Plan der primäre Speicherort bleibt. Das Dashboard verwendet keine Tracking-Cookies und keine Analytics-Skripte von Dritten. Für Ihre Monitore sind Sie der Verantwortliche, CaptainDNS handelt als Auftragsverarbeiter im Sinne von Artikel 28 der DSGVO; der DPA ist auf Anfrage verfügbar.


Grenzen des HTTP-Monitorings

Das HTTP-Monitoring von CaptainDNS deckt die folgenden Anforderungen nicht ab:

  • Reines TCP-Monitoring auf Nicht-HTTP-Ports (SMTP, FTP, Datenbank).
  • Multi-Step-Transaktionen: Nutzerpfade über mehrere Seiten mit aufeinanderfolgenden Assertions.
  • Probes außerhalb der drei Zonen Europa, USA und Asien-Pazifik: weder Südamerika noch Afrika noch der Nahe Osten.
  • Nicht öffentliche Endpunkte: eine URL hinter einem VPN oder einer privaten Firewall bleibt für unsere Probes unerreichbar.

Für Slack, Discord, PagerDuty und Opsgenie gibt es keine nativen Integrationen: diese Alarme laufen über die HTTPS-Webhooks, wobei das Ziel die endgültige Formatierung übernimmt.


FAQ - Häufig gestellte Fragen

F: Was ist Website-Monitoring?

A: Website-Monitoring bedeutet, die Verfügbarkeit und die Latenz einer HTTP-URL kontinuierlich zu prüfen. Das Tool sendet in regelmäßigen Abständen eine Anfrage, erfasst die Antwort und löst bei einem Fehler einen Alarm aus. So wird ein Ausfall erkannt, bevor Ihre Nutzer ihn bemerken.


F: Wie oft prüft CaptainDNS meine URL?

A: Standardmäßig alle 5 Minuten ein HTTP-Check auf jedem Ihrer Monitore, also 288 Checks pro Tag. Über einen Cron-Ausdruck lässt sich die Taktung anpassen: Check jede Minute während der Geschäftszeiten, ausgeschlossenes Wartungsfenster.


F: Wie erhalte ich einen Alarm, wenn meine Website ausfällt?

A: Aktivieren Sie die E-Mail-Alarme beim Erstellen des Monitors: Sie gehen an die Adresse Ihres CaptainDNS-Kontos, eine Empfängeradresse ist nicht einzutragen. Sobald ein Fehlschlag bestätigt ist (5xx, Timeout, DNS-Fehler, ungültiges TLS-Zertifikat), wird ein Alarm ausgelöst. Die Erinnerungen folgen danach mit mindestens einer Stunde Abstand, und eine Recovery-E-Mail schließt den Vorfall ab, sobald die Website zurück ist.


F: Was bedeutet eine Uptime von 99,9 %?

A: Eine Uptime von 99,9 % lässt rund 8 Stunden und 45 Minuten Ausfall pro Jahr zu, also 43 Minuten pro Monat. Das ist der im Produktivbetrieb übliche Schwellenwert. Bei 99,99 % sinkt das Budget auf 52 Minuten pro Jahr.


F: Ist CaptainDNS kostenlos für die Überwachung meiner Website?

A: Der kostenlose Plan enthält 1 HTTP-Monitor mit Checks alle 5 Minuten, unbegrenzte E-Mail-Alarme, die 30-Tage-Heatmap und die p95-Latenz, ohne Kreditkarte. Die Quoten der übrigen Pläne stehen auf der Preisseite.


F: Kann ich eine authentifizierte URL oder einen privaten Endpunkt überwachen?

A: Ja, sofern die URL öffentlich erreichbar ist. Über benutzerdefinierte HTTP-Header (Authorization, X-API-Key) lassen sich Token-geschützte Endpunkte abfragen. Eine URL hinter einem VPN oder einer privaten Firewall bleibt für unsere Probes unerreichbar.


F: Wie teile ich meine Monitoring-Ergebnisse?

A: Verknüpfen Sie Ihren Monitor mit einer öffentlichen Statusseite von CaptainDNS. Sie zeigt Uptime, Latenz und Vorfallverlauf für Ihre Kunden, ohne ihnen Zugang zu Ihrem privaten Dashboard zu geben.


F: Was ist die Sicherheitslage?

A: Die Sicherheitslage fasst fünf Komponenten in einer 100-Punkte-Bewertung zusammen: SSL/TLS-Zertifikat, HSTS, Sicherheits-Header, Seitengewicht und Phishing-Reputation. Die Bewertung verteilt sich auf die Bereiche Sicherheit (80 Punkte) und Performance (20 Punkte); CaptainDNS schlägt bei jeder Verschlechterung sowie vor dem Ablauf des Zertifikats Alarm. Ab dem Solo-Plan verfügbar.


F: Welche Komponenten werden analysiert und wie oft?

A: SSL/TLS-Zertifikat, HSTS, HTTP-Sicherheits-Header, Seitengewicht und Phishing-Reputation. Sie wählen die überwachten Komponenten (mindestens eine) und die Analysehäufigkeit, je nach Plan von einmal pro Stunde bis einmal pro Tag. Seitengewicht und Phishing-Reputation werden höchstens einmal pro Tag gemessen.


Ergänzende Tools

ToolNutzen
Status PagesEine öffentliche Statusseite mit Uptime und Vorfällen veröffentlichen
HSTS-TestDen Strict-Transport-Security-Header und die Eignung für die Preload-List prüfen
HTTP-Header-AnalyseDie Sicherheits-Header (CSP, X-Frame-Options) mit einer Note von A bis F auditieren
Page Crawl CheckDas technische SEO einer URL prüfen (Status, Header, Weiterleitungen)
Redirect CheckerHTTP-Weiterleitungsketten einer URL nachverfolgen
Phishing URL CheckerPrüfen, ob eine URL als Phishing oder Malware gemeldet ist
DNS Propagation TestWeltweite DNS-Propagierung eines Eintrags prüfen
SPF Record CheckDie SPF-Konfiguration einer Sendedomain validieren

Nützliche Ressourcen