Zum Inhalt springen

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

New monitor preview

Wie Holter überwacht

Ein Event an Holter senden Holter prüft den Endpoint

Name

Nächtliches DB-Backup

Alarmieren, wenn kein Ping innerhalb von

1 Tag

Deine Ping-URL

https://holter.sh/e/abc…/nightly-db-backup-x7k2qa

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

New monitor preview

Wie Holter überwacht

Ein Event an Holter senden Holter prüft den Endpoint

Was geprüft werden soll

HTTP-Endpoint (Status / Body / Latenz)

Endpoint

https://api.yourapp.com/health

Gesunder Status

200

Alarmieren, wenn langsamer als

2000 ms

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

New monitor preview

Anbieter

Stripe

Statusseiten-URL

https://status.stripe.com

Oder wähle aus 24 gängigen Anbietern, die wir bereits kennen.

Was hängt davon ab?

Checkout

Alarmiere mich

Bei jeder Beeinträchtigung Nur bei vollständigem Ausfall

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

New monitor preview

Badge-URL

https://app.holter.sh/status/your-page/badge

Markdown

[![Status](…/status/your-page/badge)](https://status.your-domain.com)

Uptime-Variante

https://app.holter.sh/status/your-page/badge?metric=uptime

Live-Beispiel

Holter Live-Status-Badge Holter Live-Uptime-Badge
  • ✓ 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.

Erreichbarkeit
  • 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

Zertifikate & Domains
  • 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

Hintergrundprozesse
  • 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

Grundinfrastruktur
  • 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

Vorgelagerte Abhängigkeiten · Business
  • 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