Uptime Monitoring mit GitHub: Tools, Grenzen, Alternativen

5. September 2026 · 5 Min. Lesezeit

Wer nach „uptime monitoring github“ sucht, meint meistens eine von zwei sehr verschiedenen Sachen. Entweder ein Open-Source-Tool, dessen Repository auf GitHub liegt und das du auf einem eigenen Server betreibst. Oder GitHub selbst als Prüfmotor, also GitHub Actions als Cron, GitHub Issues als Incident-Log, GitHub Pages als Statusseite. Beides ist legitim, beides hat harte Kanten. Hier stehen sie.

Weg 1: GitHub Actions prüft deine Dienste (Upptime)

Das bekannteste Projekt dieser Bauart ist Upptime. Du forkst ein Template-Repository, schreibst deine URLs in die .upptimerc.yml, aktivierst Actions, und ab dann läuft ein geplanter Workflow, der die Endpunkte abfragt. Ausfälle landen als GitHub Issue, die Antwortzeiten als Commits, die Statusseite wird auf GitHub Pages veröffentlicht. Kein Server, keine Datenbank, alles versioniert und öffentlich nachlesbar.

Für ein Open-Source-Projekt, das seinen Nutzern eine transparente Statusseite geben will, finde ich das eine charmante Lösung. Als Alarmierungssystem für Dienste, mit denen du Geld verdienst, halte ich es für die falsche Wahl. Die Gründe liegen nicht in der Software, sondern in der Plattform darunter.

Was GitHub Actions als Monitoring-Runner nicht leisten kann

Das Intervall ist nach unten begrenzt. Der kürzeste Cron-Abstand für geplante Workflows liegt bei fünf Minuten. Mehr geht nicht, und weniger brauchst du eigentlich auch nicht. Das Problem ist der zweite Teil: GitHub dokumentiert selbst, dass geplante Läufe bei hoher Last verzögert werden können. Aus fünf Minuten werden dann fünfzehn oder mehr. Deine Statusseite behauptet in dieser Zeit weiterhin „grün“, weil der letzte Lauf grün war. Ein Ausfall, der zwischen zwei verzögerten Läufen anfängt und endet, existiert in deinen Daten nicht.

Bei öffentlichen Repos schaltet GitHub geplante Workflows nach 60 Tagen ohne Repository-Aktivität ab. Wer sein Monitoring-Repo einmal einrichtet und dann nie wieder anfasst, hat irgendwann ein Monitoring, das nichts mehr tut. Auffallen wird es dir nicht, denn ein Check, der nicht läuft, meldet auch keinen Fehler. Das ist das unangenehmste Fehlerbild überhaupt: stiller Ausfall der Überwachung.

Prüfung und Alarmweg hängen an derselben Plattform. Hat GitHub eine Störung bei Actions, laufen deine Checks nicht. Hat GitHub eine Störung bei Issues oder Notifications, kommt der Alarm nicht durch. Dass beide Fälle vorkommen, kannst du auf der GitHub-Statusseite nachlesen. Monitoring soll unabhängig von dem sein, was es beobachtet, und mindestens genauso unabhängig von seinem eigenen Meldeweg.

Ein Standort, wechselnde IPs. Hosted Runner sitzen in einer Cloud-Region und bekommen jedes Mal andere Adressen aus großen Cloud-Netzen. Wenn deine WAF, Cloudflare-Regeln oder Fail2ban solche Ranges drosseln, bekommst du 403er, die nichts über deinen Dienst aussagen. Zwei Wochen später klickt niemand mehr die Issues weg, weil sie ohnehin immer rot sind.

Weg 2: Open-Source-Tools von GitHub, selbst betrieben

Hier reden wir über Software, die du aus einem GitHub-Repo holst und in einem Container laufen lässt. Diese Werkzeuge sind self-hosted, und genau das ist ihr Vorteil und ihr Preis.

Uptime Kuma ist der Klassiker: eine Weboberfläche, HTTP-, Ping-, TCP-, DNS- und Keyword-Checks, eine lange Liste an Benachrichtigungskanälen von E-Mail über Telegram bis Webhook. In zehn Minuten per Docker aufgesetzt, angenehm zu bedienen.

