Changelog

Bei der Registry liest LIVCK Registrierung, Ablaufdatum, Registrar und Sperren deiner Domains. In der Zone der Endung prüft es, ob die Domain eingetragen ist und auf welche Nameserver sie zeigt. Daten zum Inhaber einer Domain liest und speichert LIVCK nicht.

Die Domain hinter einem HTTP-, SSL-, TCP-, DNS- oder ICMP-Check überwachst du im neuen Tab Domain mit dem Häkchen Domain dieses Services überwachen. Das kostet nichts und ist gesetzt, wenn das Ziel ein Domainname ist. Eine Domain ohne Website dahinter legst du als Service vom Typ Domain an. Er zählt wie jeder andere Service. Unter Domains in der Navigation stehen alle Domains deiner Services. Jede hat eine eigene Seite mit Registrierung, Nameservern samt DNS-Anbieter, einer Checkliste zu ihrem Schutz und dem Verlauf. Über die API und MCP geht das ebenso.

Alarme und Hinweise sind noch nicht aktiv. Die Überwachung läuft die nächsten Tage still mit. Danach meldet LIVCK, wenn eine Domain aus der Zone fällt oder gesperrt wird, und gibt Hinweise zu Ablauf, Nameservern, Registrar, Transfersperre und DNSSEC. Wann du von einer Domain hörst, stellst du schon jetzt im Tab Domain unter Meldungen ein. Mehr dazu in der Hilfe.

Fehlt einem Link-Ziel https://, ergänzt der Builder es, sobald du das Feld verlässt. Ein ungültiges Ziel nennt er dann gleich und nicht erst beim Speichern. Felder mit Obergrenze zählen die Zeichen mit. Links und Blöcke sortierst du per Ziehen oder mit den Pfeiltasten. Die Vorschau zeigt die Sprache, in der du gerade schreibst, und folgt dem geöffneten Block.

Strg+S bzw. Cmd+S speichert, Verwerfen nimmt alle Änderungen zurück. Verlässt du die Seite mit ungespeicherten Änderungen, fragt die Konsole vorher nach. Lehnt LIVCK das Speichern ab, springt die Seite zum ersten Fehler. Bei mehreren Sprachen steht ein Text, der für alle Sprachen gilt, jetzt in jedem Sprach-Tab.

Mit mehreren eigenen Links und einem Button lief die Kopfzeile über ihren Rand: Der Name der Seite verschwand, auf kleineren Bildschirmen auch Button und Einstellungen. Jetzt wandert, was keinen Platz hat, ins Menü hinter dem Zahnrad. Eine Kopfzeile, die passt, bleibt, wie sie ist.

Beim Pausieren legst du unter Wie lange? fest, wann der Service von selbst wieder anläuft: für 30 Minuten, 1 Stunde, 3 Stunden, bis morgen oder bis zu einem Zeitpunkt deiner Wahl, höchstens 90 Tage. Bis ich fortsetze gibt es weiterhin. Das geht auch direkt aus der Service-Liste. Bis zum Ende zählt die Konsole die Zeit herunter. Mit Verlängern und Jetzt fortsetzen änderst du eine laufende Pause. Eine Notiz fürs Team ist nur in der Konsole sichtbar und erscheint nie auf einer Statuspage.

Auch einen manuell gesetzten Status kannst du befristen. Danach zeigt die Statuspage wieder den gemessenen Status. Läuft dann noch eine Wartung, steht dort der Wartungsstatus.

Hat dein Tarif zum Ende der Pause keinen Platz, bleibt der Service pausiert. Das siehst du auf dem Dashboard, und Inhaber und Admins deiner Organisation bekommen eine E-Mail. Pause und Status auf Zeit gehen auch über die API und den MCP. Beim Planen einer Wartung gibst du das Ende jetzt wahlweise als Dauer an.

Die Vorfälle sind in die Reiter Offen, Behoben, Intern und Alle geteilt, jeweils mit Anzahl. Du filterst nach Schweregrad, Service, Tag, Statuspage und Zeitraum, danach, ob ein Vorfall automatisch erkannt oder von Hand gemeldet wurde, und suchst im Titel. Die Einträge sind nach Tagen getrennt. Die Filter stehen in der Adresse. So kannst du eine gefilterte Liste als Link weitergeben.

