Uptime-Monitoring

Erfahre sofort,
wenn dein Dienst ausfällt.

HTTP-, Ping- und Keyword-Checks aus deutscher Infrastruktur. Intervalle ab 30 Sekunden, jeder Fehler klassifiziert, jeder Alert innerhalb von Sekunden zugestellt — kein US-Cloud, kein CLOUD Act, kein DNS-Caching.

Kostenlose Stufe inklusive · Keine Kreditkarte · jederzeit kündbar

Drei Schritte

So funktioniert's.

Richte einen Monitor auf deinen Dienst. Konfiguriere Intervall und Strenge. Werde benachrichtigt, wenn etwas kaputtgeht.

01

Monitor erstellen

Wähle einen Check-Typ — HTTP, Ping oder Keyword — und gib die URL oder den Host ein, den du überwachen willst. Das ist die minimale Konfiguration. Alles andere hat sinnvolle Standardwerte.

02

Check-Typ wählen

Drei Wege, um zu verifizieren, dass ein Dienst lebt — wähle den, der zu dem passt, was du überwachst:

GET https://api.example.com/health HTTP
// alle 30s aus Nürnberg
GET https://api.example.com/health
 200 OK · 34ms · TLS 1.3

// prüft Status-Code, Antwortzeit, Header,
// SSL-Gültigkeit, DNS-Auflösung, Chain of Trust.
03

Benachrichtigt werden, wenn er ausfällt

Sobald die konfigurierte Anzahl aufeinanderfolgender Fehler erreicht ist, wird ein Incident geöffnet und Alerts gehen per E-Mail, Slack, Discord oder Webhook raus. Der Incident wird automatisch geschlossen, sobald der nächste erfolgreiche Check eintrifft — inklusive Auflösungsbenachrichtigung.

Fehlerklassifikation

Was wir tatsächlich erkennen.

Jeder Incident wird mit seiner Ursache klassifiziert, damit du ohne Raten triagieren kannst. Kein generisches „Seite down" — der Alert sagt dir, was kaputt ist.

HTTP-Fehler

4xx- und 5xx-Antwort-Codes. Konfigurierbar — du entscheidest, ob ein 401 ein Incident ist oder erwartet (z. B. bei auth-geschützten Health-Endpoints).

SSL-Zertifikatsprobleme

Ablaufdatum, Chain-of-Trust-Probleme, Hostname-Abweichungen. Eigene Ursache, damit du reagieren kannst, bevor ein Ausfall deine Kunden trifft.

DNS-Fehler

Kein Record gefunden, NXDOMAIN, Timeout beim Resolver. Kein DNS-Caching auf unserer Seite — jeder Check führt einen frischen Lookup durch.

Timeouts

Server nicht erreichbar, Verbindung hängt, oder Antwort langsamer als dein konfiguriertes Timeout (Standard 10s). Erfasst degradierte Performance, nicht nur harte Ausfälle.

Connection Refused

Port geschlossen, Dienst hört nicht zu, Firewall-Drop. Unterscheidet sich von Timeout — Host ist oben, aber der Dienst ist tot.

Keyword fehlt

Antwort lieferte 200, aber der erwartete Text fehlt. Fängt weiche Fehler ab, bei denen eine Seite einen Fehler rendert oder eine WAF Inhalte blockiert.

Die Richtung zählt

Uptime vs. Heartbeat.

Zwei Ansätze, ein Ziel: zu wissen, wann etwas kaputtgeht. Uptime fängt öffentliche Ausfälle ab. Heartbeat fängt stille interne Fehler ab.

Uptime-MonitoringHeartbeat-Monitoring
RichtungFoundersDeck pingt deinen DienstDeine Aufgabe pingt FoundersDeck
Beantwortet„Antwortet mein Dienst?"„Lief mein Job pünktlich?"
Am besten fürWebsites, APIs, EndpointsCronjobs, Scripts, Worker
FehlermodusErkennt öffentliche AusfälleErkennt stille Fehler
Warum eins nicht reicht

Deine API kann 200 OK zurückgeben, während das nächtliche Backup eine Woche lang stillschweigend fehlgeschlagen ist. Dein Cronjob kann perfekt laufen, während deine Website ausfällt. Echte Zuverlässigkeit bedeutet, beide Richtungen zu überwachen. FoundersDeck gibt dir Uptime-Monitoring und Heartbeat-Monitoring in einem Tool — alles in Nürnberg gehostet. Kein CLOUD Act, keine Daten verlassen die EU, kein zweiter Anbieter.

Uptime-Tool wählen

FoundersDeck vs. UptimeRobot, Better Stack, Pingdom.

Die drei beliebtesten Uptime-Tools sind allesamt US-Gesellschaften — das bedeutet, dass jedes Byte deiner Monitoring-Daten dem CLOUD Act unterliegt, egal welche „Region" du in ihrem Dashboard wählst. Hier ein ehrlicher Direktvergleich.

