Statusseite erstellen ohne Code: Aufbau, Texte und Kosten

Statusseite erstellen ohne Code

Eine Statusseite entsteht bei Zugo aus einer Beschreibung: Liste der Komponenten, aktueller Zustand, laufende Störung, Historie und geplante Wartung. Der Aufbau kostet 6 Credits, jede spätere Änderung 3. Veröffentlicht wird auf eine Adresse wie status-ihrname.zugo.run, getrennt von Ihren eigenen Servern, oder unter Ihrer eigenen Domain.

Der Text klärt der Reihe nach: wofür eine Statusseite im Alltag wirklich sorgt, was daraufgehört, wie eine Störungsmeldung formuliert wird, woher die Daten kommen und an welcher Stelle ein Überwachungsdienst nötig wird, den ein Builder nicht ersetzt.

Wofür ist eine Statusseite überhaupt da?

Nicht für Transparenz im Allgemeinen, sondern für einen sehr konkreten Zweck: Sie soll die Frage „liegt es an euch oder an mir“ beantworten, bevor jemand zum Telefon greift. Jede Minute Störung erzeugt sonst Support-Anfragen, die alle dasselbe fragen und alle einzeln beantwortet werden.

Der zweite Zweck ist die Entlastung im Nachgang. Eine Seite mit Verlauf und kurzer Ursachenbeschreibung ersetzt zehn Einzelmails an Kunden, die wissen wollen, was passiert ist. Der dritte Zweck betrifft den Vertrieb: Größere Kunden fragen im Auswahlprozess danach, und eine gepflegte Historie wirkt dort besser als jede Zusage im Angebot.

Was eine Statusseite nicht leistet: Sie verhindert keinen Ausfall und ersetzt keine Überwachung. Sie ist die Anzeige, nicht das Messgerät. Wer das verwechselt, baut eine schöne Seite, die bei der nächsten Störung als Letztes bemerkt wird.

Was gehört auf eine Statusseite, und was nicht?

Der häufigste Fehler ist zu viel Technik. Die Seite wird von Anwendern gelesen, nicht von Ihrem Betriebsteam, und die Komponenten müssen deshalb den Namen tragen, den der Kunde benutzt.

Für die Zustände genügen vier Stufen: läuft, eingeschränkt, gestört, Wartung. Mehr Stufen führen dazu, dass niemand mehr weiß, was der Unterschied zwischen „teilweise beeinträchtigt“ und „eingeschränkt verfügbar“ sein soll, und zwei Kollegen sie unterschiedlich vergeben.

Wie sieht der Prompt für eine Statusseite aus?

Beschreiben Sie Ihr Produkt aus Kundensicht und nennen Sie die Komponenten so, wie sie im Menü Ihrer Anwendung heißen. Alles Weitere leitet der Builder ab.

Erstelle eine Statusseite für einen Dienst zur Rechnungsstellung.
Oben ein großer Kasten mit dem Gesamtzustand in einem Satz.
Darunter fünf Komponenten: Anmeldung, Weboberfläche, Rechnungsversand,
Zahlungseingang, Schnittstelle für Partner.
Je Komponente ein Zustand: läuft, eingeschränkt, gestört, Wartung.
Bereich für die laufende Störung mit Zeitstempel und Verlauf der Meldungen.
Darunter Historie der letzten dreißig Tage, nach Datum gruppiert.
Eigener Abschnitt für angekündigte Wartungsfenster.
Sehr schlicht, sehr schnell ladend, gut lesbar auf dem Telefon,
keine Animationen, kein großes Bildmaterial.

Der Hinweis auf schlichte Gestaltung ist kein Geschmack, sondern Funktion. Eine Statusseite wird in dem Moment aufgerufen, in dem etwas nicht geht, oft über eine schlechte Verbindung. Alles, was das Laden verzögert, arbeitet gegen den Zweck der Seite.

Wie schreibe ich eine Störungsmeldung, die Anrufe verhindert?

Eine gute Meldung beantwortet drei Fragen in dieser Reihenfolge: Was merkt der Kunde, was tun wir, wann melden wir uns wieder. Der letzte Punkt fehlt fast immer und ist der wichtigste, denn er ersetzt das Nachfragen.

Vermeiden Sie Zeitangaben, die Sie nicht halten können. Eine verschobene Zusage kostet mehr Vertrauen als eine ehrliche Aussage, dass die Ursache noch unklar ist. Und schreiben Sie in der Sprache Ihrer Kunden: „Rechnungen werden nicht versendet“ statt „Warteschlange des Mailversands blockiert“.

Woher kommen die Statusdaten?

Hier ist Ehrlichkeit wichtiger als Verkaufsfreude: Zugo baut die Seite, aber es überwacht Ihre Systeme nicht. Es gibt keine eingebaute Prüfung, die alle paar Minuten Ihre Anwendung anruft und den Zustand selbständig umstellt. Diese Rolle übernimmt entweder ein Mensch oder ein Überwachungsdienst, den Sie ohnehin einsetzen.

Daraus ergeben sich zwei brauchbare Wege. Der einfache: Sie ändern den Zustand von Hand, wenn etwas passiert. Das kostet je Änderung 3 Credits und passt für kleine Teams, die ohnehin bemerken, wenn der Dienst steht.