Mit Alle Treffer auswählen behebst oder löschst du alles, was zum Filter passt, auch über mehrere Seiten, bis zu 500 Vorfälle auf einmal. Kommt ein neuer Vorfall dazu, springt die Liste nicht mehr. Ein Hinweis oben zeigt ihn an.

Die Wartungen teilen sich genauso in Anstehend & laufend, Vergangen, Abgebrochen und Alle, mit Filtern für Typ, Service, Tag, Statuspage und Zeitraum.

Stell dir dein Badge zusammen, kopier das Snippet und füg es auf deiner Website ein. Das Badge zeigt den aktuellen Status und führt per Klick zu deiner Statuspage. Kostenlos für jede öffentliche Statuspage.

Badge-Generator öffnen

Auf der Übersicht jeder Statuspage siehst du ihr Badge. Badge anpassen öffnet den Generator.

Ein interner Vorfall steht auf keiner Statuspage, und niemand wird benachrichtigt. Das zeigt jetzt ein Hinweis oben auf dem Vorfall. In der Vorfall-Liste, auf dem Dashboard und auf der Service-Seite trägt er das Badge Intern, und die Liste lässt sich danach filtern.

Beim Anlegen wählst du mit Direkt veröffentlichen, ob ein Vorfall sofort erscheint oder erst intern bleibt. Mit Veröffentlichen bringst du ihn später auf deine Statuspages. Vorher siehst du, wo er erscheint und welche Meldung an wie viele Abonnenten geht. Ob sie überhaupt rausgeht, entscheidest du dabei selbst, auch über die API und den MCP. Auf intern stellen nimmt ihn sofort wieder von allen Statuspages.

Trägst du einen Vorfall erst später als behoben ein, gibst du unter Behoben am an, wann er wirklich vorbei war. Das geht beim Beheben, im Update-Formular und auf der Bearbeiten-Seite. Die Ausfallzeiten der betroffenen Services richten sich danach. Auch KI-Assistenten können den Zeitpunkt über den MCP angeben.

In der Aktivität wählst du jetzt mehrere Personen, Kategorien und Kanäle auf einmal. Die aktiven Filter stehen über der Liste und lassen sich einzeln entfernen. Bis gilt bis zum Ende des Tages in deiner Zeitzone.

Eine Meldung mit dem Status Behoben schließt den Vorfall. Im Update-Formular braucht sie deshalb jetzt das Recht Vorfälle auflösen, wie schon in der API. Notizen zu einem bereits behobenen Vorfall gehen weiter ohne dieses Recht.

Stellst du einen internen Vorfall auf öffentlich, bekommen deine Abonnenten jetzt die neueste Meldung. Bisher ging die erste raus. Bei einem schon behobenen Vorfall war das also noch „Wir untersuchen …“. Veröffentlichst du einen Vorfall erneut, geht eine schon verschickte Meldung nicht mehr ungefragt ein zweites Mal raus.

Besucher sehen deine Statuspage jetzt in der Sprache ihres Browsers. Bietet die Seite diese Sprache nicht an, erscheint sie auf Englisch, wenn vorhanden, sonst in ihrer Standardsprache. Bisher landeten englischsprachige Besucher auf rein deutschen Statuspages teils auf einer englischen Fassung, die es gar nicht gibt.

Über das Model Context Protocol (MCP) arbeitet dein KI-Assistent direkt mit LIVCK. Du schreibst zum Beispiel „Plan heute Nacht von 2 bis 4 Uhr eine Wartung für alle Services mit dem Tag db und kündige sie an“. Der Assistent bereitet die Wartung vor und zeigt dir Text, Zeiten und Empfänger.

Er eröffnet Vorfälle und schreibt die Meldungen dazu, plant Wartungen, legt Services an oder ändert sie und sucht bei einer Störung nach der Ursache. Je nach Rechten und Umfang der Verbindung kommen Statuspages, Rufbereitschaft, SLA, Aktivität und Support-Tickets dazu.

