uptimelens/claude-plugins

UptimeLens-Überwachung

Richten Sie UptimeLens-Uptime-Überwachung auf den eigenen Ressourcen des Kunden über den UptimeLens MCP-Server ein und betreiben Sie sie. Diese Skill übersetzt eine Überwachungsanfrage („überwache diese URL“, „was sollte ich nach diesem Deployment beobachten?“, „was ist ausgefallen?“, „eröffne einen Incident“) in die korrekte Abfolge von MCP-Tool-Aufrufen.

Wann diese Skill verwendet werden soll

Verwenden Sie sie für den Überwachungs-Einrichtungs- und Incident-Buchhaltungsteil des Produkts:

• Erstellen von HTTP/HTTPS-Monitoren und Empfehlen der Abdeckung nach einem Deployment oder für einen neuen Service.
• Prüfen, was gerade ausgefallen ist, und Durchführen einer leichten Untersuchung (Statusverlauf, Ursachenanalyse pro Probe, Antwortzeit/Verfügbarkeit).
• Planen eines Wartungsfensters, damit ein Deployment oder geplante Arbeiten niemanden alarmieren.
• Modellieren von Monitor-Abhängigkeiten, sodass ein nachgelagerter Check nicht alarmiert, wenn sein vorgelagerter bereits ausgefallen ist.
• Öffnen, Aktualisieren oder Schließen von Incidents.

Übergeben Sie die Verantwortung, wenn es um das Reagieren auf eine Alarmierung geht und nicht um die Überwachung: für das Bestätigen oder Stummschalten einer aktiven Eskalation, das Übernehmen einer Schicht oder das Untersuchen von Eskalationsläufen verwenden Sie die uptimelens-on-call-Skill. Für eine tiefgehende, geführte Ursachenanalyse eines Incidents bevorzugen Sie den schreibgeschützten triage_incident-MCP-Prompt (und das get_root_cause-Tool) anstatt die gesamte Analyse hier zu skripten.

Voraussetzungen

1. Der UptimeLens MCP-Server ist mit diesem Client verbunden. Lesewerkzeuge funktionieren mit jedem Plan.
2. Schreibaktionen (create_monitor, update_monitor, pause_monitor, resume_monitor, register_monitor_dependency, delete_monitor_dependency, create_incident, post_incident_update, resolve_incident, cancel_incident, reopen_incident, save_postmortem, add_incident_action_item, create_maintenance, delete_maintenance) erfordern einen **Lese-/Schreib-**API-Token und einen Pro-Plan oder höher. Mit einem schreibgeschützten Token werden die Schreibwerkzeuge nicht einmal aufgelistet; beim Free-Plan geben sie FeatureNotAvailable zurück.
3. Einige Lesewerkzeuge sind planabhängig. get_root_cause (kostenpflichtig) und get_incident_analytics (Pro+) sind hart begrenzt – unterhalb des Plans geben sie einen FeatureNotAvailable-Fehler zurück; behandeln Sie dies wie die Schreibwerkzeug-Voraussetzungen unten (teilen Sie dem Benutzer mit, dass der Plan nicht erfüllt ist, und wiederholen Sie den Vorgang nicht). query_metrics-Perzentile sind weich begrenzt – die Perzentilfelder kommen unterhalb des Team-Plans als null zurück, nicht als Fehler.

Wenn ein Schreibwerkzeug fehlt oder FeatureNotAvailable zurückgibt, teilen Sie dem Benutzer mit, welche Voraussetzung nicht erfüllt ist, anstatt es erneut zu versuchen.

Werkzeuge

Diese Werkzeuge stammen vom UptimeLens MCP-Server. Verweisen Sie voll qualifiziert als UptimeLens:<tool> darauf – ersetzen Sie UptimeLens durch den Namen, den der Connector in diesem Client erhalten hat, da das Werkzeug sonst möglicherweise nicht gefunden wird.

Lesen (Erkundung und Kontext):