FoundersDeckUptimeRobotBetter StackPingdom
HauptsitzDeutschlandUSAUSA (Delaware)USA (SolarWinds)
CLOUD-Act-ExpositionKeineJaJaJa
DatenstandortAusschließlich NürnbergGlobal (US-betrieben)Global (US-betrieben)Global (US-betrieben)
Schnellstes Intervall30s (Scale)60s (Free)30s60s
Monitoring-StandorteNur EU (bewusst)GlobalGlobalGlobal
Heartbeat / Cron
Öffentliche Status-Seiten
Bezahlte Einstiegsstufe€9/Monat$7/Monat$29/Monat$15/Monat
Wähle ein US-Tool, wenn

du wirklich globale Monitoring-Standorte brauchst (z. B. weil du ein weltweites Publikum bedienst und regionale Ausfälle abfangen willst), du bereits in US-Compliance-Frameworks operierst oder du Features brauchst, die wirklich kategoriebildend sind — wie Pingdoms Real-User-Monitoring.

Wähle FoundersDeck, wenn

deine Zielgruppe europäisch ist, deinen Kunden DSGVO und CLOUD-Act-Exposition wichtig sind, du Uptime + Heartbeat + Status-Seiten in einem Abonnement willst — oder du ein Tool bevorzugst, das ein Founder gebaut hat, der es selbst nutzt, statt einer VC-finanzierten Plattform.

Konfiguration

Geschwindigkeit vs. Rauschen feinjustieren.

Jeder Regler, den du brauchst, um den Monitor auf den Dienst abzustimmen — ohne dich in Optionen zu ertränken, die du nicht brauchst.

Check-Intervalle
30s → 10m

30-Sekunden-Checks auf Scale, 1-Minute auf Starter und Pro, 5-Minuten auf Free.

Request-Timeout
5s → 30s

Harter Cutoff, nach dem der Check als Timeout markiert wird. Standard 10 Sekunden.

Alert-Sensitivität
1 → 5 Fehler

Anzahl aufeinanderfolgender fehlgeschlagener Checks, bevor ein Incident geöffnet wird.

Request-Gestaltung
6 Methoden

GET, HEAD, POST, PUT, PATCH oder DELETE — mit eigenen Headern, Request-Body und Basic-/Bearer-Auth. Redirects werden standardmäßig verfolgt.

Erwarteter Status
Listen · Ranges

Standard ist 200 — akzeptiere eine Liste, einen Range wie 200-204 oder eine ganze Klasse wie 2xx, pro Monitor.

Aufbewahrung
30T → 365T

30 Tage auf Free, 90 auf Starter, 180 auf Pro, 365 auf Scale — alles in Deutschland gespeichert.

Alert-Kanäle
  • E-Mail
  • Slack
  • Discord
  • Telegram
  • Webhook
  • Microsoft Teams
Unter der Haube

Mehr als URL und Intervall.

Gestalte den exakten Request, prüfe die exakte Antwort und überwache die Dinge rund um deinen Endpoint — Zertifikate, Domains, DNS-Einträge —, die still und leise Ausfälle verursachen.

Request-Konfiguration

Jeder HTTP-Monitor sendet genau den Request, den du brauchst. Wähle die Methode — GET, HEAD, POST, PUT, PATCH oder DELETE —, ergänze eigene Header, einen Request-Body sowie Basic- oder Bearer-Authentifizierung. Setze den Request-Timeout (Standard 10 Sekunden, bis zu 30) und lege fest, ob Redirects verfolgt werden. Die Request-Konfiguration ist in jedem Tarif verfügbar.

Erwartete Statuscodes

Sag jedem Monitor, welche Antworten als gesund gelten. Gib einen einzelnen Code, eine kommagetrennte Liste, einen Range wie 200-204 oder eine Klasse wie 2xx an. Alles außerhalb dieser Menge öffnet einen als HTTP-Fehler klassifizierten Incident — ein auth-geschützter Endpoint, der bewusst 401 liefert, weckt dich also nie.

SSL-Zertifikat & Domain-Ablauf

Jeder HTTPS-Monitor überwacht sein TLS-Zertifikat automatisch — ohne Konfiguration. FoundersDeck warnt dich 30, 14, 7 und 1 Tag vor Ablauf des Zertifikats. Die Domain-Ablauf-Überwachung (ab Starter) prüft deine Registrierung per RDAP und warnt 30, 14 und 7 Tage im Voraus, damit eine verpasste Verlängerung deine Seite nie offline nimmt.

DNS-Monitoring