Die Verbindung legst du unter KI & MCP in den Einstellungen deiner Organisation an. Für 30 Clients, darunter Claude Code, Cursor, VS Code, OpenAI Codex, Gemini CLI, OpenCode und Claude Desktop, zeigt dir die Konsole die fertige Konfiguration. Lesen ist auf allen Plänen enthalten, auch im kostenlosen. Schreiben gibt es ab Solo.

KI-Assistent verbinden

Alles, was Kunden erreicht, jemanden weckt, Alarme abschaltet oder etwas löscht, zeigt der Assistent zuerst als Vorschau: Empfänger, Texte je Sprache, Zeiten und was verloren geht. Ausgeführt wird es erst, wenn du bestätigst. Ändert jemand im Team den Text nach deiner Vorschau, führt LIVCK nichts aus und der Assistent muss dich neu fragen.

Für Clients, die von sich aus nicht nachfragen, wählst du Per Klick im Browser freigeben. Die Aktion wartet dann unter Freigaben, bis du sie freigibst.

Jede Verbindung bekommt je Bereich Kein Zugriff, Lesen, Schreiben oder Löschen. Drei Schalter regeln, was nach außen wirkt: Kunden benachrichtigen, Rufbereitschaft wecken und Alarme abschalten oder ändern. Eine Verbindung hat nie mehr Rechte als die Person, die sie erstellt hat. Ihr Token gilt nur für MCP, nicht für die API.

Neue Einträge in der Aktivität zeigen jetzt, wie eine Änderung entstanden ist: im Browser am Desktop oder Smartphone, über die API mit dem Namen des Tokens oder durch einen KI-Assistenten mit dem Logo seines Clients, zum Beispiel „via Claude Code“. Der Filter Kanal zeigt dir auf Wunsch nur die Änderungen von KI-Assistenten.

Jede Seite eines Service hat jetzt denselben Head: Name, Status mit der Angabe, seit wann er besteht, Check-Typ und Ziel. Bearbeiten und Pausieren stehen direkt daneben, Status manuell setzen, Duplizieren und Löschen liegen im Menü ⋯.

Darunter wechselst du über Reiter zwischen Übersicht, Insights, Checks und Artefakte, bei Server-Agents zwischen Übersicht, Analyse und Verlauf. Springst du zu einem anderen Service, bleibst du auf demselben Reiter.

Services öffnen

Über der Liste filterst du nach Status, Typ, Provider und Tags. Mehrere Werte in einem Filter zeigen alle passenden Services, mehrere Filter zusammen nur die, die alle erfüllen.

Unter der Uptime steht eine Uptime-Bar der letzten 30 Tage. So siehst du in der Liste, wann es Störungen gab.

Die Übersicht zeigt die Antwortzeit als vollständiges Diagramm und zwei neue Karten.

Leistung je Standort zeigt je Monitoring-Standort die Uptime und die durchschnittliche Antwortzeit der letzten 7 Tage, der langsamste zuerst. Verbindungen zeigt, wer bei einem Ausfall alarmiert wird, welche Vorfälle offen sind, welche Wartungen anstehen und auf welchen Statuspages der Service erscheint.

Uptime und andere Prozentwerte stehen in der Konsole jetzt mit Komma und Leerzeichen, also „99,55 %“ statt „99.55%“.

Solo enthält jetzt drei Monitoring-Standorte statt zwei. Mit drei Standorten entscheidet eine echte Mehrheit, ob ein Service ausgefallen ist: Zwei von drei müssen den Fehler melden. Meldet nur ein Standort einen Fehler, gilt der Service als beeinträchtigt und nicht als ausgefallen.

Den dritten Standort wählst du in den Einstellungen deiner Organisation oder je Service dazu.

Tarife ansehen

Schlug ein Check fehl, weil eine deiner Bedingungen gegriffen hat, stand unter Insights bei Fehlerursachen bisher „Keine Fehler“. Diese Checks erscheinen dort jetzt als eigene Ursache.

Im Heartbeat steht neben der Toleranzzeit jetzt Bestätigungen vor Alarm (1 bis 5). Bei 1 alarmieren wir wie bisher sofort beim ersten verpassten Intervall.

