Wartungsarbeiten ankündigen, Störungen melden. Bevor jemand anruft.
Deine Status-Seite zeigt, was deine Checks sehen, und du ergänzt, was nur du weißt: Vorfälle mit Updates in Phasen, geplante Wartungen mit Erinnerung und ein ehrliches Postmortem danach. So wird aus einem Ausfall eine Nachricht statt hundert Tickets.
Entwickelt und gehostet in der
Europäischen Union
DSGVO-konformes Hosting
in Deutschland
Georedundantes Replikat
in der gesamten EU
Der Status kommt aus deinen Checks.
Jede Zeile auf der Status-Seite ist eine Komponente: ein Monitor, ein Dienst eines Drittanbieters oder ein Eintrag, den du selbst pflegst. Monitore setzen ihren Status selbst, sobald ein Ausfall bestätigt ist, und zeigen ihre Verfügbarkeit als Balken, standardmäßig 30 Tage, bis zu 90. Du sortierst die Komponenten in Gruppen und änderst den Status von Hand mit einem Klick, wenn es nötig ist.
- Automatischer Status aus dem Monitor, damit die Seite einen Ausfall zeigt, ohne dass nachts jemand daran denken muss.
- Drittanbieter als eigene Komponente: Den Status von Diensten wie Cloudflare oder bunny.net bindest du direkt ein, damit dein Kunde sieht, wenn das Problem nicht bei dir liegt.
- Gruppen per Drag-and-drop, damit auch Seiten mit vielen Diensten übersichtlich bleiben.
`sourceKind` ist `monitor`, `dependency` oder `manual`, bis zu 100 Komponenten und 100 Gruppen pro Seite. Monitore liefern ihren Status aus offenen Vorfällen: `operational`, `maintenance`, `degraded` (nur Zertifikatshinweis), `partial_outage` (Seite antwortet, ein anderer Check schlägt fehl) oder `major_outage` (down). Manuelle Komponenten nehmen einen dieser Werte über `manualStatus`, ein verknüpfter offener Vorfall kann ihn anheben.
Drittanbieter kommen aus unserem öffentlichen Dependency-Monitoring, ihr Status `unknown` erscheint als Hinweis, zählt aber nicht in den Gesamtstatus. `overallStatus` ist der schwerste Status aller Komponenten, `major_outage` nur, wenn alles down ist. Rohdaten der Checks verlassen die Plattform nie.
Ein Vorfall, vier Phasen, kein Rätselraten.
Wenn etwas brennt, schreibt niemand gern einen Text von Grund auf. Du meldest den Vorfall mit Titel, betroffenen Komponenten, Status und Schweregrad, nimmst bei Bedarf eine Vorlage und ergänzt ihn mit Updates: Untersuchung, identifiziert, Beobachtung, behoben. Jedes Update steht sofort auf der Seite und geht an die Abonnenten.
- Vorfall in einem Formular, ohne Ausklapp-Bereiche, damit die erste Meldung in einer Minute draußen ist.
- Vorlagen für Vorfälle und Updates, damit Ton und Inhalt auch nachts um drei stimmen.
- Postmortem unter dem Vorfall, damit dein Kunde nach der Lösung nachlesen kann, was passiert ist und was sich ändert.
Ein manueller Vorfall hat einen Titel bis 200 Zeichen, eine Zusammenfassung bis 5.000 Zeichen und einen Schweregrad `minor`, `major`, `critical` oder `maintenance`. Daraus folgt die Darstellung: `degraded`, `partial_outage`, `major_outage` oder `maintenance`, überschreibbar per `impact`. Er erscheint auf bis zu 10 Seiten und an bis zu 100 Komponenten. Updates tragen die Phase `investigating`, `identified`, `monitoring` oder `resolved`. Ein identisch wiederholtes Update wird erkannt und nicht doppelt gesendet. Ein neues Update auf einem gelösten Vorfall öffnet ihn wieder.
Vorlagen gibt es als `incident` und `update`, bis zu 200 pro Organisation, mit Text bis 5.000 Zeichen und vorausgewählten Seiten und Komponenten. Das Postmortem ist Markdown bis 50.000 Zeichen und benachrichtigt die Abonnenten nur, wenn du es beim Veröffentlichen ausdrücklich wählst. Per MCP: `create_incident`, `post_incident_update`, `publish_postmortem`.
Wartung angekündigt. Kein Ausfall in den Augen deines Kunden.
Ein Update am Sonntagabend ist kein Vorfall, wenn dein Kunde es vorher weiß. Du planst die Wartung mit Zeitraum, betroffenen Komponenten und Text. Sie beginnt und endet von selbst, die Komponenten stehen in dieser Zeit auf Wartung, und deine Abonnenten bekommen Ankündigung, Erinnerung und Abschluss.
- Start und Ende automatisch, damit niemand um Mitternacht den Status umschalten muss.
- Erinnerung zwischen 5 Minuten und 7 Tagen vorher, damit dein Kunde seine eigenen Leute rechtzeitig vorwarnt.
- Für die ganze Seite oder einzelne Komponenten, damit eine Datenbank-Wartung nicht den ganzen Shop als gestört zeigt.
Der Status wird nie gespeichert, sondern berechnet: `scheduled` vor `scheduledFor`, `in_progress` bis `scheduledUntil`, danach `completed`, `cancelled` mit `cancelledAt`. Ein schlechterer Zustand wie ein Ausfall geht der Wartung vor. Titel bis 200, Beschreibung bis 5.000 Zeichen, 1 bis 10 Seiten, bis zu 100 Komponenten aus jeder Quelle.
`notifyOnSchedule` (Standard an) kündigt an und erneut, wenn sich der Start verschiebt. `reminderMinutesBefore` 5 bis 10.080, `notifyOnStart` (Standard aus), `notifyOnComplete` (Standard an). Ob eine Nachricht rausgeht, entscheidet sich beim Versand, eine verschobene oder abgesagte Wartung schickt also keine veraltete Meldung. Jedes Ereignis steht auch im RSS- und Atom-Feed. Wichtig: Diese Wartung pausiert keine Monitor-Alarme. Dafür gibt es das Wartungsfenster im Monitoring.
Eine Historie, die stimmt. Auch rückwirkend.
Nicht jeder Ausfall läuft über deine Checks. Einen Vorfall, der schon vorbei ist, trägst du mit festem Beginn, festem Ende und Updates zu ihren eigenen Zeitpunkten nach. Er steht in der Historie und in den Uptime-Balken, ohne dass Abonnenten nachträglich eine Meldung bekommen. Regeln legen fest, ob Monitore und Incident Management auf die Seite schreiben.
- Vorfall nachtragen mit eigenen Zeitpunkten, damit die Historie vollständig ist, auch wenn der Ausfall außerhalb des Monitorings bemerkt wurde.
- Historie quartalsweise zurückblättern, damit dein Kunde auch ältere Vorfälle nachvollziehen kann.
- Regeln pro Seite, damit du entscheidest, ob Monitore und Incident Management den Status automatisch setzen.
Ein Nachtrag braucht `started_at` und `resolved_at` in der Vergangenheit und bis zu 50 Updates mit eigenem Zeitpunkt dazwischen. Er erscheint in der Historie und in den Uptime-Balken der betroffenen manuellen Komponenten und benachrichtigt nie Abonnenten. Per MCP: `backfill_incident`.
`historyPage` 1 umfasst den aktuellen und die zwei vorherigen Kalendermonate, jede weitere Seite drei Monate davor, bis zu 200 Vorfälle pro Seite. Die Uptime-Balken zeigen standardmäßig die letzten 30 Tage, einstellbar bis 90. Vorfälle aus dem Incident Management erscheinen nur mit mindestens einem öffentlichen Update. Team, Responder und interne Notizen gibt die öffentliche Seite nie aus, Autoren erscheinen als Vorname und Initial.
Wir überwachen nicht nur. Wir helfen dir beim Verkaufen.
Jedes Uptimeify-Abonnement enthält Zugang zu unserem Success Kit: eine Sammlung erprobter Ressourcen, um dein Monitoring profitabel zu machen.
Service Level Agreement Vorlagen, um professionelle Grenzen mit deinen Kunden zu definieren.
Finde den Sweet Spot für deine Wartungspläne. Berechne Margen basierend auf Prüfintervallen und Supportstunden.
Präsentationen, die nicht-technischen Kunden 24/7-Monitoring erklären. Schließe mehr Wartungsverträge ab.
Nutze automatisierte Berichte, um proaktiv Wert zu kommunizieren, damit Kunden nie fragen, wofür sie bezahlen.
Bereit, Monitoring in ein Profit-Center zu verwandeln?
Sichere dir dein Success Kit und starte noch heute mit der Skalierung.
Häufig gestellte Fragen
Du planst eine Wartung mit Titel, Zeitraum, betroffenen Komponenten und einer kurzen Beschreibung. Beim Speichern geht die Ankündigung an deine Abonnenten, auf Wunsch folgen eine Erinnerung, eine Startmeldung und eine Abschlussmeldung. Während der Wartung stehen die Komponenten auf Wartung statt auf Störung.
Nein. Die Wartung auf der Status-Seite ist Kommunikation an deine Kunden. Damit dein Team währenddessen nicht alarmiert wird, legst du zusätzlich ein Wartungsfenster im Monitoring an. So bleiben beide Entscheidungen bewusst getrennt: was der Kunde sieht und wer geweckt wird.
Nein. Komponenten, die mit einem Monitor verknüpft sind, wechseln ihren Status automatisch, sobald ein Ausfall über mehrere Standorte bestätigt ist, und kehren nach der Erholung zurück. Einen Vorfall von Hand meldest du, wenn du mehr sagen willst als den Status, etwa die Ursache oder die nächste Einschätzung.
Ein öffentlicher Rückblick auf einen gelösten Vorfall: was passiert ist, warum und was ihr ändert. Er erscheint direkt unter dem Vorfall. Ob deine Abonnenten dazu eine Nachricht bekommen, entscheidest du beim Veröffentlichen. Ein offenes Postmortem zeigt deinem Kunden, dass du Ausfälle ernst nimmst.
Die Uptime-Balken zeigen standardmäßig die letzten 30 Tage, einstellbar bis 90. Die Vorfall-Historie lässt sich darüber hinaus in Quartalsschritten zurückblättern, solange die Vorfälle gespeichert sind. Vorfälle, die nicht über dein Monitoring liefen, trägst du nach, damit die Historie vollständig bleibt.
Für den technischen Ansprechpartner
Bereit, Ausfälle zu erklären, bevor jemand fragt?
Verknüpf deine Monitore, leg zwei Vorlagen an und plan die nächste Wartung. Beim nächsten Ausfall schreibst du ein Update statt hundert Antworten.