Der stabilere Weg führt über Supabase. Die Zustände und Meldungen liegen dann in einer Datenbank, die Seite liest sie aus, und Sie pflegen sie über eine geschützte Eingabemaske. Wer bereits eine Überwachung betreibt, kann deren Ergebnis in dieselbe Tabelle schreiben lassen. Wie die Anbindung abläuft, steht in KI-App-Builder mit Supabase.

Wie benachrichtige ich Kunden per Mail?

Eine Statusseite, die niemand aufruft, hilft nur denen, die ohnehin suchen. Der Mailversand über Resend schließt diese Lücke: Interessierte tragen ihre Adresse ein und bekommen bei Störung und Entwarnung eine kurze Nachricht.

Drei Regeln sparen späteren Ärger. Erstens die Bestätigung der Eintragung, sonst tragen Dritte fremde Adressen ein. Zweitens ein Abmeldelink in jeder Mail. Drittens keine Nachricht bei jeder Kleinigkeit, denn eine Liste, die zu oft schreibt, wird zuerst ignoriert und dann abbestellt.

Der Versand selbst ist eine Änderung am Projekt, keine Sonderleistung. Wie die Anbindung im Einzelnen aussieht, beschreibt KI-App-Builder mit Resend.

Was kostet eine Statusseite in Credits?

Bezahlt wird pro Aktion. Für eine Seite dieser Größe bleibt die Rechnung klein, und der laufende Betrieb ist der Teil, den man vorher überschlagen sollte.

Free gibt 5 Credits, Pro kostet 25 $ im Monat mit 200 Credits, Business 99 $ im Monat mit 800 Credits. Zweihundert Credits entsprechen etwa 16 mehrseitigen Plattformen oder 33 Aufbauten oder 66 Änderungen im Monat.

Wer den Zustand von Hand pflegt, sollte rechnen: Jede Statusänderung ist eine Änderung. Bei einem Dienst mit mehreren Vorfällen im Monat summiert sich das, und ab diesem Punkt lohnt die Datenbankvariante, bei der die Pflege nichts mehr kostet, weil sie im Projekt selbst passiert.

Muss die Statusseite getrennt vom Produkt laufen?

Ja, und das ist der einzige technische Punkt, an dem eine Statusseite scheitern kann. Läuft sie auf denselben Servern wie Ihre Anwendung, ist sie bei genau der Störung nicht erreichbar, für die sie gebaut wurde. Der Satz klingt selbstverständlich und wird trotzdem regelmäßig übersehen.

Ein bei Zugo veröffentlichtes Projekt liegt auf einer Adresse der Form status-ihrname.zugo.run und damit außerhalb Ihrer eigenen Umgebung. Wenn Sie eine eigene Domain verwenden, wählen Sie einen Namen unter einer anderen Domain als das Produkt, damit ein Ausfall Ihrer Hauptdomain die Statusseite nicht mitnimmt.

Wichtig bleibt die Einordnung: Diese Trennung senkt ein bekanntes Risiko, sie ist keine Zusicherung von Verfügbarkeit. Wer vertraglich harte Zusagen macht, prüft die Verfügbarkeit seiner Kette selbst.

Wo hört ein Builder auf und fängt ein Überwachungsdienst an?

Drei Grenzen gehören auf den Tisch, bevor Sie anfangen. Es gibt keine automatische Prüfung Ihrer Systeme. Wer eine Seite will, die sich ohne menschliches Zutun auf „gestört“ stellt, braucht dafür einen Überwachungsdienst, der diese Information liefert.

Es gibt auch keine Verfügbarkeitsstatistik, die sich selbst berechnet. Eine Angabe über die Verfügbarkeit eines Monats setzt Messwerte voraus, und Messwerte entstehen nur dort, wo gemessen wird.

Und für sehr spezifische Abläufe gilt wie überall: Sie entstehen über mehrere Änderungen und nicht mit einem einzigen Prompt. Bei einem komplexen Produkt ersetzt ein Builder kein Entwicklungsteam. Er nimmt Ihnen die Seite ab, nicht den Betrieb.

Wie führe ich die Statusseite im Alltag?

Legen Sie vorher fest, wer melden darf und ab wann gemeldet wird. Ohne diese Absprache passiert regelmäßig beides: erst schweigt die Seite bei einer echten Störung, dann meldet jemand vorsichtshalber jede Kleinigkeit.

Eine brauchbare Regel lautet: gemeldet wird, was Kunden merken. Ein ausgefallener Hintergrundprozess ohne sichtbare Folgen gehört ins interne Protokoll, nicht auf die Statusseite. Ein verzögerter Rechnungsversand gehört dorthin, auch wenn technisch alles läuft.

Nach jedem Vorfall lohnt ein kurzer Nachtrag, was die Ursache war und was sich ändert. Wer solche Nachträge sammelt, kann sie mit den Produktneuerungen zusammenführen, wie es Changelog-Seite erstellen ohne Code beschreibt. Den ersten Entwurf Ihrer Statusseite stoßen Sie mit der Liste Ihrer Komponenten auf zugo.dev an, eine einfache Seite dieser Art steht in etwa einer Minute.