Website-Überwachung für Entwickler, fest in Ihrem Stack verdrahtet.
Uptimia führt Ihre echten API-Aufrufe aus — Anmeldung, Token ziehen, Bestellung aufgeben, Ergebnis zurücklesen — und prüft jede Antwort mit Assertions. Geben Sie jedem Cron-Job eine Heartbeat-URL, legen Sie Monitore aus Ihrem Deploy-Skript an, und werden Sie in Slack, Discord oder PagerDuty alarmiert.
Step breakdown
All 4 steps passedFailed at step 31.66 s · 14:251.38 s · 14:327-day averagesLast runAssertions — step 3
3 of 3 passing1 of 3 passedResponse — step 3
201 · 624 ms500 · 612 msRecent Runs
every 5 min · 12 locations
New York✗ Failed at step 31.41 s
Frankfurt✗ Failed at step 31.38 s
London✓ All 4 steps passed1.62 s
Sydney✓ All 4 steps passed1.71 sNew York✓ All 4 steps passed1.58 s
Tokyo✓ All 4 steps passed1.64 sVier Ausfälle, die lautlos bleiben
Alle vier stimmen am Deploy-Tag. Keiner bleibt von allein wahr — und wenn einer aufhört zu stimmen, wirft nichts.
„Wenn etwas ausfällt, sehen wir eine Exception.“
Error-Tracker sehen nur Code, der läuft. Ein Cron-Eintrag, der nie startet, ein Worker, der mitten im Job feststeckt, ein Zertifikat, das unbemerkt abläuft — keines davon wirft. Die schlimmsten Ausfälle sind keine Stack-Traces; sie sind Funkstille.
„Die Pipeline ist grün, also ist Prod in Ordnung.“
CI beweist, dass der Code zum Deploy-Zeitpunkt gut war. Abgelaufene Tokens, volle Festplatten, erschöpfte Quotas und driftende Konfiguration passieren zwischen den Deploys — im laufenden System, das Ihre Testsuite nie wieder sieht.
„Davon erfahren wir schnell — wir sind den ganzen Tag online.“
Sie sitzen 40 der 168 Wochenstunden an der Tastatur — in den anderen 128 sucht niemand. Und Nutzer melden einen kaputten Checkout selten; sie probieren es einmal erneut und gehen.
„Es lief in Staging, also läuft es.“
Staging hat nie den Traffic, die Datenmengen, die Quotas Dritter oder das DNS von Production. Die Ausfallarten, die Sie um 03:00 Uhr wecken, sind genau diejenigen, die Staging nicht reproduzieren kann.
„Wir haben einen /health-Endpunkt — wir sind abgesichert“ ist die größte Annahme. Ein Health-Check pro Minute sagt Ihnen 1.440-mal täglich, dass ein Prozess antwortet (24 × 60). Wie viele dieser Prüfungen belegen, dass der Checkout durchläuft, das nächtliche Backup gelaufen ist oder sich die Queue leert: null.
„Ein Prozess antwortet“ und „das System funktioniert“ sind verschiedene Aussagen — und nur eine davon ist die, die Ihren Nutzern wichtig ist.
So sieht ein lautlos gestorbener Cron-Job aus, wenn ein Heartbeat zuhört.↓ Minute für Minute
Was passiert, wenn ein Cron-Job lautlos stoppt
Ein Deploy hat die Crontab umgeschrieben und eine Zeile verloren. In dieser Nacht startete der Invoice-Worker nicht, warf nichts, und jedes Dashboard blieb grün — die Queue bewegte sich nie.
Damit ist der gestorbene Job abgedeckt. Aber Cron ist nur eine der Flächen, die lautlos ausfallen — jede Annahme oben hat ihre eigene.↓ ein Monitor für jede
Ketten, Pings und Agents
API-Ketten für Dienste, eingehende Pings für Jobs, Echtbrowser-Abläufe für Checkouts, ein Einzeiler-Agent für die Maschine. Verschiedene Flächen, ein Vorfallstrom, eine API.
Ketten, Heartbeats und Eskalationen
Verkettete Aufrufe, je Schritt geprüft
Ein /health-Endpunkt beweist, dass ein Prozess antwortet. Über den Ablauf dahinter beweist er nichts. Die Kette fährt die echten Aufrufe der Reihe nach ab und prüft jede Antwort — den Statuscode, die Dauer, einen Wert im JSON — bis zu einmal pro Minute in jedem bezahlten Tarif, von jedem Standort oder nur den von Ihnen gewählten.
- Bis zu 15 Schritte — GET, POST, PUT, PATCH, DELETE oder HEAD, der Reihe nach ausgeführt
- Extrahieren und wiederverwenden — einen Wert aus einer Antwort ziehen und mit
{{token}}in den nächsten einsetzen - Das prüfen, was zählt — Statuscode, Antwortzeit, ein JSONPath-Wert, ein Header oder Body-Text, je Schritt
/health-Prüfung antwortet die ganze Zeit prächtig — und beweist keinen dieser vier Aufrufe.
0 von 4 belegt
Der Job, der nie gestartet ist
Ein Job, der nicht mehr läuft, wird leise statt rot — nichts wirft, also warnt nichts. Geben Sie ihm eine Heartbeat-URL zum Anpingen bei jedem Lauf, und der fehlende Ping wird zur Warnung: Bleibt das Fenster über die Toleranz hinaus aus, öffnet Uptimia einen Vorfall. Signalisieren Sie auch Start und Ende, dann erwischt es Jobs, die hängen statt zu stoppen.
- Intervall oder Cron-Zeitplan — ein schlichtes Intervall oder ein 5-Felder-Cron-Ausdruck in der Zeitzone Ihres Kontos
- Eine Zeile zum Anbinden — Copy-Paste-Schnipsel für Crontab, Bash, PowerShell, GitHub Actions und PHP
- Erwischt Hänger, nicht nur Aussetzer — senden Sie einen Start-Ping, und ein Laufzeitlimit markiert einen Job, der nie fertig wird
Monitore, die Ihr Deploy-Schritt anlegt
Niemand klickt sich hier durch — das Skript, das den Dienst ausgeliefert hat, hat dessen Monitor angelegt. Erstellen und verwalten Sie Monitore über die REST-API aus einem CI-Schritt heraus, und wenn sich ein Vorfall öffnet, POSTet ein eigener Webhook ihn in alles, was Sie ohnehin fahren: ein Statusboard, einen Bot, einen ChatOps-Ablauf.
- Eine REST-API — Monitore erstellen, lesen, aktualisieren und löschen in jedem Tarif (API-Monitore und Heartbeats liegen auf v2), Konto-API-Schlüssel werden in den Einstellungen verwaltet
- Eigene Webhooks — POST eines festen JSON-Bodys mit Ihren eigenen Headern an einen beliebigen Endpunkt bei einem Monitor-Ereignis
- Sicher ab Werk — die Webhook-Zustellung ist TLS-verifiziert, pinnt DNS zum Sendezeitpunkt und lehnt Ziele in privaten Netzen ab
curl -X POST …/api/v2/api-monitor
-d '{"name":"Checkout API","interval":60}'
Erst Slack, dann PagerDuty, wenn niemand quittiert.
Im Kanal, den Ihr Team ohnehin liest, nicht in einem Posteingang, den nachts niemand öffnet. Die Kette stuft einen unbeantworteten Slack-Ping nach Ihrem Zeitplan zu einer PagerDuty-Warnung hoch, und eine einzige Bestätigung — direkt in der Warnung getippt, ohne Anmeldung — pausiert alle offenen Schritte für alle.
- Warnungen dort, wo Sie arbeiten — Slack, Discord, Telegram, MS Teams, Mattermost, PagerDuty, E-Mail, SMS, Webhooks und mehr
- Eskalationsleitern — bis zu 10 zeitgesteuerte Schritte je Richtlinie; aus der Warnung heraus quittieren, und die Leiter pausiert
- Zuerst bestätigt — Ausfälle werden aus mehreren Regionen verifiziert — und späte Jobs jenseits ihrer Toleranz — bevor jemand gewarnt wird
Alarmiert dort, wo Sie ohnehin arbeiten, nicht in einem weiteren Dashboard
Ein Worker, der stoppte, eine Kette, die brach, eine Maschine ohne Speicherplatz — all das erreicht dieselben Kanäle, und all das lässt sich über die REST-API skripten.
Microsoft TeamsEine Kontaktliste — einmal über die API oder die Oberfläche gepflegt.
Komplettes Integrationsverzeichnis durchsehen →Ein kaputter Deploy sollte Sie alarmieren.Nicht Ihre Nutzer.
Die 30-tägige Testphase schaltet jeden Monitor-Typ und jeden Benachrichtigungskanal frei.
Ihren ersten Monitor in drei Schritten einrichten
Auf eine Fläche richten, die Warnung routen, laufen lassen.
Die Fläche wählen
Eine API-Kette, eine Heartbeat-URL, ein Browser-Ablauf oder der Einzeiler-Agent — anlegen in der Oberfläche oder über die REST-API.
Die Warnung routen
An Slack, Discord oder PagerDuty senden, ein Webhook ergänzen und festlegen, wer als Nächstes alarmiert wird, wenn niemand bestätigt.
Laufen lassen
Prüfungen laufen von über 171 Prüfstandorten und bestätigen einen Fehler, bevor Sie alarmiert werden — inklusive Angabe, welcher Schritt bzw. Job ausgefallen ist.
Ebenfalls enthalten
Server-Agent als Einzeiler
CPU, Arbeitsspeicher, Festplatte und Load direkt aus der Maschine — eine bash-Installation mit Checksummenprüfung, kein Collector, den Sie schreiben müssen. Linux, per systemd-Timer oder Cron.
Web-Transaktions-Monitoring
Eine Anmeldung oder einen Checkout in einem echten Browser nachstellen — Schritt für Schritt im Builder erstellt, mit Screenshot zu jedem einzelnen Schritt.
Wartungsfenster
Heute Nacht ein Deploy? Planen Sie das Fenster — Prüfungen pausieren, Warnungen bleiben still, keine Fehlalarme während eines geplanten Releases.
Wiederherstellungsbenachrichtigungen
Kommt ein Dienst zurück, erfahren das auch die Alarmierten — kein „Ist er noch offline?“ hängt dann im Kanal.
Vorfallhistorie
Jeder Vorfall wird protokolliert: was ihn ausgelöst hat, wann, wie lange die Wiederherstellung dauerte und — wenn eine Kette läuft — wer bestätigt hat.
Eine Liste für Ketten und Jobs
API-Ketten, Heartbeats, Server und Verfügbarkeitsprüfungen teilen sich ein Dashboard, ein Warnungs-Rückgrat und eine API — nicht vier einzelne Tools.
Was ist Website-Überwachung für Entwickler?
Website-Überwachung für Entwickler heißt, die Flächen im Blick zu behalten, die Sie ausliefern — HTTP-APIs, Hintergrundjobs, Server und Nutzerabläufe — und sich über die Tools benachrichtigen zu lassen, die Sie ohnehin nutzen, wenn eine davon bricht. Sie verdrahten die Überwachung in den Stack: eine mehrstufige API-Prüfung von außen, einen Heartbeat-Ping, den ein Cron-Job hereinsendet, einen Agenten in der Maschine sowie eine REST-API und Webhooks, wo Sie lieber skripten.
Er antwortet, und trotzdem ist der Dienst kaputt
Ein oberflächlicher Ping bleibt grün, während der Ablauf scheitert, von dem Ihre Nutzer abhängen.
Die Kette findet es
Die scheiternde Assertion nennt den exakten Aufruf — Sie beginnen zu debuggen statt zu raten.
Welcher Monitor was überwacht
Jede Familie überwacht eine andere Fläche — alle teilen sich ein Dashboard, ein Warnungs-Rückgrat und eine REST-API. Jede wird zudem separat gezählt, und eine Kette ist die teuerste Zeile im Betrieb — die Preisseite führt die Zahlen je Tarif.
Alle Monitor-Typen ansehen →| Bereich | Was erkannt wird | So funktioniert es |
|---|---|---|
| API-Kette | Kaputte mehrstufige Abläufe | Bis zu 15 geordnete Schritte mit Assertions je Schritt, geprüft so oft wie einmal pro Minute |
| Heartbeat | Crons & Worker, die lautlos stoppen | Eingehende Ping-URL; ein verpasstes Fenster nach Ablauf der Toleranz öffnet einen Vorfall |
| Verfügbarkeit | Ausfälle, Serverfehler | Von-außen-Prüfungen so oft wie alle 30 s ab Professional, bestätigt aus bis zu 3 Regionen |
| Server-Agent | CPU, Arbeitsspeicher, Festplattendruck | Linux-Einzeiler-Agent, meldet /proc + df alle 30 s |
| Web-Transaktion | Kaputte Logins & Checkouts | Mehrstufige Abläufe, durchlaufen in einem echten Browser |
FAQ zur Überwachung für Entwickler & DevOps
01Was ist Website-Überwachung für Entwickler?+
02Kann ich einen mehrstufigen API-Ablauf überwachen, nicht nur einen einzelnen Endpunkt?+
{{token}} in den nächsten ein, und prüfen Sie je Schritt auf Statuscode, Antwortzeit, einen JSONPath-Wert, einen Header oder Body-Text. Scheitert ein Schritt, nennt die Warnung ihn — Sie wissen, welcher Aufruf brach.03Wie überwache ich einen Cron-Job oder Background-Worker?+
curl, damit er bei jedem Lauf pingt. Legen Sie Intervall oder Cron-Zeitplan mit einer Toleranz fest, und bleibt der Ping aus, öffnet sich ein Vorfall. Ein Start-Ping plus ein Laufzeitlimit erwischt auch Jobs, die hängen. Schnipsel gibt es für Crontab, Bash, PowerShell, GitHub Actions und PHP.04Gibt es eine API für die Verfügbarkeitsüberwachung, um Monitore anzulegen und zu verwalten?+
curl-Beispiel zum Kopieren. Einen Terraform-Provider oder eine Zapier-App gibt es nicht.05Kann ich jedem Teammitglied einen eigenen API-Schlüssel ausstellen?+
06Wohin gehen Warnungen, und kann ich sie in eigene Tools weiterschleifen?+
07Behandeln Sie Rufbereitschaftspläne?+
08Läuft der Server-Agent unter Windows?+
/proc und df für CPU, Arbeitsspeicher, Festplatte und Load ausliest. Ein PowerShell-Collector für Windows und einer für macOS kommen mit und posten dieselbe Payload — ohne die Per-Core- und I/O-Wait-Werte, die allein Linux liefert — aber als Einzeiler bekommt man sie nicht gereicht. Windows-Hosts lassen sich zusätzlich von außen mit Verfügbarkeits-, API- oder Web-Transaktions-Monitoren beobachten.09Kann ich einen cURL-Befehl oder eine OpenAPI-Spec in den API-Builder importieren?+
10Wie viele Ketten, Heartbeats und Agents enthält ein Tarif?+
Ausliefern. Wir halten es im Blick.
Verdrahten Sie eine API-Kette, einen Heartbeat und einen Server-Agent in die Testphase — Warnungen erreichen Sie dort, wo Sie ohnehin sind.