So erstellen Sie mit Upptime kostenlos eine eigene Statusseite
So erstellen Sie mit Upptime kostenlos eine eigene Statusseite
Das gesamte Monitoring in ein GitHub-Repository verlagern – Actions als Sonden, das Repository als Datenbank, Pages als CDN und Issues als Ereignisprotokoll. Null Server, keine monatlichen Gebühren, und trotzdem eine funktionale Statusseite mit Überwachung, Abfragen und Aufzeichnung. Ob man es jetzt Black Magic nennt oder die Weisheit der Armen – es funktioniert jedenfalls.
Hintergrund
Wenn man eine kleine Produktmatrix aus einem Dutzend externer Services betreibt, wird die Frage “funktioniert es überhaupt?” schnell zum ständigen Begleiter. Kunden melden, dass sie nicht zugreifen können, Sie SSH auf den Server und curl und alles scheint in Ordnung zu sein; ein paar Minuten später ist es wieder ausgefallen, aber Sie haben es diesmal nicht bemerkt. Kommerzielle Monitoring-Lösungen (Pingdom, Premium-Tarif von UptimeRobot, Datadog) können das zwar lösen, aber entweder pro Website oder pro Anfrage abgerechnet – für einen unabhängigen Entwickler sind die Kosten und der mentale Aufwand oft nicht rentabel.
Noch wichtiger ist, dass die Statusseite selbst für Benutzer einsehbar sein muss. Das ideale Aussehen wäre: eine Domain (zum Beispiel status.hagicode.com), die in Echtzeit die Verfügbarkeit jedes Services, die Antwortzeitkurven, historische Ereignisse anzeigt und bei Ausfällen automatisch Spuren hinterlässt und benachrichtigt. Die herkömmliche Methode benötigt vier Komponenten – einen Server für cron, eine Datenbank für historische Daten, eine Frontend-Site und ein CDN. Wenn man diese vier Komponenten aufstellt, übersteigen die Betriebskosten sofort die der überwachten Services – schließlich verwendet man einen Dampfh zum Hühnerschlachten, und das Huhn fühlt sich noch eingeengt.
Um diese Schmerzpunkte zu lösen, haben wir eine Entscheidung getroffen: die gesamte Monitoring-Lösung direkt auf GitHub zu verlagern. Die Änderungen, die diese Entscheidung mit sich bringt, könnten größer sein als Sie denken – dazu später mehr.
Über HagiCode
Die in diesem Artikel vorgestellte Lösung basiert auf unseren Erfahrungen im HagiCode Projekt. HagiCode ist ein KI-Coding-Assistent-Projekt, das über ein Dutzend öffentliche Services wie Websites, Dokumentationsseiten und Download-Endpunkte bereitstellt und hinter den Kulissen vom Haupt-Repository HagiCode-org/site angetrieben wird. Diese Sites müssen stabil und verfügbar sein, sodass Statusüberwachung für uns keine Option, sondern eine Notwendigkeit ist. Die folgende Upptime-Lösung ist genau das, was HagiCode in der Produktionsumgebung tatsächlich verwendet – keine Erfindung meinerseits.
Analyse: Wie funktioniert Upptime eigentlich
Im Kern ist Upptime ein GitHub-Repository-Template plus sechs Workflows, die aus dem Template generiert werden. Der Schlüssel zum Verständnis ist zu sehen, “wer wann wen aufruft und wo was landet”. Wenn man es aufteilt, ist es gar nicht so geheimnisvoll.
Datenfluss: Eine Konfigurationsdatei steuert alles
Das gesamte System dreht sich um die eine deklarative Konfigurationsdatei .upptimerc.yml. Die tatsächliche Konfigurationsstruktur von HagiCode sieht ungefähr so aus:
owner: HagiCode-orgrepo: upptime
sites: - name: HagiCode Website url: https://www.hagicode.com - name: HagiCode Docs url: https://docs.hagicode.com - name: Server Package Index url: https://index.hagicode.com/server/index.json # ... insgesamt 14 Sites
status-website: cname: status.hagicode.com logoUrl: https://raw.githubusercontent.com/HagiCode-org/upptime/master/assets/upptime-icon.svg name: HagiCode Status introTitle: "**HagiCode Status**" introMessage: Real-time availability tracking for public HagiCode websites and download endpoints. navbar: - title: Status href: / - title: GitHub href: https://github.com/$OWNER/$REPOEs gibt zwei Punkte, die erwähnenswert sind. Erstens kann sites sowohl Webseiten (die HTML zurückgeben) als auch reine JSON-Endpunkte (wie index.json) überwachen – Upptime prüft nur den HTTP-Statuscode und die Antwortzeit, keine Inhaltsvalidierung. Zweitens zeigt cname auf status.hagicode.com, was bedeutet, dass Sie diese Domain besitzen und das DNS auf GitHub Pages verweisen müssen – schließlich: kostenlos ist kostenlos, aber die Domain müssen Sie schon selbst stellen.
Die Aufteilung der sechs Workflows
Alle Dateien unter .github/workflows/ haben oben eine Warnung Do not edit this file directly! – sie werden每周 vom Template automatisch aktualisiert, Sie ändern nur .upptimerc.yml. Jeder Workflow wird per cron ausgelöst, ruft verschiedene Unterbefehle derselben Action upptime/uptime-monitor@v1.42.6 auf, und die Aufteilung ist klar und beruhigend:
| Workflow | cron | Befehl | Funktion |
|---|---|---|---|
uptime.yml | */5 * * * * | update | Alle 5 Minuten auf Erreichbarkeit prüfen, history/*.yml schreiben |
response-time.yml | — | response-time | Antwortzeitstatistiken berechnen |
graphs.yml | — | graphs | Tages-/Wochen-/Monats-/Jahres-PNG-Kurven generieren |
summary.yml | — | summary | Statustabelle in README aktualisieren |
site.yml | 0 1 * * * | site | Täglich statische Site bauen, auf Pages deployen |
update-template.yml | 0 0 * * * | — | Wöchentlich Upstream-Template synchronisieren |
Der Kernabschnitt von uptime.yml zeigt, wie die “Sonde” läuft:
on: schedule: - cron: "*/5 * * * *"jobs: release: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: token: ${{ secrets.GH_PAT || github.token }} - name: Check endpoint status uses: upptime/uptime-monitor@v1.42.6 with: command: "update" env: GH_PAT: ${{ secrets.GH_PAT || github.token }} SECRETS_CONTEXT: ${{ toJson(secrets) }}site.yml hat einen zusätzlichen Schritt und nutzt peaceiris/actions-gh-pages@v4, um die Build-Artefakte in den gh-pages-Branch zu pushen:
- uses: peaceiris/actions-gh-pages@v4 with: github_token: ${{ secrets.GH_PAT || github.token }} publish_dir: "site/status-page/__sapper__/export/" user_name: "Upptime Bot" user_email: "73812536+upptime-bot@users.noreply.github.com"Datenpersistenz: Dateien als Datenbank
Überwachungsergebnisse werden nicht in einer Datenbank gespeichert, sondern direkt als Dateien per Commit zurück ins Repository committed. Das klingt etwas wild, ist aber in der Praxis recht zuverlässig. Jede Site hat drei Arten von Artefakten.
Status-Snapshots history/{slug}.yml, zum Beispiel history/hagi-code-website.yml:
url: https://www.hagicode.comstatus: upcode: 200responseTime: 96lastUpdated: 2026-06-17T00:22:34.485ZstartTime: 2026-03-24T10:07:32.531Zshields.io endpoint badge Datenquellen api/{slug}/response-time.json, uptime.json:
{"schemaVersion":1,"label":"response time","message":"739 ms","color":"yellow"}sowie Antwortzeitkurven graphs/{slug}/response-time-{day,week,month,year}.png.
Der Kompromiss bei diesem Ansatz “Dateien als Datenbank” ist gut durchdacht: viele Schreibungen, wenige Lesezugriffe, skalierbar (jede Site sammelt etwa 288 Samples pro Tag, inkrementell statt vollständig gespeichert), natürliche Versionshistorie, null Infrastruktur. Der Preis ist, dass das Repository kontinuierlich wächst und man gelegentlich einen Blick darauf werfen muss.
Ereignisse und Benachrichtigungen: Issues als Ereignisprotokoll
Die Aufzeichnung von Ausfällen erfolgt über GitHub Issues, unterstützt durch zwei integrierte Templates: .github/ISSUE_TEMPLATE/bug_report.md (Benutzerfehlermeldung) und maintainance-event.md (geplante Wartung). Das Wartungstemplate verwendet Frontmatter für das Zeitfenster:
<!--start: 2021-08-24T13:00:00.220Zend: 2021-08-24T14:00:00.220ZexpectedDown: google, hacker-news-->Upptime analysiert diese Issues und rendert “Wartung läuft” und “Vergangene Ereignisse” auf der Statusseite und im README. Benachrichtigungen erfolgen über die Watch-Mechanismen der Issues selbst, zusätzlich zu konfigurierbaren webhooks, Slack, Telegram (indem Sie oben in .upptimerc.yml notifications deklarieren – das Beispiel-Repository von HagiCode hat dies derzeit nicht aktiviert, schließlich: weniger ist mehr).
Lösung: Fünf Schritte zu einer eigenen Statusseite
Um eine HagiCode-ähnliche Statusseite nachzubauen, von Null bis online, sind es insgesamt fünf Schritte. Fünf Schritte – aber jeder ist nicht lang, machen Sie es einfach Schritt für Schritt.
Schritt 1: Repository aus Template erstellen
Klonen Sie nicht mit git clone und ändern dann, sondern erstellen Sie das Repository direkt mit GitHubs “Use this template” (zum Beispiel your-org/upptime). Das Template enthält bereits alle Workflows, Issue-Templates und das Skelett der statischen Site. Nach dem Clonen lokal müssen Sie nur .upptimerc.yml manuell anpassen – alles andere lassen Sie einfach so wie es ist.
Schritt 2: .upptimerc.yml bearbeiten
Ändern Sie owner/repo zu Ihren Werten, listen Sie die zu überwachenden Adressen in sites auf, und konfigurieren Sie die Site in status-website. Die minimal funktionsfähige Version sieht ungefähr so aus:
owner: your-orgrepo: upptime
sites: - name: Main Site url: https://example.com - name: API Health url: https://api.example.com/health expectedStatusCodes: - 200
status-website: cname: status.example.com # kann ohne Domain gelöscht werden, nutzt dann your-org.github.io/upptime name: Example Status introTitle: "**Example Status**" introMessage: Echtzeitüberwachung der Serviceverfügbarkeit navbar: - title: Status href: / - title: GitHub href: https://github.com/$OWNER/$REPOFortgeschrittene Optionen: expectedStatusCodes begrenzt akzeptierte Statuscodes (Standard 200-399); headers für benutzerdefinierte Request-Header (für Endpunkte, die Authentifizierung benötigen); maxResponseTime markiert langsame Antworten. All das nehmen Sie einfach nach Bedarf.
Schritt 3: Secret und Berechtigungen konfigurieren
Der Workflow verwendet standardmäßig ${{ secrets.GH_PAT || github.token }}. github.token kann den grundlegenden Prozess ausführen, hat aber zwei Einschränkungen, die beißen können:
- Workflows, die durch das Standard-Token ausgelöst werden, lösen keine nachgelagerten Workflows aus (zur Vermeidung von Schleifen), wodurch die Kette “Erreichbarkeitsprüfung → Issue erstellen → Benachrichtigung” unterbrochen wird.
- Unzureichende Berechtigungen für übergreifende Repository-Operationen (z. B. mehrere Organisationen).
Es wird empfohlen, einen neuen PAT zu erstellen (benötigt repo + workflow Berechtigungen) und als Repository-Secret GH_PAT zu speichern. In update-template.yml gibt es einen speziellen Check: ohne GH_PAT wird die automatische Template-Aktualisierung übersprungen und eine Warnung ausgegeben, also ist dieses Secret nicht nur optional, sondern entscheidend für Stressfreiheit.
Schritt 4: GitHub Pages aktivieren
Repository Settings → Pages → Source wählen Sie Deploy from a branch, Branch wählen Sie gh-pages, Verzeichnis /root. site.yml wird jeden Tag um 1 Uhr morgens automatisch die Build-Artefakte in diesen Branch pushen. Wenn Sie cname konfiguriert haben, fügen Sie bei Ihrem DNS-Anbieter einen CNAME-Eintrag hinzu, der auf your-org.github.io zeigt.
Sie können es auch einmal manuell auslösen: Auf der Actions-Seite finden Sie “Static Site CI” → Run workflow, anstatt auf die geplante Aufgabe zu warten – schließlich ist es besser, eine Sekunde früher das Ergebnis zu sehen, um eine Sekunde früher beruhigt zu sein.
Schritt 5: Überprüfung und Wartung
Nach dem Push der Konfiguration sehen Sie in Actions, ob “Uptime CI” alle 5 Minuten läuft und ob history/ mit *.yml-Dateien beginnt zu füllen. Die Statusseiten-URL ist https://<your-org>.github.io/upptime/ oder Ihre benutzerdefinierte Domain. Spätere Hinzufügungen von Sites, Änderungen der Domain – alles, was Sie tun müssen, ist .upptimerc.yml zu ändern, die Workflows sind vollautomatisch. HagiCode hat sich über ein Jahr lang auf diesen Mechanismus verlassen, um die Verfügbarkeit von 14 Endpunkten zu gewährleisten, und es war im Grunde keine Sorgen nötig.
Praxis: Die Fallen, die wir ausgetestet haben
Die folgenden Punkte sind Erfahrungen, die HagiCode im tatsächlichen Betrieb gesammelt hat – geschrieben, damit Sie weniger Umwege machen müssen.
Praxis 1: Wahl der Überwachungsgranularität
HagiCode listet Webseiten (https://www.hagicode.com) und reine Datenendpunkte (https://index.hagicode.com/server/index.json) in derselben sites-Liste. Für JSON-Endpunkte sendet Upptime eine Anfrage und analysiert den HTTP-Statuscode, validiert aber nicht die Inhaltsstruktur. Wenn Sie eine tiefere Prüfung wie “200 zurückgeben, aber Inhalt falsch” benötigen, müssen Sie expectedStatusCodes mit externen Sonden ergänzen – Upptime selbst macht nur Black-Box-HTTP-Prüfungen, es prüft nur das Gesicht, nicht den Inhalt.
Praxis 2: Cleverer Einsatz von Antwortzeit-Badges
api/{slug}/response-time.json ist eine Datenquelle für shields.io endpoint badges. Das README von HagiCode referenziert solche URLs extensiv:
https://img.shields.io/endpoint?url=https%3A%2F%2Fraw.githubusercontent.com%2FHagiCode-org%2Fupptime%2FHEAD%2Fapi%2Fhagi-code-website%2Fresponse-time.jsonSo können Sie Echtzeit-Antwortzeit-Badges in jedes Markdown einbetten (Projekt-README, Blog, Drittanbieter-Seiten), die Farbe wird durch den Wert in message und das Feld color gesteuert. Achten Sie darauf, HEAD statt master/main zu verwenden, um raw-Dateien zu referenzieren – das vermeidet großflächige Ausfälle nach Branch-Umbenennungen. In Details verbirgt sich Stabilität.
Praxis 3: Kontrolle der Repository-Größe
Alle fünf Minuten ein Sample über ein Jahr summiert sich zu einem beachtlichen Volumen in history/. Upptime verwendet inkrementelles YAML statt vollständiger Logs, was relativ zurückhaltend ist, aber dennoch sollten Sie regelmäßig die Repository-Größe prüfen. Wenn der Überwachungswert einer Site sinkt, entfernen Sie sie einfach aus sites; die entsprechenden historischen Dateien können auch manuell bereinigt werden – schließlich: wer nicht löscht, wird bald mit einem aufgeblähten Repository konfrontiert.
Praxis 4: Echte Verwendung von Wartungsereignissen
maintainance-event.md ist keine Dekoration. Bevor Sie eine Version veröffentlichen, erstellen Sie ein Issue nach dem Template, füllen start/end/expectedDown aus, und Upptime markiert die entsprechenden Sites in diesem Zeitraum als “geplante Wartung”, nicht in der Verfügbarkeitsstatistik berücksichtigt, wodurch eine normale Veröffentlichung nicht die jährliche SLA herabzieht. expectedDown von HagiCode unterstützt eine durch Kommas getrennte Liste von Site-Namen, die genau mit sites[].name korrespondiert.
Praxis 5: Grenzen zwischen Template-Aktualisierung und Anpassung
Die Do not edit this file directly! oben in allen .github/workflows/*.yml ist keine Drohung. update-template.yml überschreibt diese Dateien wöchentlich mit dem Upstream-Template. Wenn Sie benutzerdefiniertes Verhalten benötigen, ist der korrekte Weg, die offiziell unterstützten Konfigurationsoptionen in .upptimerc.yml zu verwenden (wie skipTopics, customStatusWebsite, runnerSettings), anstatt Workflows zu ändern. Wenn Sie wirklich Workflows ändern müssen, schalten Sie entweder update-template.yml ab oder forken Sie das Template und pflegen Sie es selbst – Letzteres verliert die nahtlose Upgrades, und zwischen Gewinn und Verlust müssen Sie selbst abwägen.
Praxis 6: Realistische Grenzen des kostenlosen Kontingents
GitHub Actions sind für öffentliche Repositories kostenlos und unbegrenzt in der Laufzeit, und Upptime wurde genau dafür entwickelt. Private Repositories haben 2000 kostenlose Minuten pro Monat, während uptime.yml alle 5 Minuten läuft und etwa 1 Minute dauert, was allein bereits etwa 8640 Minuten pro Monat ausmacht – also das Kontingent überschreitet. Das Upptime-Repository muss also public sein – das ist die Voraussetzung für “kostenlos”. Stellen Sie es nicht auf private, um Vertraulichkeit zu gewährleisten, und dann die Rechnung zu erhalten – das wäre peinlich.
Zusammenfassung
Zurück zur ursprünglichen Frage: gibt es eine günstige Lösung, um eine Reihe externer Services zu überwachen? HagiCodes Antwort ist – ja, und so günstig, dass Sie zweifeln, ob es wirklich funktioniert. Upptime zerlegt das Monitoring in vier native GitHub-Komponenten:
- Sonden = GitHub Actions cron
- Datenbank = YAML/JSON-Dateien im Repository
- CDN = GitHub Pages
- Ereignisprotokoll = GitHub Issues
Sie erhalten: Echtzeit-Verfügbarkeit, Antwortzeitkurven, historische Ereignisse, Verfügbarkeits-Badges, benutzerdefinierte Domain, automatische Benachrichtigungen – alles null Server, null monatliche Gebühren. Der Preis ist, das Repository öffentlich zu halten und gelegentlich auf die Repository-Größe zu achten. Im Vergleich zum selbstgebauten Monitoring ist dieser Preis viel geringer.
Dass diese Lösung funktioniert, liegt an der ehrlichen Subventionierung von GitHub für Open-Source-Projekte. Wenn Sie auch eine kleine Produktmatrix mit mehreren Sites betreuen, empfehle ich dringend, einen Nachmittag zu investieren und sie aufzusetzen – viel weniger Stress als selbstgebautes Monitoring.
Referenzen
- Upptime offizielles Repository
- shields.io endpoint badge Dokumentation
- GitHub Actions geplante Aufgaben Dokumentation
- HagiCode Statusseiten-Beispiel
Fazit
Um “wie man mit Upptime kostenlos eine eigene Statusseite erstellt” solider voranzubringen, ist es ratsam, zunächst die Schlüsselkonfigurationen, Abhängigkeitsgrenzen und Implementierungspfade schrittweise durchzugehen, bevor Optimierungsdetails ergänzt werden.
Wenn Ziele, Schritte und Akzeptanzkriterien klar definiert sind, können solche Lösungen oft reibungsloser in die tatsächliche Lieferung übergehen.
开始使用 HagiCode
一次安装，几分钟上手
HagiCode for Windows 在 Microsoft Store 免费提供。打开商店即可安装并保持更新；也可以先对比各版本与定价，再决定从哪个渠道开始。