MOSSBoard – Max’s OpenSource Status Board

Ich freue mich, MOSSBoard vorzustellen — Max’s OpenSource Status Board, ein selbst gehostetes Statusboard für den Betrieb eigener Dienste, das ich in den letzten Wochen entwickelt habe und heute als Open-Source-Projekt veröffentliche.

MOSSBoard Hauptansicht — MOSSBoard — die öffentliche Statusseite

Was ist MOSSBoard?

Wer mehrere Dienste betreibt — ob im Homelab, für Kunden oder im Unternehmensumfeld — kennt das Problem: Man braucht eine zentrale, übersichtliche Ansicht über den aktuellen Zustand aller Systeme.

MOSSBoard ist die Antwort darauf. Vollständig selbst gehostet, Docker-basiert und kostenlos.

Funktionen im Überblick

Öffentliche Statusseite

Statusseite Detailansicht — Service-Detailansicht mit 24h-Verlauf und 30-Tage-Uptime

Die öffentliche Statusseite zeigt alle Dienste gruppiert nach Sektionen (z. B. „Infrastruktur“, „Anwendungen“). Jeder Dienst hat:

Ein farbiges Statusbadge (Operational, Performance Issues, Partial Outage, Major Outage, Under Maintenance, Unknown)
Eine 24-Stunden-Verlaufsleiste mit 5-Minuten-Auflösung (288 Blöcke)
Eine 30-Tage-Uptime-Zusammenfassung in der Detailansicht
Ein Statusprotokoll mit optionalen Anmerkungen zu jeder Änderung

Sektionen, in denen alle Dienste operativ sind, werden automatisch eingeklappt. Ein Gesamtstatus-Banner oben zeigt den schlechtesten aktuellen Status aller sichtbaren Dienste.

Vollbild-Monitor

Ideal für Bildschirme im Serverraum oder Büro: /monitor öffnet eine vollbildoptimierte Ansicht mit Live-Uhr, Statusgitter und pulsierenden Indikatoren für nicht-operative Dienste. Automatische Aktualisierung alle 30 Sekunden.

Aktives Monitoring

MOSSBoard führt selbst aktive Checks durch — ohne externe Tools. Vier Prüftypen stehen zur Verfügung:

Typ	Was wird geprüft
HTTP	GET-Request, HTTP-Statuscode und Antwortzeit
TCP	TCP-Verbindung zu `host:port`, Verbindungszeit
ICMP	Ping (`ping -c 3`), Paketverlust und Round-Trip-Time
DNS	DNS-Auflösung, Antwortwerte und Latenz

Die Statuszuordnung erfolgt über konfigurierbare Schwellenwert-Regeln (max_ms → Status). Mehrere Regeln können gestapelt werden — die erste passende gewinnt. Beispiel:

≤ 200 ms  →  operational
≤ 800 ms  →  performance_issues
> 800 ms  →  major_outage

Dazu kommen:

Anti-Flap-Bestätigung: Ein neuer Status muss über einen konfigurierbaren Zeitraum stabil bleiben, bevor er übernommen wird. Damit werden kurze Ausreißer ignoriert.
Staleness-Erkennung: Kommt innerhalb eines definierten Zeitfensters kein Update, wird der Service automatisch auf unknown gesetzt.

Admin-Oberfläche

Das Admin-Dashboard mit Statusübersicht aller Dienste

Das Admin-Backend bietet eine vollständige Verwaltung:

Sektionen & Dienste — anlegen, bearbeiten, sortieren
Incidents — mehrstufiger Lebenszyklus: Investigating → Identified → Monitoring → Resolved
Geplante Wartungsarbeiten — mit optionalem Auto-Status: der Dienst wird zur Startzeit automatisch auf under_maintenance gesetzt und nach Ende wieder auf operational zurückgestellt

Geplante Wartungsarbeiten — Verwaltung geplanter Wartungsarbeiten mit Auto-Status-Option

Monitore — HTTP/TCP/ICMP/DNS-Checks konfigurieren, Schwellenwerte definieren, sofortiger Test per „Run now“

Monitor-Konfiguration — Monitor-Verwaltung mit Echtzeit-Ergebnissen

API-Tokens — Tokens erstellen und auf bestimmte Dienste einschränken
Benutzerverwaltung — Admin- und Viewer-Rollen

API-Integration

Status-Updates lassen sich über einen Bearer-Token aus CI/CD-Pipelines, Deployment-Skripten oder beliebigen externen Tools pushen:

curl -X PATCH https://status.example.com/api/v1/services/mein-dienst/status \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{"status": "operational", "note": "Deployment abgeschlossen"}'

Damit lässt sich MOSSBoard nahtlos in bestehende Automatisierungen integrieren — z. B. eine Deployment-Pipeline, die den Dienst vor dem Rollout auf under_maintenance setzt und danach auf operational zurückstellt.

Tech-Stack

MOSSBoard setzt auf bewährte, wartungsarme Technologien:

Schicht	Technologie
Backend	Python 3.12 · APIFlask · MongoEngine
Datenbank	MongoDB 7
Queue	Redis 7 · Celery · Celery Beat
Frontend	Vue 3 · Vite · Tailwind CSS
Icons	Lucide Vue Next
Schrift	JetBrains Mono (self-hosted)
Proxy	nginx (im Frontend-Container)

Das gesamte System läuft als Docker Compose Stack — kein Kubernetes, keine externe Cloud, keine Abhängigkeiten. MongoDB und Redis laufen als Container mit dabei.

Schnellstart

git clone https://github.com/lanbugs/mossboard.git
cd mossboard
cp .env.example .env
# SECRET_KEY und ADMIN_PASSWORD in .env setzen
docker compose up -d

Danach ist MOSSBoard unter http://localhost:3444 erreichbar. Die vollständige Installationsanleitung steht im README auf GitHub.

Warum GPL v3?

MOSSBoard ist unter der GNU General Public License v3 veröffentlicht. Das bedeutet: Jeder darf den Code lesen, verwenden, verändern und weitergeben — solange Ableitungen ebenfalls offen bleiben. Damit soll sichergestellt werden, dass Verbesserungen der Community zugutekommen.

Ausblick

MOSSBoard ist ein persönliches Projekt, das ich für meine eigene Infrastruktur entwickelt habe und jetzt der Community zur Verfügung stelle. Feature-Requests, Bug-Reports und Pull Requests sind herzlich willkommen.

Wer das Projekt ausprobiert, Feedback hat oder beitragen möchte: Der Code liegt auf GitHub.

→ github.com/lanbugs/mossboard