• UptimeLens:get_overview – beginnen Sie hier für „Was ist gerade kaputt?“: Monitoranzahlen nach Status, 24-Stunden-Uptime, offene Incidents und die zusammengefassten unterschiedlichen Fehler – vierzig Monitore, die auf die gleiche Weise am gleichen Ziel ausgefallen sind, werden als EIN Ausfall statt vierzig Zeilen zurückgegeben. Verwenden Sie stattdessen list_monitors, wenn Sie das Inventar selbst benötigen (Namen, Tags, IDs).
• UptimeLens:list_monitors – Monitore mit aktuellem Zustand; filtern Sie nach status (up/degraded/down/unconfirmed-down/unknown/not-monitored/in-maintenance), Name oder Tags. Die Quelle von monitorId für fast alles andere und die Antwort auf „Was ist ausgefallen?“.
• UptimeLens:get_monitor – Konfiguration und aktueller Zustand eines Monitors (keine Anmeldeinformationen).
• UptimeLens:list_status_changes – Up/Down/Degraded-Verlauf eines Monitors mit Dauern; die Quelle der statusChangeId, die get_root_cause benötigt.
• UptimeLens:get_status_change – eine Statusänderung mit ihrem Kontext (vorherige und nächste Änderung, der sie abdeckende Incident und Eskalationsläufe) und einer Zusammenfassung pro Standort der Checks darum: wie viele fehlgeschlagen sind, firstDownAt und die häufigste errorCategory. Verwenden Sie es, um festzustellen, wo ein Ausfall begann und wie er bestätigt wurde; auf jedem Plan verfügbar.
• UptimeLens:get_root_cause – Netzwerkdiagnose pro Probe für eine Statusänderung: DNS/Connect/TLS-Timing, Traceroute, TLS-Version, verbleibende SSL-Tage, Fehlerkategorie. Die reichhaltigste Quelle für „Warum war es ausgefallen“ (kostenpflichtiger Plan).
• UptimeLens:query_metrics – Antwortzeit- und Uptime-Statistiken für einen Monitor über einen Zeitraum (Zeitraumzusammenfassung, keine vollständige Reihe; Perzentile ab Team+).
• UptimeLens:get_monitor_availability – SLA-Ansicht für einen Monitor: Uptime-%, Ausfallzeit, Incident-Anzahl, MTTR, MTBF, Antwortzeit-Statistiken. Beachten Sie beim Lesen: Ein fehlendes uptimePct bedeutet, dass der Zeitraum KEINE Messungen hatte – es ist NICHT 100, sagen Sie also, dass der Monitor nicht gemessen wurde; longestIncidentSec ist die Echtzeit eines Incidents und KANN die gemessene totalDowntimeSec überschreiten – das ist erwartet, kein Datenfehler; uptimePct wird auf zwei Dezimalstellen gerundet, sodass ein sehr kurzer Ausfall 100.00 neben einer positiven Ausfallzeit anzeigen kann; ein fehlendes mtbfSec/mttrSec ist NICHT null.
• UptimeLens:get_uptime_report – die gleiche Frage für das gesamte Konto über einen Zeitraum: zeitgewichtete Uptime, Ausfallzeit, Fehlerbudget gegenüber einem SLA-Ziel, plus was ausgefallen ist (causes) und wo es bestätigt wurde (locations). Wählen Sie einen Zeitraum mit einer Voreinstellung (last_month, last_30d, …) oder expliziten Daten. Verwenden Sie dies für „Wie war der letzte Monat?“; get_monitor_availability für einen einzelnen Monitor.
• UptimeLens:list_monitor_dependencies – die übergeordneten Monitore, von denen ein Monitor abhängt (was verfügbar sein muss, damit seine Alarme ausgelöst werden).
• UptimeLens:list_monitor_dependents – das Gegenteil: Monitore, die von diesem abhängen – sein Blast Radius, um Ursache von Symptom zu unterscheiden.
• UptimeLens:list_incidents – Incidents, neueste zuerst; Standardmäßig die letzten 7 Tage, es sei denn, Sie übergeben startDate/endDate. Filtern Sie nach status, monitorId oder source.
• UptimeLens:get_incident – Details eines Incidents plus seine Update-Zeitleiste und betroffene Monitore.
• UptimeLens:get_incident_analytics – Flottenweite Incident-Metriken über einen Datumsbereich (MTTR, Volumen/Trend, Schweregrad/Quellen-Aufschlüsselung, Top-Monitore) – Pro+.
• UptimeLens:list_maintenance – Wartungsfenster; status=active beantwortet „Ist gerade etwas in Wartung?“.
• UptimeLens:list_status_pages / UptimeLens:get_status_page – Was wird Kunden veröffentlicht und welche Monitore erscheinen auf einer Seite (nützlich bei der Entscheidung über die Abdeckung).

