Status pages & uptime monitoring

OpenStatus

Open-Source-Statusseite und Uptime-Monitoring in einem Werkzeug: selbst hostbar, als Code konfigurierbar, geprüft aus 28 Regionen

openstatusHQ/openstatusTypeScript8,954 as of 2026-08-10
By Jake Luo · Published 10. Aug. 2026

OpenStatus ist eine Open-Source-Plattform, die eine öffentliche Statusseite mit Uptime- und API-Monitoring in einem einzigen Werkzeug verbindet — man verdrahtet also keinen Checker mit einem separaten Status-Hoster und hält danach beides von Hand synchron. Das Projekt ist TypeScript unter AGPL-3.0, verfügbar als verwalteter Dienst oder selbst gehostet mit Docker, prüft aus 28 Regionen bei drei Cloud-Anbietern und lässt sich über ein Dashboard, eine YAML-Datei, ein CLI, Terraform oder einen MCP-Server steuern. Für Gründerinnen und Gründer ist das eine Vertrauensfläche und kein Akquisekanal: aufsetzen sollte man sie vor dem ersten Vorfall, nicht während.

Was OpenStatus ist

OpenStatus führt die zwei Hälften der Vorfallkommunikation zusammen, die sonst in getrennten Produkten leben. Die eine beobachtet Server, Websites und APIs und meldet, wenn etwas ausgefallen oder langsam ist. Die andere ist die öffentliche Seite, die Kundinnen und Kunden öffnen, um herauszufinden, ob das Problem bei euch oder bei ihnen liegt. Kleine Teams zahlen am Ende meist getrennt für einen Monitoring-Dienst und einen Status-Hoster und halten beides danach manuell im Gleichklang. OpenStatus liefert beides unter AGPL-3.0 und lässt euch das Ganze selbst betreiben, wenn ihr nicht von einem Anbieter abhängen wollt, um zu verkünden, dass ein anderer Anbieter in Ordnung ist.

Das Projekt läuft seit Juni 2023 und ist tatsächlich aktiv: Zum Erhebungszeitpunkt stammten die jüngsten Commits vom Vortag, darunter eine Härtung, die private Adressbereiche bei der Validierung von Monitor-URLs blockiert. Es ist ein TypeScript-Monorepo: ein Next.js-Dashboard, ein API-Server auf Hono und ein in Go geschriebener Checker, darunter Turso, Drizzle und Tinybird. Bevor ihr einen Upgrade-Pfad plant, ist eines wichtig: Es gibt keine getaggten GitHub-Releases. Das Projekt liefert vom Hauptbranch aus und veröffentlicht stattdessen fertige Container-Images — ihr pinnt also einen Image-Digest statt einer Versionsnummer.

Was von Haus aus dabei ist

Die README benennt den Funktionsumfang konkret, was den Abgleich mit dem eigenen Bedarf einfach macht:

  • Statusseiten Eigene Domains, Passwortschutz, Wartungsfenster und Benachrichtigungen an Abonnenten per E-Mail und RSS. Der gehostete Tarif ist pauschal mit unbegrenzten Mitgliedern statt pro Sitz oder pro Abonnent — erwähnenswert, weil diese Kategorie traditionell nach der Zahl der Leute abrechnet, die wissen wollen, wann ihr ausgefallen seid.
  • Prüfungen aus 28 Regionen Monitore laufen parallel aus 28 Regionen bei drei Cloud-Anbietern. Ein Checker mit nur einer Region wird euch irgendwann melden, die Website sei tot, obwohl in Wahrheit eine Region hakt — und erfahren werdet ihr das um drei Uhr nachts.
  • Monitoring als Code Monitore, Benachrichtigungen und Statusseiten lassen sich in YAML deklarieren, über das CLI steuern, in GitHub Actions ausführen oder mit Terraform verwalten. Wenn eure Infrastruktur ohnehin in der Versionskontrolle liegt, können die Prüfungen daneben liegen und denselben Review durchlaufen.
  • Alarmierung, eine API und ein MCP-Server Alarme gehen an Slack, Discord, PagerDuty oder E-Mail. Dazu kommen eine typisierte JSON-über-HTTP-API mit Node-SDK, ein CLI mit einem auf Agenten zugeschnittenen `--json`-Modus und ein MCP-Server, damit ein Assistent den Workspace direkt abfragt, statt ein Dashboard zu scrapen.
  • Selbst hosten Eine Docker-Compose-Datei bringt den Stack lokal hoch, dazu gibt es veröffentlichte Images und eine Anleitung für das Deployment mit Coolify. Private Locations — Prüfungen, die innerhalb eures eigenen Netzes gegen Dinge laufen, die das öffentliche Internet nicht erreicht — kommen als ein einziges 8,5-MB-Image.

