Doku & Beispiele
Was du überwachen solltest, und wie.
Holter überwacht auf zwei Arten. Eingehende Heartbeats — deine Jobs pingen uns an, wenn sie fertig sind, und wir alarmieren, wenn ein Ping ausbleibt. Ausgehende Checks — wir rufen deine URL, dein Zertifikat, deinen Port oder DNS von außen nach einem Zeitplan ab. Kein Server-Agent, kein Zugriff auf deine Server. Und bei Business, Abhängigkeiten — wir überwachen die Statusseiten der Anbieter, auf die du dich verlässt, damit du von deren Ausfällen als Erster erfährst.
Eingehende Heartbeats
Ein Dead-Man-Switch: ping uns bei Erfolg, und wir alarmieren, wenn es still wird. Ideal für Backups, Queue-Worker, Crons, Pipelines und Webhooks.
1 · Erstelle deinen eingehenden Heartbeat
Wie Holter überwacht
Name
Alarmieren, wenn kein Ping innerhalb von
Deine Ping-URL
Holter generiert diese — kopiere sie aus dem Dashboard.
2 · Dann rufe sie per curl aus deinem Job auf
# success — at the end of the job
pg_dump … | gzip | aws s3 cp - s3://… \
&& curl -fsS "$HOLTER_URL"
# failure — alert right away
curl -fsS "$HOLTER_URL/fail"
Verpasst du das Zeitfenster, eröffnet Holter einen Incident und alarmiert deine Kanäle. Gleiches Muster für Queue-Worker (alle paar Minuten pingen) und Crons (hänge den curl-Aufruf an die Zeile an).
Lieber per E-Mail? Stelle den Heartbeat auf eine eindeutige Adresse um (…@in.holter.sh) und lass deine App nach einem Zeitplan daran senden. Bleibt dein E-Mail-Versand aus, sagt dir Holter Bescheid — es überwacht die ganze Sendepipeline, nicht nur deinen Code.
Ausgehende Checks
Wir erreichen deinen Dienst nach einem Zeitplan aus dem öffentlichen Internet — nichts zu installieren. Ideal für Uptime, API-Health, SSL, Domain, DNS und TCP.
Einen ausgehenden Check erstellen
Wie Holter überwacht
Was geprüft werden soll
Endpoint
Gesunder Status
Alarmieren, wenn langsamer als
Was es erfasst
- ● Ausgefallen, oder falscher Statuscode
- ● Erreichbar, aber langsamer als dein Latenzbudget (eingeschränkt)
- ● Wiederhergestellt — mit der Ausfalldauer
Wechsle Was geprüft werden soll zu SSL, Domain, DNS oder Redirect — gleicher Bildschirm, nur eine URL, keine zusätzlichen Felder. Zertifikats- und Domain-Checks warnen dich Tage vor Ablauf.
Tipp: Innerhalb von Holter richtet „Was überwachen“ jedes davon mit einem Klick für dich ein.
Behalte im Blick, wovon du abhängst Business
Manche Ausfälle sind nicht deine. Wenn Stripe, AWS, dein Auth-Provider oder Datenbank-Host einen Incident hat, spürt deine App das — und deine Kunden geben dir die Schuld. Füge diese Anbieter als Abhängigkeiten hinzu, und Holter überwacht deren öffentliche Statusseiten, damit du es zuerst per Alert erfährst.
Eine Abhängigkeit hinzufügen
Anbieter
Statusseiten-URL
Oder wähle aus 24 gängigen Anbietern, die wir bereits kennen.
Was hängt davon ab?
Alarmiere mich
Was es erfasst
- ● Ein Anbieter — oder eine seiner Komponenten — meldet eingeschränkten Service
- ● Ein Anbieter meldet einen vollständigen Ausfall — deine Kanäle werden alarmiert
- ● Wiederhergestellt — der vorgelagerte Incident ist behoben
Holter liest die eigene veröffentlichte Statusseite jedes Anbieters alle paar Minuten — es prüft dessen Systeme nicht direkt. Funktioniert bei jeder Seite mit einem öffentlichen Status-Feed (die meisten SaaS-Anbieter), mit eingebauter Unterstützung für AWS, Google Cloud und Azure.
Optional kannst du ausgewählte Abhängigkeiten auf deiner eigenen Statusseite als „Vorgelagerte Dienste“ auflisten.
Status-Badges
Jede öffentliche Statusseite stellt ein einbettbares SVG-Badge bereit – eine Live-Momentaufnahme deines Status oder deiner Uptime, die du in ein README, ein Wiki oder deine eigene Website einbauen kannst. Kein API-Schlüssel nötig, und es aktualisiert sich von selbst.
Snippet holen
Badge-URL
Markdown
Uptime-Variante
Live-Beispiel
- ✓ Selbstaktualisierend – zeigt deinen echten Status innerhalb einer Minute
- ✓ Öffentlich und eigenständig – wird überall angezeigt, wo ein Bild funktioniert
Mit deinem Coding-Agenten einrichten (MCP)
Statt die obigen Formulare von Hand auszufüllen, lass deinen Agenten den ersten Durchgang machen. Holter betreibt einen MCP-Server — verbinde Claude Code, Cursor oder einen beliebigen MCP-fähigen Agenten mit einem team-gebundenen Token, und er liest dein Repo lokal, schlägt die gefundenen Monitore vor (Crons, Queues, Health-Checks, Domains) und schreibt den Heartbeat-Code zur Prüfung für dich.
1 · MCP-Server hinzufügen
{
"mcpServers": {
"holter": {
"type": "http",
"url": "https://app.holter.sh/api/mcp",
"headers": { "Authorization": "Bearer ${HOLTER_TOKEN}" }
}
}
}
Hol dir einen team-gebundenen Token unter Einstellungen → MCP und setze ihn als HOLTER_TOKEN. Der Token ist das Einzige, was der Agent braucht — er ist auf dein Holter-Team beschränkt und gibt keinen Zugriff auf deinen Code, deine Server oder deine Cloud.
2 · Dann einfach fragen
"Set up Holter monitoring for this repo —
read holter.sh/use and follow it."
- ✓ Er liest deine Codebase lokal — Holter erhält deinen Quellcode nie
- ✓ Er schlägt die Monitore und den Heartbeat-Code vor; du prüfst und übernimmst jede Änderung
- ✓ Er arbeitet über den Token, nie mit deinen Keys — er kann deine Systeme nicht anfassen
Produktions-Monitoring-Checkliste
Jede Zeile ist in 3 Minuten eingerichtet — oder mit einem Klick über „Was überwachen“ in der App.
-
Homepage / Haupt-App antwortet
Ausgehender HTTP-Check, erwartet 200
-
API- oder Health-Endpoint antwortet
Ausgehender HTTP-Check auf /health, optional mit Abgleich eines Body-Strings
-
Antwortzeit innerhalb des Budgets
Füge ein „alarmieren wenn langsamer als“-Latenzbudget hinzu
-
HTTP leitet auf HTTPS um
Ausgehender Redirect-Check
-
TLS-Zertifikat läuft nicht bald ab
Ausgehender SSL-Check
-
Domain läuft nicht bald ab
Ausgehender Domain-Check (RDAP)
-
DNS löst weiterhin auf
Ausgehender DNS-Check
-
Nächtliches Backup abgeschlossen
Eingehender Heartbeat vom Backup-Skript
-
Queue-Worker aktiv & arbeiten Warteschlange ab
Eingehender Heartbeat von einem geplanten Worker-Ping
-
Geplante Jobs / Crons gelaufen
Eingehender Heartbeat am Ende jedes Crons
-
Kritische Pipelines (ETL, Abrechnungsläufe)
Eingehender Heartbeat bei Erfolg, /fail bei Fehler
-
Transaktionale E-Mails werden weiterhin versendet
Eingehender E-Mail-Monitor — deine App sendet nach Zeitplan an eine eindeutige Adresse
-
Datenbank-/Cache-Port erreichbar
Ausgehender TCP-Check (öffentlicher host:port)
-
Webhooks von Drittanbietern feuern weiterhin
Eingehender Heartbeat von deinem Webhook-Handler
-
Statusseite veröffentlicht
Aktiviere eine, damit sich Kunden bei Incidents selbst informieren können
-
Status des Zahlungsanbieters
Füge Stripe (oder deinen Payment-Provider) als Abhängigkeit hinzu
-
Status des Cloud-/Hosting-Anbieters
Füge AWS, GCP, Azure, Vercel… als Abhängigkeit hinzu
-
Kritische APIs von Drittanbietern
Füge OpenAI, Twilio, SendGrid… hinzu — alles, was kritische Abläufe brauchen
Starte mit einem Check.
Kostenlos für 5 Monitore, keine Karte. Hak den Rest der Liste nach und nach ab.
Kostenlos loslegen