Ein eigener DNS-Monitor-Typ (ab Starter) löst A-, AAAA-, CNAME-, MX-, TXT- oder NS-Einträge auf und vergleicht sie mit den erwarteten Werten — als exakter Match oder Contains-Prüfung. Erkenne gekaperte Einträge, fehlende MX-Records oder Propagationsfehler, bevor deine E-Mail oder dein Traffic still und leise ausfällt.

Degraded-Status

Langsam ist nicht dasselbe wie down. Setze pro Monitor einen Antwortzeit-Schwellwert; jeder Check, der erfolgreich, aber langsamer als dieser antwortet, wird als degraded markiert — zählt weiter als verfügbar, ist aber im Antwortzeit-Chart und auf der Status-Seite sichtbar. Du siehst nachlassende Performance lange bevor sie zum echten Ausfall wird. In jedem Tarif verfügbar.

Alert-Reminder & Kanäle

Alerts erreichen dich per E-Mail in jedem Tarif; Slack, Discord und Telegram ab Starter; Webhook und Microsoft Teams ab Pro. Ordne Kanäle pro Monitor zu, damit das richtige Team vom richtigen Dienst erfährt. Bei einem anhaltenden Ausfall erinnern Reminder-Alerts (ab Starter) im Abstand von 15, 30, 60 oder 240 Minuten, bis er behoben ist — und eine Recovery-Benachrichtigung schließt den Kreis.

Reports & Incident-Dokumentation

Ab Pro exportierst du gesetzte PDF-Uptime-Reports (monatlich, quartalsweise oder jährlich) und einzelne Incident-PDF-Reports sowie CSV-Exporte von Check-Log und Incident-Historie. Sie liefern zeitgestempelte Verfügbarkeitsnachweise zur Unterstützung deiner Meldepflicht-Dokumentation nach § 30 BSIG (NIS2). Sie unterstützen deine Pflichten; sie machen dich nicht von selbst konform.

365-Tage-Uptime-Historie

Tägliche Uptime-Rollups liefern jedem Tarif — auch Free — eine vollständige 365-Tage-Uptime, über Zeiträume von 24 Stunden, 7, 30, 90 und 365 Tagen. Die täglichen Rollups werden zwei Jahre aufbewahrt, sodass Zuverlässigkeitstrends über Jahre verfügbar bleiben, auch wenn rohe Einzel-Check-Logs bereits ausgelaufen sind.

FAQ

Häufig gefragt.