Schreiben (Zustandsänderung – siehe „Vor dem Schreiben bestätigen“):

• UptimeLens:create_monitor – Erstellen eines HTTP/HTTPS-Monitors aus einer URL. Siehe „Was create_monitor kann und nicht kann“.
• UptimeLens:update_monitor – Bearbeiten von Name und/oder Prüfintervall eines vorhandenen Monitors (id + name und/oder intervalSeconds, mindestens eines). Alle anderen Einstellungen (URL, Typ, Authentifizierung, Header, Schwellenwerte, Regionen) bleiben unverändert erhalten und können über MCP nicht geändert werden. Reversibel und idempotent.
• UptimeLens:pause_monitor / UptimeLens:resume_monitor – Stoppen oder Neustarten der aktiven Überwachung für einen Monitor. Eingabe: id. Reversibel und idempotent.
• UptimeLens:register_monitor_dependency – Deklarieren einer Kind→Eltern-Abhängigkeit: Solange der Elternteil ausgefallen ist, werden die Ausfallalarme des Kindes unterdrückt. Eingabe: monitorId (Kind), parentId. Nur direkter Elternteil; Zyklen/Selbstbezüge werden abgelehnt.
• UptimeLens:delete_monitor_dependency – Entfernen einer Abhängigkeitskante anhand ihrer Datensatz-id (von list_monitor_dependencies); löscht keinen Monitor.
• UptimeLens:create_incident – Öffnen eines Incidents. Siehe „Incidents werden als Entwürfe geöffnet“.
• UptimeLens:post_incident_update – Hinzufügen eines Zeitleisten-Updates (untersuchend/identifiziert/überwachend) mit einer Nachricht. Abonnenten erhalten keine E-Mail, es sei denn, Sie übergeben notifySubscribers=true (und nur, wenn der Incident bereits veröffentlicht ist).
• UptimeLens:resolve_incident – Markieren eines Incidents als gelöst. Abonnenten erhalten keine E-Mail, es sei denn, Sie übergeben notifySubscribers=true (und nur, wenn veröffentlicht). Reversibel über reopen_incident.
• UptimeLens:cancel_incident – Abbrechen als false_alarm/duplicate/test; endgültig (kann nicht wieder geöffnet werden), von Analysen ausgeschlossen. Standardmäßig still.
• UptimeLens:reopen_incident – Wiedereröffnen eines zuvor gelösten Incidents (ein abgebrochener Incident kann nicht wieder geöffnet werden).
• UptimeLens:save_postmortem – Schreiben (oder Überschreiben) des Postmortem-Textes eines Incidents als Markdown; optionaler status draft oder in_review. Hierhin gehört die Ausgabe des postmortem_draft-Prompts – ohne dies existiert der Entwurf nur im Chat. Die Veröffentlichung bleibt ein manueller Schritt im Dashboard.
• UptimeLens:add_incident_action_item – Hinzufügen eines Folgeaktionselements zu einem Incident (Titel, plus optionaler Typ, Priorität und Fälligkeitsdatum). Die Hälfte eines Postmortems, die tatsächlich etwas ändert.
• UptimeLens:create_maintenance / UptimeLens:delete_maintenance – Planen oder Abbrechen eines Wartungsfensters, das Alarme für seine Monitore während des Fensters unterdrückt.

Kern-Workflow: Überwachung einrichten (insbesondere nach einem Deployment)

Die Erkundung steht an erster Stelle: Fast jeder Schreibvorgang benötigt eine ID oder eine Entscheidung, die nur das aktuelle Inventar liefern kann. Kopieren Sie diese Checkliste und arbeiten Sie sie ab:

Überwachung einrichten:
- [ ] 1. Aktuelle Abdeckung ansehen (list_monitors) – was vorhanden ist, was fehlt, was bereits ausgefallen ist
- [ ] 2. Für eine neue URL/einen neuen Service: list_monitors auf ein Duplikat prüfen (create_monitor ist NICHT idempotent)
- [ ] 3. URL(s) mit dem Benutzer bestätigen, dann create_monitor (nur HTTP/HTTPS)
- [ ] 4. Topologie verdrahten, falls relevant (register_monitor_dependency: den neuen Check unter seinem vorgelagerten)
- [ ] 5. Wenn ein Deployment/Wartung ansteht, Noise unterdrücken (create_maintenance für das Fenster)

