Changelog

Ü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.

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.

Deine Statuspage folgt jetzt der Einstellung im Gerät der Besucher. Ist ein Handy oder Rechner auf dunkel gestellt, erscheint auch die Statuspage dunkel. Wechselt das Gerät die Einstellung, wechselt die offene Seite mit. Das gilt ab sofort für alle Statuspages, einrichten musst du nichts.

Über das Zahnrad auf der Statuspage wählen Besucher selbst Hell, Dunkel oder System. Der Browser merkt sich die Wahl. Mit System folgt die Seite wieder dem Gerät.

Im Tab Branding stellst du je Statuspage System, Hell oder Dunkel ein. Ist Besucher dürfen umschalten aus, sehen alle genau diese Darstellung und der Schalter auf der Statuspage entfällt.

Statuspages öffnen

Statuspages haben in der API die neuen Felder appearance (system, light oder dark) und allow_appearance_switch. Beide setzt du mit PATCH /v1/statuspages/{id}.

Deine Primärfarbe greift jetzt auf der Statuspage und bleibt im hellen wie im dunklen Modus lesbar. Reicht der Kontrast zum Hintergrund nicht, passen wir ihre Helligkeit an.

Jede Statuspage hat jetzt ein eigenes Vorschaubild. Es zeigt Name, Logo und Primärfarbe deiner Seite. Unten steht die Adresse aus dem geteilten Link, dahinter der aktuelle Status. Teilt jemand einen Link auf deine eigene Domain, zeigt auch das Bild diese Domain. Läuft alles, leuchtet das Bild in deiner Primärfarbe, sonst in der Farbe des Status.

Jeder Vorfall und jede Wartung bekommt ein eigenes Bild mit Titel, Zeitpunkt und betroffenen Komponenten. Einrichten musst du dafür nichts.

Im Free-Plan trägt das Bild unten rechts klein das Logo von LIVCK, so wie der Footer deiner Statuspage.

Im Tab SEO in den Einstellungen deiner Statuspage legst du fest, was Suchmaschinen und Linkvorschauen zeigen:

• Titel, Beschreibung und Untertitel im Bild, je Sprache deiner Statuspage
• Hintergrund im Bild: automatisch, hell oder dunkel
• ob Vorschauen den aktuellen Status zeigen
• ob Vorfälle und Wartungen eigene Bilder bekommen
• ob Suchmaschinen die Seite aufnehmen dürfen

Im Tab siehst du das Bild so, wie es beim Teilen erscheint. Plattformen speichern Vorschauen oft stundenlang, Messenger in alten Nachrichten sogar dauerhaft. Soll ein geteilter Link nie einen veralteten Status zeigen, schalte den Status in Vorschauen ab.

Statuspages haben in der API jetzt das Feld seo mit denselben Einstellungen wie der Tab. Mit PATCH /v1/statuspages/{id} ersetzt seo alle Einstellungen auf einmal. Was du darin weglässt, fällt auf den Standard zurück, und "seo": {} setzt alles zurück. Lässt du seo ganz weg, bleibt alles, wie es ist.

In den Einstellungen deiner Organisation wählst du jetzt eine Zeitzone. In ihr nennen die Vorschaubilder von Vorfällen und Wartungen Beginn und Ende. Voreingestellt ist Europe/Berlin.

Statuspages mit Passwort oder E-Mail-Whitelist erscheinen nicht mehr in Suchmaschinen. Ihre Vorschaubilder zeigen nur Name, Logo und Adresse, nie einen Status. Auch die Links, mit denen Abonnenten ihr Abo bestätigen oder verwalten, nehmen Suchmaschinen nicht mehr auf.

Die Zeitzonen-Auswahl gruppiert die Zonen jetzt nach Kontinenten, mit Europa ganz oben und den Städten alphabetisch. Das gilt überall, wo du eine Zeitzone wählst: in der Organisation, bei Heartbeats und bei SLA-Zielen.

Beim Speichern einer Statuspage sprang die Logo-Größe auf Mittel zurück. Jetzt bleibt sie, wie du sie eingestellt hast. Außerdem lud das Formular ein neu gewähltes Logo bei jedem weiteren Speichern noch einmal hoch. Auch das ist behoben.

Löscht ein Token einen Service mit delete_orphaned_incidents oder delete_orphaned_maintenances, braucht er jetzt zusätzlich Vorfälle löschen bzw. Wartungen löschen, sonst antwortet die API mit 403. Ein Token, dessen Ersteller auf Zugriffsbereiche beschränkt ist, verknüpft Vorfälle und Wartungen nur noch mit Services und Statuspages aus diesen Bereichen. Nutzt dein Skript einen der beiden Parameter, gib seinem Token die passende Berechtigung.

Mit livck/cloud-php steuerst du LIVCK Cloud aus PHP, ohne JSON von Hand zu bauen. Services entstehen über einen typisierten Builder, jeder Fehler kommt als eigene Exception, und Listen blättert der Client selbst durch. Bricht eine Verbindung ab, wiederholt er die Anfrage mit demselben Idempotency-Key, und nichts wird doppelt angelegt. livck/cloud-laravel ergänzt Konfiguration, Facade, mehrere Verbindungen und einen Fake für Tests. Beide Pakete stehen unter der MIT-Lizenz.