Was es nicht ist: OpenStatus beobachtet Endpunkte, nicht das Innenleben eurer Anwendung. Es beantwortet, ob das, was eure Kundschaft anfasst, antwortet und wie schnell — nicht, warum es aufgehört hat. Tracing und Log-Aggregation sind eine andere Werkzeugkategorie, und das Projekt behauptet nichts anderes.

Wo es in den Wachstums-Stack einer Gründung passt

Eine Statusseite ist kein Akquisekanal, und das sollte man deutlich sagen: Sie bringt keinen Traffic. Was sie tut, ist Reibung an zwei sehr konkreten Punkten wegnehmen — wenn ein Interessent abwägt, ob ihr eine echte Firma seid, und wenn bestehende Kundschaft entscheidet, ob sie eine E-Mail schreibt oder fünf Minuten wartet. Beides ist Vertrauensarbeit, näher an Social Proof als an Marketing. Derselbe Instinkt, der Documenso betreibenswert macht, gilt hier: Die Artefakte, die eine kleine Firma verlässlich wirken lassen, sind billig im Betrieb und teuer, wenn sie an genau dem Tag fehlen.

Der Auslöser zum Aufsetzen ist die erste zahlende Kundin, nicht der erste Ausfall. Eine während eines Vorfalls angelegte Statusseite hat keine Abonnenten, liegt auf einer Domain, die niemand kennt, und wurde von jemandem geschrieben, der gerade sehr beschäftigt ist. Die Einrichtung kostet eine Stunde, deren gesamter Wert daran hängt, dass sie vor dem Ereignis existiert, für das sie gedacht ist. Wer an Entwicklerinnen und Entwickler verkauft, hat einen zweiten Grund: Statusseite und Changelog gehören zu den wenigen Seiten, die technische Käufer von sich aus ansteuern, gleich neben eurer Dokumentation. Mehr zu diesem Publikum in wie vermarkte ich ein Entwicklerwerkzeug.

Was wir gelernt haben, als wir einen Checker auf die eigene Flotte richteten

Diesen Teil steuern wir aus dem Betrieb bei, nicht aus der Lektüre. AgentCeres — der AI Growth Officer unter agentceres.com — betreibt pro Kunden-Workspace einen eigenen Container, und ungenutzte skalieren auf null herunter, damit die Rechnung im Rahmen bleibt. Damit werden "antwortet nicht" und "schläft" zu zwei verschiedenen Zuständen, und das hat unsere Monitoring-Instinkte zweimal gebrochen. Erstens ist eine Sonde nicht kostenlos: Jede Prüfung gegen einen auf null skalierenden Dienst weckt ihn, also zahlt der Monitor den Kaltstart und löscht still die Ersparnis, die er bewachen sollte. Wir haben einen Workspace, der praktisch dauerhaft wach war, am Ende auf einen vergessenen eingeloggten Browser-Tab zurückgeführt, der alle paar Minuten einen Hintergrund-Endpunkt abfragte — während der Rest der Flotte im einstelligen Bereich lag. Zweitens mussten unsere eigenen Health Checks lernen, "schläft" zu melden, ohne überhaupt zu sondieren. Ein Satz, der erst Sinn ergibt, wenn man entschieden hat, was "läuft" für die eigene Architektur eigentlich heißt.