Gatus geht den anderen Weg und konfiguriert alles über YAML, mit Bedingungen als Ausdrücken. [STATUS] == 200 und [RESPONSE_TIME] < 300 stehen direkt in der Definition, dazu Prüfungen auf Inhalte des Response Bodys. Wer seine Monitoring-Konfiguration im Git-Repo neben dem Deployment haben will, ist damit gut bedient.

Healthchecks löst ein verwandtes, oft vergessenes Problem: Cronjobs und Backups, die einfach nicht mehr starten. Der Job meldet sich per HTTP-Ping, und wenn die Meldung ausbleibt, gibt es Alarm. Ein HTTP-Check von außen sieht davon nichts.

Die Grenze aller drei ist dieselbe. Läuft dein Monitoring auf demselben Docker-Host, demselben Hypervisor oder im selben Rechenzentrum wie der überwachte Dienst, misst es im entscheidenden Moment nichts. Ein Stromausfall im Rack nimmt beide mit. Dazu kommt die Pflege: Updates, Backup der Konfiguration und der Historie, TLS für die Oberfläche, Erreichbarkeit der Instanz auch dann, wenn dein Netz Probleme hat. Das ist machbar, es ist aber Arbeit, die niemand einplant, wenn er das Ding an einem Freitagabend aufsetzt.

Was du sinnvoll aus GitHub heraus prüfen solltest

GitHub Actions ist ein schlechter Wächter, aber ein guter Testläufer. Diese Dinge gehören dort hin und nicht in ein Monitoring-Tool:

Smoke-Test direkt nach dem Deploy, im selben Workflow. Antwortet /health nach dem Rollout mit 200, und liefert die Startseite den erwarteten String? Wenn nicht, Rollback, bevor Nutzer es merken.
Ein wöchentlicher Job, der Abhängigkeiten und Container-Images auf bekannte Lücken prüft.
Link-Checker und Lighthouse-Läufe auf Staging, wo eine Verschlechterung noch billig zu beheben ist.
Vertragstests gegen fremde APIs, die sich still ändern.

Der Unterschied ist der Zeitpunkt. Actions prüft, wenn du etwas änderst. Monitoring prüft, wenn du gerade nicht hinschaust. Wo genau die Trennlinie liegt, habe ich in was Uptime Monitoring prüft und wo es aufhört ausführlicher aufgeschrieben.

Wann ein externer Dienst die bessere Wahl ist

Sobald ein Ausfall echte Konsequenzen hat, brauchst du drei Eigenschaften, die eine GitHub-Actions-Lösung strukturell nicht mitbringt: eine Prüfung von außerhalb deiner Infrastruktur, einen Alarmweg, der von der geprüften Plattform unabhängig ist, und ein Intervall, das nicht in einer Warteschlange hängt.

Dazu kommen die Prüfarten, die im Alltag mehr Vorfälle verhindern als der reine HTTP-Status. Ein ablaufendes SSL-Zertifikat kündigt sich Wochen vorher an, wenn jemand die Restlaufzeit im Blick hat, und trifft dich sonst an einem Sonntagmorgen. Ein DNS-Eintrag, der nach einem Providerwechsel plötzlich woanders zeigt, sieht für einen Statuscode-Check völlig gesund aus. Und der Fall, der am häufigsten unterschätzt wird: Die Seite ist erreichbar, braucht aber statt 300 Millisekunden acht Sekunden. Formal keine Störung, praktisch schon.

Mein Rat, wenn du gerade zwischen den Optionen stehst: Nutze GitHub für das, was zu deinem Code gehört, also Tests und Deploy-Checks. Nutze Uptime Kuma oder Gatus, wenn du gerne Infrastruktur pflegst und der Monitoring-Host garantiert nicht am gleichen Strang hängt wie der Dienst. Und nimm einen Dienst von außen, wenn dein Interesse darin besteht, im Ausfall benachrichtigt zu werden, statt ein weiteres System zu betreuen.

Uptime Alien prüft genau von dieser Außenposition aus, mit HTTP, TCP, DNS, SSL und API-Checks und Alarmen, die nicht an der Plattform hängen, die gerade Probleme macht. Wenn du sehen willst, wie das für deine Domains aussieht, bevor du irgendwas umstellst: die Demo ist ohne Anmeldung anklickbar.