• composer require livck/cloud-php
• composer require livck/cloud-laravel

Anleitungen: PHP-SDK und Laravel

Im Feld tags eines Services stehen jetzt Namen oder IDs, auch gemischt: tags: ["kunde:4711", "env=prod"]. Einen neuen Namen legt die API gleich mit an. Nur ein Eintrag, der wie eine Tag-ID aussieht (21 Zeichen mit mindestens einem Großbuchstaben), muss ein bestehender Tag sein.

GET /v1/statuspages?slug=kunde-4711 liefert genau diese Seite oder eine leere Liste. Jede Statuspage nennt jetzt in url ihre öffentliche Adresse, und jede Komponente in effective_status den Status, den Besucher sehen.

Stößt ein Service oder eine eigene Domain an ein Limit deines Plans, nennt die Antwort mit 403 jetzt in upsell das betroffene Limit, dazu limit und usage. So unterscheidet ein Skript ein volles Kontingent von fehlenden Rechten.

Fehlermeldungen der API sind jetzt immer englisch, auch bei Organisationen mit deutschen Inhalten. Accept-Language bestimmt nur noch die Sprache der Inhalte, etwa der Titel von Vorfällen.

GET /v1/services?tag= mit leerem Wert liefert jetzt eine leere Liste statt aller Services. Ein Skript, dessen Variable leer geblieben ist, bekommt so nie versehentlich alle Services.

statuspage_id war bei eigenen Domains leer, jetzt nennt es die Statuspage der Domain.

Eine Statuspage mit email_whitelist: null zu bearbeiten, endete mit 500. Jetzt gilt null als leere Liste.

Auf eine zu große Anfrage kam eine HTML-Seite zurück. Jetzt antwortet die API mit 413 und einer Fehlermeldung als JSON.

Auf roadmap.livck.cloud siehst du, woran wir gerade arbeiten, was als Nächstes kommt und was fertig ist. Mit deinem LIVCK-Konto kannst du dort:

• für Themen abstimmen
• Themen folgen
• mitdiskutieren
• eigene Ideen einreichen

Eine Einreichung sehen zunächst nur du, deine Organisation und wir. Erscheint sie auf dem Board, dann in unserer Fassung und ohne deinen Namen.

Unser Discord-Bot bringt deine Statuspage in einen Discord-Channel. Bisher ging das nur mit Self-Hosted, seit dem 22. September auch mit Statuspages aus LIVCK Cloud. So richtest du ihn ein:

1. Lade den Bot auf deinen Discord-Server ein.
2. Führe im gewünschten Channel /livck subscribe aus und füge die Adresse deiner Statuspage ein. Ob Cloud oder Self-Hosted, erkennt der Bot selbst.

Vorfälle und Wartungen erscheinen danach als eigene Threads.

Drei neue Endpunkte liefern alles rund um einen Service:

• GET /v1/services/{id}/incidents: seine Vorfälle
• GET /v1/services/{id}/maintenances: seine Wartungen
• GET /v1/services/{id}/checks: seine Prüfergebnisse mit Standort, Status, HTTP-Code, Fehler und Zeiten

So siehst du auch über die API, warum ein Service nicht erreichbar war. Außerdem lassen sich /v1/incidents und /v1/maintenances mit service_ids auf mehrere Services eingrenzen.

Schreibende Anfragen (POST) nehmen einen optionalen Header Idempotency-Key an. Kam die Antwort auf eine erfolgreiche Anfrage nicht an, etwa wegen eines Timeouts, wiederholst du sie einfach mit demselben Schlüssel. Du bekommst dann die ursprüngliche Antwort zurück, und nichts wird doppelt angelegt. Ausgenommen ist nur das Hochladen von Logos und Favicons.

• GET /v1/tags filtert jetzt nach label und key.
• POST /v1/tags/ensure legt einen Tag an oder liefert den bestehenden zurück.

So musst du keine Liste mehr durchblättern, um einen Tag zu finden.

Scheitert beim Anlegen eines Services über die API ein Teil, etwa das Setzen der Tags, bleibt kein halb angelegter Service mehr zurück. Ein zweiter Versuch legt so kein Duplikat an.

Anlegen, ändern und löschen — für die Seite selbst und für jede Komponente, dazu Darstellung, Zugriffsschutz sowie Logo und Favicon.

Eine Statuspage muss damit nicht mehr in jeder Umgebung von Hand nachgebaut werden.

Tags anlegen, Services zuweisen, Statuspage-Gruppen aus einem Tag befüllen. Neue Services landen dann selbst in der richtigen Gruppe.

Hinterlegen und verifizieren, ohne die Konsole zu öffnen.

Auch die Diagramme einer Statuspage lassen sich über die API festlegen.

Übersetzte Felder kommen zusätzlich mit allen Sprachen zurück. Beim Schreiben geht dadurch keine Sprache verloren, die gerade nicht abgefragt war.

Was die Konsole ablehnt, lehnt die API genauso ab.