Was ist Uptime-Monitoring?
Uptime-Monitoring ist die Praxis, kontinuierlich zu prüfen, ob eine Website, API oder ein Dienst von außen erreichbar ist und korrekt antwortet. FoundersDeck sendet Anfragen von deutscher Infrastruktur in festen Intervallen, erfasst Antwortzeit, Status-Code und Fehlerklasse — und alarmiert dich in dem Moment, in dem ein Dienst nicht mehr wie erwartet reagiert.
Wie oft werden meine Monitore geprüft?
Check-Intervalle reichen von 30 Sekunden (Scale-Tarif) bis 10 Minuten. Free läuft auf 5-Minuten-Intervallen, Starter und Pro auf 1 Minute, Scale auf 30 Sekunden. Jeder Check läuft aus EU-Infrastruktur — kein DNS-Caching, keine geteilten Agents mit unbeteiligten Kunden.
Was ist der Unterschied zwischen HTTP-, Ping- und Keyword-Checks?
HTTP-Checks verifizieren den vollständigen Request/Response-Zyklus auf Port 80/443 — Status-Code, Header, SSL, DNS. Ping-Checks prüfen die grundlegende Netzwerkerreichbarkeit über ICMP/TCP und eignen sich für Dienste ohne HTTP-Endpoints. Keyword-Checks sind HTTP-Checks, die zusätzlich überprüfen, ob ein bestimmter String im Response-Body vorhanden ist — nützlich für weiche Fehler, wo eine Seite 200 OK liefert, aber einen Fehler darstellt.
Erkennt ihr SSL-Zertifikatsprobleme?
Ja. Jeder HTTPS-Check verifiziert die Zertifikatskette, Ablaufdatum und Hostname-Match. SSL-Fehler werden als eigene Incident-Ursache klassifiziert (ssl_error) und erscheinen separat in deiner Incident-Historie — so kannst du auf Zertifikatsprobleme reagieren, bevor sie zu Ausfällen werden.
Wie werden False Positives verhindert?
Jeder potenzielle Ausfall wird durch mehrere aufeinanderfolgende fehlgeschlagene Checks bestätigt, bevor ein Incident geöffnet wird — die genaue Zahl ist pro Monitor konfigurierbar (1 bis 5). Kurze Netzwerk-Aussetzer, transiente Upstream-Fehler und kurze Cold-Start-Spitzen wecken dich nicht. Nur echte, anhaltende Probleme lösen einen Alert aus.
Was passiert in dem Moment, in dem ein Check fehlschlägt?
Ein fehlgeschlagener Check wird mit Status-Code, Antwortzeit und klassifiziertem Fehlertyp (Timeout, DNS, SSL, Connection Refused, HTTP-Fehler, Keyword fehlt) protokolliert. Sobald die konfigurierte Anzahl aufeinanderfolgender Fehler erreicht ist, wird ein Incident geöffnet und Alerts werden innerhalb von Sekunden an alle verknüpften Kanäle gesendet. Der Incident wird automatisch geschlossen, sobald der nächste erfolgreiche Check eintrifft.
Welche Alert-Kanäle werden unterstützt?
E-Mail in jedem Tarif; Slack, Discord und Telegram ab Starter; Webhooks und Microsoft Teams ab Pro. Alert-Kanäle werden pro Monitor zugeordnet, und bei einem anhaltenden Ausfall erinnern Reminder-Alerts im Abstand von 15, 30, 60 oder 240 Minuten (ab Starter). Jeder Kanal erhält außerdem eine Auflösungsbenachrichtigung, wenn sich der Dienst erholt.
Überwacht FoundersDeck den Ablauf von SSL-Zertifikaten?
Ja, automatisch. Jeder HTTPS-Monitor überwacht sein TLS-Zertifikat ohne jede Konfiguration und warnt dich 30, 14, 7 und 1 Tag vor Ablauf. Die Zertifikats-Überwachung ist in jedem Tarif enthalten, auch in Free — so wird aus einer vergessenen Erneuerung nie ein stiller Ausfall.
Kann ich POST-Requests mit eigenen Headern senden?
Ja. Jeder HTTP-Monitor lässt dich die Methode wählen (GET, HEAD, POST, PUT, PATCH oder DELETE) und eigene Header, einen Request-Body sowie Basic- oder Bearer-Authentifizierung ergänzen. Das funktioniert in jedem Tarif, sodass du authentifizierte API-Endpoints und Webhooks genau so überwachst, wie sie tatsächlich aufgerufen werden.
Kann ich DNS-Einträge überwachen?
Ja. Ein eigener DNS-Monitor-Typ (ab Starter) löst A-, AAAA-, CNAME-, MX-, TXT- oder NS-Einträge auf und vergleicht sie mit den erwarteten Werten — als exakter Match oder Contains-Prüfung. So erkennst du gekaperte Einträge, fehlende MX-Records und Propagationsfehler, bevor Traffic oder E-Mail stillschweigend ausfallen.
Warnt mich FoundersDeck, bevor meine Domain abläuft?
Ja, ab dem Starter-Tarif. Die Domain-Ablauf-Überwachung fragt deine Registrierung per RDAP ab und warnt dich 30, 14 und 7 Tage vor Ablauf. Sie läuft parallel zu deinen Uptime-Checks, sodass eine verpasste Verlängerung nie unbemerkt die ganze Seite offline nimmt.
Was ist der Degraded-Status?
Ein Check, der erfolgreich, aber langsamer als ein von dir gesetzter Antwortzeit-Schwellwert antwortet, wird als degraded markiert statt als down. Er zählt weiterhin als verfügbar, erscheint aber im Antwortzeit-Chart und auf der Status-Seite — so siehst du nachlassende Performance, bevor sie zum echten Ausfall wird. In jedem Tarif verfügbar.
Wie lange wird die Uptime-Historie aufbewahrt?
Tägliche Uptime-Rollups liefern jedem Tarif eine vollständige 365-Tage-Uptime, über Zeiträume von 24 Stunden, 7, 30, 90 und 365 Tagen. Die täglichen Rollups werden zwei Jahre aufbewahrt. Die rohen Einzel-Check-Logs werden von 30 Tagen (Free) bis 365 Tagen (Scale) gespeichert.
Kann ich Uptime- und Incident-Reports exportieren?
Ja, ab dem Pro-Tarif. Exportiere gesetzte PDF-Uptime-Reports (monatlich, quartalsweise oder jährlich) und einzelne Incident-PDF-Reports sowie CSV-Exporte von Check-Log und Incident-Historie. Sie liefern zeitgestempelte Verfügbarkeitsnachweise zur Unterstützung deiner Meldepflicht-Dokumentation nach § 30 BSIG — sie unterstützen deine Pflichten; sie machen dich nicht von selbst konform.
Wo werden meine Uptime-Daten gespeichert?
Alle Uptime-Check-Ergebnisse, Antwortzeit-Historien und Incident-Datensätze werden ausschließlich in Nürnberg auf Netcup-Infrastruktur gespeichert. Aufbewahrung reicht von 30 Tagen (Free) bis 365 Tagen (Scale). Keine Daten verlassen die EU, kein US-Recht, kein CLOUD Act, kein FISA 702. Details auf unserer Trust- & Souveränitäts-Seite.