Schritt 1 – Inventar. list_monitors aufrufen. Um zu beantworten, was ausgefallen ist, übergeben Sie status=["down"] (fügen Sie degraded/unconfirmed-down hinzu, wenn der Benutzer „unhealthy“ meint). So erkennen Sie auch Lücken: einen Service, den der Benutzer gerade deployed hat, aber für den kein passender Monitor existiert.

Schritt 2-3 – Erstellen, aber vorsichtig. create_monitor ist nicht idempotent – zweimaliges Aufrufen für dieselbe URL erstellt zwei Monitore. Prüfen Sie zuerst mit list_monitors, ob bereits einer existiert, und bestätigen Sie die genaue URL mit dem Benutzer, bevor Sie erstellen. Beachten Sie die Einschränkungen unten.

Schritt 4 – Topologie (optional). Wenn der neue Monitor von etwas abhängig ist, das Sie bereits überwachen (eine App hinter einem Gateway, ein Service hinter seiner Datenbank), dann rufen Sie register_monitor_dependency auf, mit dem neuen Monitor als monitorId und dem vorgelagerten als parentId, damit das Kind nicht alarmiert, wenn der Vorgelagerte das eigentliche Problem ist.

Schritt 5 – Deployment-Noise unterdrücken (optional). Wenn der Benutzer deployed oder geplante Arbeiten durchführt, rufen Sie create_maintenance für die betroffenen Monitore über das Fenster auf, damit die Arbeit selbst nicht alarmiert.

Was create_monitor kann und nicht kann

create_monitor ist ein Schnellhinzufügen: Geben Sie eine URL an, es erstellt einen HTTP/HTTPS-Monitor (https wird angenommen, wenn kein Schema angegeben ist), der Name standardmäßig der Host, und das Prüfintervall und die Alarmgruppe verwenden die Mandantenvorgaben.

Es kann nicht, über MCP: Nicht-HTTP-Monitore erstellen (TCP/UDP, DNS, ping/ICMP, SSH, SMTP usw.) oder Authentifizierung, benutzerdefinierte Header, Schlüsselwort-/Text-Assertions, ein bestimmtes Intervall oder Alarmgruppen festlegen. Weisen Sie den Benutzer in solchen Fällen an, die Einrichtung im Dashboard abzuschließen – geben Sie nicht vor, dass das MCP sie konfigurieren kann. Nach der Erstellung kann update_monitor den Namen und das Prüfintervall eines Monitors ändern (nur diese beiden – alles andere bleibt im Dashboard). Es gibt kein delete_monitor-Tool: Um einen Monitor zu entfernen, verweisen Sie den Benutzer auf das Dashboard.

Incidents werden als Entwürfe geöffnet

create_incident öffnet immer einen unveröffentlichten Entwurf: Er wird auf keiner Statusseite angezeigt und Abonnenten werden nicht benachrichtigt. Ein Mensch veröffentlicht ihn über das Dashboard. Sagen Sie dies, wenn Sie einen erstellen, damit der Benutzer weiß, dass er noch nicht öffentlich ist. post_incident_update, resolve_incident, cancel_incident und reopen_incident benachrichtigen Abonnenten per E-Mail nur, wenn Sie explizit notifySubscribers=true übergeben – die MCP-Voreinstellung ist still, weil E-Mails an die eigenen Kunden des Kunden nicht zurückgenommen werden können. (Das Dashboard verhält sich gegenteilig: Dort drückt ein Mensch den Knopf.) cancel_incident ist endgültig (false_alarm/duplicate/test) und kann nicht wieder geöffnet werden; resolve_incident ist über reopen_incident reversibel. Verwenden Sie cancel für „das war nicht echt“ und resolve für „das ist vorbei“.

Vor dem Schreiben bestätigen

Lesen und empfehlen Sie frei. Bestätigen Sie vor jedem Schreibvorgang, was Sie tun werden, und holen Sie die Zustimmung des Benutzers ein – diese ändern, was überwacht wird, was alarmiert oder was aufgezeichnet wird:

• Monitor erstellen: Nennen Sie die genaue URL. Da es nicht idempotent ist, bestätigen Sie, dass noch kein Monitor dafür existiert (Sie haben list_monitors geprüft).
• Pausieren/Fortsetzen: Pausieren stoppt die Überwachung, sodass ein echter Ausfall nicht alarmiert, während er pausiert ist – bestätigen Sie, dass der Benutzer ihn stummschalten möchte.
• Wartung: Nennen Sie die Monitore und das genaue Fenster (RFC3339; Standard UTC, oder übergeben Sie eine IANA-Zeitzone wie Europe/Berlin – wiederkehrende Fenster sind DST-bewusst); währenddessen werden Alarme unterdrückt.
• Incident eröffnen/aktualisieren/schließen/abbrechen: Nennen Sie den Incident und, für Schließen/Abbruch, geben Sie an, ob Sie eine Abonnenten-E-Mail anfordern (notifySubscribers=true) – standardmäßig wird keine E-Mail gesendet.

Bevorzugen Sie die am wenigsten überraschende Aktion, empfehlen Sie eher, als in großem Umfang zu erstellen, und eröffnen oder schließen Sie niemals Incidents in großen Mengen ohne Bestätigung pro Incident.

Häufige Szenarien

„Überwache https://api.example.com.“ list_monitors (prüfen, ob es nicht bereits überwacht wird) → URL bestätigen → create_monitor(url). Wenn der Benutzer Authentifizierung, eine Schlüsselwortprüfung oder ein Nicht-HTTP-Protokoll wünscht, erstellen Sie den einfachen HTTP-Monitor und teilen Sie ihm mit, diese Einstellungen im Dashboard abzuschließen.

„Ich habe gerade den Billing-Service deployed – was sollte ich überwachen?“ list_monitors, um die aktuelle Abdeckung zu sehen → identifizieren Sie die Lücken (die neuen öffentlichen Endpunkte/Health Checks ohne Monitor) und empfehlen Sie sie dem Benutzer, anstatt sie stillschweigend zu erstellen → nach Bestätigung create_monitor für jeden → wenn der neue Monitor hinter etwas liegt, das Sie bereits überwachen, register_monitor_dependency, um ihn unter diesen Vorgelagerten zu stellen. Notieren Sie, was nicht automatisch erstellt werden kann (Nicht-HTTP, Authentifizierung, Schlüsselwörter) und übergeben Sie dies an das Dashboard.

„Was ist gerade ausgefallen?“ get_overview zuerst – es beantwortet die Frage mit einer aufgabenorientierten Ansicht („3 verschiedene Ausfälle von 16 inaktiven Monitoren“). Verwenden Sie dann list_monitors mit status=["down"] für die Liste der tatsächlichen Monitornamen und get_monitor oder get_status_change für Details zu einem bestimmten. Wenn der Benutzer fragt, warum ein bestimmter Monitor ausgefallen ist, verwenden Sie get_status_change für dessen aktuellsten Ausfall und get_root_cause für Diagnosen.

„Kannst du für meine geplante Bereitstellung heute Abend ein Wartungsfenster einrichten?“ list_maintenance (prüfen, ob es bereits eins abdeckt – Sie wollen keine doppelten Fenster) → bestätigen Sie die genauen Monitore und die Start-/Endzeit (UTC oder mit IANA-Zeitzone) mit dem Benutzer → create_maintenance. Standardmäßig still.

Ich denke, die_aktuelle_page ist ausgefallen.“ list_monitors nach Name oder Tags → prüfen Sie den status: wenn down, fragen Sie, ob sie einen Incident eröffnen sollen. Wenn Sie den Grund sehen wollen, get_status_change → wenn der Benutzer tiefer graben möchte, get_root_cause.

„Eröffne einen Incident für api.example.com.“ list_monitors, um den Monitor zu finden → (optional) get_monitor für den aktuellen Zustand → create_incident mit den Details (Titel, optional description, monitorId). Erinnern Sie den Benutzer daran, dass es ein Entwurf ist – es wird niemand benachrichtigt, bis ein Mensch es im Dashboard veröffentlicht.

„Aktualisiere den Incident #123 – wir haben die Ursache identifiziert.“ post_incident_update(incidentId, status="identifiziert", message=...). Keine E-Mail, es sei denn, der Benutzer sagt ausdrücklich, dass Abonnenten benachrichtigt werden sollen.