Voreingestellt sind 2 bei Intervallen bis fünf Minuten und 1 darüber. Grund: Bestätigungen mal Intervall ergibt die Zeit bis zum Alarm — bei einem täglichen Backup wären zwei Runden zwei Tage.

Zwei Fälle alarmieren weiterhin sofort, unabhängig von der Einstellung: ein Ping an /fail und ein Lauf, der gestartet, aber nie fertig gemeldet hat. Beides meldet dein Skript selbst, da ist nichts verloren gegangen.

Bestehende Heartbeats mit kurzem Intervall haben wir bereits auf 2 gesetzt. Ihre Zeit bis zum Alarm verlängert sich dadurch um ein Intervall — wenn du das nicht willst, stell den Wert auf 1.

Heartbeats öffnen

Bisher reichte ein ausgebliebener Ping, damit ein Heartbeat auf Ausgefallen wechselt und benachrichtigt. Bei einem minütlichen Job hieß das: eine einzelne Anfrage, die unterwegs verloren geht, wird zu einem Vorfall — obwohl dein Job sauber gelaufen ist.

Jetzt zählen wir. Erst wenn mehrere Intervalle hintereinander fehlen, gilt der Dienst als ausgefallen. Jeder eingehende Ping setzt den Zähler zurück: ein Aussetzer am Vormittag und einer am Nachmittag addieren sich nicht.

Die Erholung bleibt sofort — der erste Ping, der wieder ankommt, setzt den Dienst zurück auf Aktiv.

Mit GET, POST und DELETE /v1/enrollment-keys verwaltest du Keys. Den Key selbst siehst du nur in der Antwort beim Anlegen, zusammen mit dem fertigen Installationsbefehl. Jeder Key nennt die Server-Agents, die sich mit ihm angemeldet haben.

Jeder Server-Agent hat in der API den Block agent mit Zustand, Host-Daten, Update-Einstellungen und dem Key der Anmeldung. GET /v1/services/{id}/agent-metrics liefert die aktuellen Werte, /agent-metrics/history den Verlauf.

Enrollment-Tokens tragen jetzt echte Tags deiner Organisation. Mit Server darf eigene Tags setzen legst du fest, ob Tags aus dem Installationsbefehl dazukommen. Ein Tag des Tokens darf auch eine Statuspage-Gruppe füllen.

Enrollment-Tokens öffnen

Teilst du eine Einladung in Slack, Teams oder WhatsApp, zeigt die Vorschau den Namen der Organisation und wer einlädt.

Sind Messdaten kurz nicht abrufbar, antworten /checks und die Messwerte der Server-Agents mit leeren Werten statt mit einem Fehler.

Jeder Webhook trägt jetzt die Header webhook-id, webhook-timestamp und webhook-signature. X-Signature-256 bleibt erhalten.

Das Secret erzeugt jetzt LIVCK und zeigt es dir einmal an. Webhooks ohne Secret bekommen automatisch eins. Erneuerst du es, signiert das alte noch 24 Stunden in webhook-signature mit. X-Signature-256 wechselt sofort.

Integrationen öffnen

Jede Zustellung zeigt ihre Ereignis-ID und bei einem Fehler den Grund, etwa Timeout oder DNS. Wiederholungen tragen dieselbe ID, so erkennst du doppelte Zustellungen. Auch an Webhooks deiner Abonnenten versuchen wir es bei einem Fehler erneut.

Ein Webhook gilt nur noch als zugestellt, wenn dein Endpunkt mit 2xx antwortet. Bisher zählte auch eine Weiterleitung, obwohl dein Endpunkt nichts bekam. Weiterleitungen folgen wir nicht mehr. Leitet dein Endpunkt um, trag die Zieladresse direkt ein.

Testen schickt jetzt einen signierten Beispiel-Alarm im echten Format. Bisher kam eine unsignierte Nachricht, die Empfänger mit Signaturprüfung abgelehnt haben.

In der Service-Übersicht steht vor jedem Ziel das Logo des Providers, zum Beispiel Hetzner, Cloudflare oder STACKIT. Bei Server-Agents steht es neben jeder IP-Adresse. Der Tooltip zeigt Name, Land, Adressen und ob ein CDN davor sitzt.

Neue und geänderte Services erkennen wir nach wenigen Sekunden.

Services öffnen