Bevor ihr einen Checker auf irgendetwas richtet
  • Entscheidet zuerst, was "läuft" für euren Dienst bedeutet. Eine Architektur mit Kaltstart oder Skalierung auf null liest sich unter einer naiven Prüfung als langsam oder tot, und die Prüfung selbst verändert das, was sie misst.
  • Überwacht den Endpunkt, den eure Kundschaft anfasst, nicht den internen, der billig zu treffen ist. Sie fallen unterschiedlich aus, und nur einer davon kostet euch Kundschaft.
  • Setzt das Timeout über eure reale Kaltstartzeit. Ein Alarm, der zweimal pro Woche falsch schreit, ist ein Alarm, den ihr schon zu ignorieren gelernt habt.
  • Stellt die Seite online, solange nichts kaputt ist. Eigene Domain, DNS und Abonnenten lassen sich an einem ruhigen Nachmittag deutlich leichter organisieren.

FAQ

Ist OpenStatus kostenlos?
Selbst hosten ist kostenlos: Das Repository steht unter AGPL-3.0, mit Docker-Compose-Setup und veröffentlichten Container-Images. Lest die Lizenz, wenn ihr es verändern und Dritten als Dienst anbieten wollt — genau dafür ist die AGPL geschrieben. Für den Betrieb als eigene Statusseite erlegt sie euch nichts Unangenehmes auf. Das Projekt verkauft außerdem eine verwaltete Variante, und deren erklärter Ansatz ist Pauschalpreis mit unbegrenzten Mitgliedern statt der in dieser Kategorie üblichen Abrechnung pro Sitz oder pro Abonnent.
Brauche ich als kleines Start-up wirklich eine Statusseite?
Nicht am ersten Tag und nicht vor der ersten zahlenden Kundschaft. Sie fängt in dem Moment an, sich zu rechnen, in dem ein Ausfall sonst Support-E-Mails erzeugt, die ihr einzeln beantworten müsst, oder in dem ein Käufer fragt, wie ihr mit Vorfällen umgeht. Davor ist eine Statusseite ohne Abonnenten und ohne Historie Dekoration. Danach ist sie der billigste Weg, ein Eins-zu-viele-Problem wieder in eine Eins-zu-viele-Antwort zu verwandeln.
Reicht nicht einfach ein kostenloser Uptime-Checker?
Für die Alarm-Hälfte ja — es gibt reichlich kostenlose Checker, die eine URL anpingen und melden, wenn sie nicht mehr antwortet, und wenn das alles ist, was ihr braucht, nehmt es. Der Unterschied ist die öffentliche Hälfte: die Seite, die eure Kundschaft lesen kann, ohne euch zu schreiben, mit Abonnements, Wartungsfenstern und einer sichtbaren Historie, die Zuverlässigkeitsaussagen überprüfbar macht statt bloß behauptet. OpenStatus lohnt den Aufwand, wenn beide Hälften eine gemeinsame Konfiguration teilen sollen, statt mit der Zeit auseinanderzudriften.
Related projects
LangfuseOpen-Source-LLM-Engineering-Plattform — Tracing und Observability, Prompt-Management, Evaluierungen, Datasets und ein Playground für Teams, die KI-Anwendungen bauenDocumensoDie Open-Source-Alternative zu DocuSign — selbst hostbares Dokumenten-Signieren, gebaut damit Sie prüfen können, wie die Signatur zustande kamDocusaurusOpen-Source-Generator für statische Dokumentationswebsites, veröffentlicht von MetaChatwootOpen-Source-Plattform für Kundensupport — Live-Chat, ein gemeinsamer Posteingang und ein Omnichannel-Helpdesk

You built it. Now grow it.

AgentCeres is a managed AI marketing team — specialists draft the SEO, social, and outreach that fill your links, you approve what ships. 14-day free trial, from $39/month.

Start free trialMore projects