„Schließe Incident #123 – bitte benachrichtige Abonnenten.“ resolve_incident mit notifySubscribers=true. Wenn der Incident nicht echt war (false_alarm, duplicate, test), verwenden Sie cancel_incident.

„Schreibe ein Postmortem für Incident #123.“ Rufen Sie zuerst get_incident auf, um die Details und die Zeitleiste zu erhalten. Verwenden Sie dann die postmortem_draft-Prompt, um einen Entwurf zu generieren. Bestätigen Sie den Entwurf mit dem Benutzer, dann rufen Sie save_postmortem(incidentId, body=entwurf, status="draft") auf. Fügen Sie dann add_incident_action_item für jeden Folgepunkt hinzu, den der Benutzer aus dem Postmortem ableitet.

„Was ist mit der Wartung für diesen Monat?“ list_maintenance (ohne Filter erhalten Sie alle Fenster, die nach dem aktuellen Datum enden – die Zukunft und die laufenden; übergeben Sie includePast=true für den gesamten Verlauf).

Werkzeugverhalten (gutes zu wissen)

• create_monitor ist nicht idempotent: Zwei Aufrufe mit derselben URL erzeugen zwei Monitore. Prüfen Sie immer zuerst das Inventar und bestätigen Sie.
• update_monitor ändert nur name und intervalSeconds; alles andere müssen Sie als Dashboard-Aufgabe deklarieren.
• delete_monitor gibt es nicht: Sie können einen Monitor nicht über MCP entfernen.
• Lessons Learned (Postmortems) werden als privat (Entwurf) gespeichert – die Veröffentlichung ist eine Dashboard-Aufgabe.
• Die meisten Schreibvorgänge sind standardmäßig still – Sie müssen notifySubscribers=true übergeben, um Benachrichtigungen zu senden.

Nach der Verwaltung aufhören (keine Tutorials)

Führen Sie die Aktion aus, dann hören Sie auf. Bieten Sie keine Einführungstour an, schlagen Sie nicht vor, das Dashboard zu besuchen, wenn Sie nicht speziell nach einer Einschränkung gefragt werden, und fahren Sie nicht mit unaufgeforderten Nachfragen wie „Möchten Sie auch…“ fort – es sei denn, der Workflow erfordert es (z. B. nach dem Erstellen eines Monitors einen Check, ob er funktioniert).

Wichtige Haftungsausschlüsse

• Nur HTTP/HTTPS-Monitore: create_monitor unterstützt nur HTTP/HTTPS. Authentifizierung, Schlüsselwort-Assertions, Header, benutzerdefinierte Intervalle und Nicht-HTTP-Protokolle erfordern das Dashboard.
• Keine Benachrichtigungen standardmäßig: resolve, cancel und post_incident_update sind still, es sei denn, notifySubscribers=true wird übergeben.
• Incident-Abbruch ist endgültig: Ein abgebrochener Incident kann nicht wieder geöffnet werden; verwenden Sie resolve für echte Schließungen.
• Keine Bulk-Vorgänge: Erstellen, schließen oder aktualisieren Sie keine Monitore oder Incidents in großen Mengen ohne Bestätigung pro Element.
• Postmortems erfordern menschliche Veröffentlichung: Das Postmortem wird im MCP als Entwurf gespeichert; die Veröffentlichung ist ein separater Schritt im Dashboard.
• Uptime-Werte: Ein fehlendes uptimePct bedeutet Keine Messungen für diesen Zeitraum – es ist NICHT 100 %.
• Daten außerhalb des Zeitraums: Standardmäßige Incident-Listen sind die letzten 7 Tage; Standard-Maintenance-Listen sind zukünftige/laufende Fenster.

Diese Skill arbeitet mit dem UptimeLens MCP-Server. Nicht gefundene Werkzeuge weisen auf ein Verbindungsproblem hin. Wenn Sie das Gefühl haben, dass Werkzeuge fehlen, überprüfen Sie die Serververbindung und die Benennung.

---

Hinweis: UptimeLens MCP-Server lesen. Einrichten. Verwalten. Schreiben Sie den nächsten Teil der Produktgeschichte in der UptimeLens-MCP-Integration.