UptimeLens Bereitschaftsdienst

Was macht UptimeLens Bereitschaftsdienst?

Betreiben Sie UptimeLens Bereitschafts- und Eskalationsworkflows auf den eigenen Ressourcen des Kunden über den UptimeLens MCP-Server. Diese Fähigkeit verwandelt eine Alarmierungsfrage („Wer hat Bereitschaft?“, „Bestätige die Page“, „Übernimm meine Schicht“) in die korrekte Abfolge von MCP-Tool-Aufrufen.

Wann diese Fähigkeit verwendet werden sollte

Verwenden Sie sie für die operative Seite der Incident-Alarmierung:

• Herausfinden, wer aktuell Bereitschaft hat (oder warum niemand Bereitschaft hat).
• Bestätigen oder Pausieren einer aktiven Eskalation, die eine Person anfunkt.
• Übernehmen einer Schicht durch Überschreiben einer Bereitschaftsrotation für einen Zeitraum.
• Prüfen von Eskalationsläufen (aktive Pages + Verlauf) und Eskalationsrichtlinien.

Für die Ursachenanalyse eines Incidents (im Gegensatz zur Verwaltung der Page) bevorzugen Sie den schreibgeschützten MCP-Prompt triage_incident oder die Lesetools get_incident, get_root_cause, list_status_changes und query_metrics. Diese Fähigkeit bleibt auf der Bereitschafts-/Eskalationsebene und verlinkt nur dann auf den Incident-Kontext, wenn dies bei der Entscheidung hilft, wer handeln sollte.

Voraussetzungen

1. Der UptimeLens MCP-Server ist mit diesem Client verbunden. Lesetools funktionieren mit jedem Plan.
2. Schreibaktionen (acknowledge_escalation, bulk_acknowledge_escalation, resolve_escalation, snooze_escalation, escalate_escalation, create_on_call_override, update_on_call_override, delete_on_call_override, create_cover_request, accept_cover_request, decline_cover_request) erfordern ein 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 davon haben eine zweite, pro-Funktion-Schranke zusätzlich zur Planschranke, und sie sind nicht alle gleich:
   • create_on_call_override, update_on_call_override und accept_cover_request benötigen die Bereitschaftsüberschreibungs-Funktion. Akzeptieren zählt, weil es eine aktive Überschreibung erzeugt – genau das, was die Funktion verkauft. (Eine ausstehende Anfrage, die in einem kostenpflichtigen Plan erstellt und nach einem Downgrade akzeptiert wurde, würde sonst eine Überschreibung erzeugen, die der Plan nicht mehr enthält; diese Lücke wurde bewusst geschlossen.)
   • create_cover_request benötigt eine andere Funktion – Bereitschafts-Deckungsanfragen –, sodass ein Plan die eine, aber nicht die andere enthalten kann.
   • delete_on_call_override und decline_cover_request sind bewusst ohne Schranke: Das Rückgängigmachen einer Aktion muss auch nach einem Downgrade möglich bleiben, sonst wäre ein Schichttausch, den Sie nicht mehr bearbeiten können, auch einer, den Sie nicht mehr stornieren können. Jede dieser kann FeatureNotAvailable zurückgeben, selbst mit einem Lese-Schreib-Token.

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. Referenzieren Sie sie vollqualifiziert als UptimeLens:<tool> – ersetzen Sie UptimeLens durch den Namen, den der Connector in diesem Client erhalten hat, da sonst das Werkzeug möglicherweise nicht gefunden wird.

Lesen (Entdeckung und Kontext):

• UptimeLens:list_on_call_schedules – Zeitpläne; Quelle der scheduleId, die who_is_on_call und create_on_call_override benötigen.
• UptimeLens:who_is_on_call – wer hat jetzt für einen Zeitplan Bereitschaft; gibt gapReason zurück, wenn niemand Bereitschaft hat.
• UptimeLens:get_on_call_schedule – die kommende Besetzung für einen Zeitplan für die nächsten N Tage (Standard 7, max. 90): jede Schicht (wer, wann, Rotation vs. Überschreibung), Abdeckungslücken mit Grund und eine Abdeckungszusammenfassung. Verwenden Sie dies für zukünftige Abdeckung; who_is_on_call ist nur für jetzt.
• UptimeLens:list_on_call_overrides – die aktiven und bevorstehenden Überschreibungen für einen Zeitplan; die Quelle der id, die update_on_call_override und delete_on_call_override benötigen. Jeder Eintrag enthält den Benutzer (wer die Schicht übernimmt), den Anforderer (requestedBy, nur für eine ausstehende Deckungsanfrage – wer die Deckung angefordert hat), das Zeitfenster, den Grund und den Status. Nur eine active Überschreibung ist bearbeitbar; ein pending Eintrag ist eine Deckungsanfrage, die noch auf die Annahme des Zielbenutzers wartet, und update_on_call_override wird sie ablehnen. Vergangene Überschreibungen werden nicht aufgelistet.
• UptimeLens:list_escalation_runs – Eskalationsläufe (aktive Pages + Verlauf); Quelle der runId, die acknowledge_escalation, snooze_escalation und escalate_escalation benötigen. Der Fortschritt ist 1-basiert: currentStep (der Schritt, den die Eskalation erreicht hat), nextStep (wird als nächstes ausgelöst), totalSteps.
• UptimeLens:get_escalation_run – der vollständige Zustand eines Laufs: welchen Schritt die Eskalation erreicht hat und welcher als nächstes ausgelöst wird (currentStep/nextStep von totalSteps), Wiederholungsfortschritt, Dringlichkeit, Bestätigungs-/Auflösungsmethode (WARUM es endete), Pausen- und Bestätigungszeitüberschreitungen, nextActionAt, auslösender Monitor/Incident.
• UptimeLens:get_escalation_run_timeline – das chronologische Ereignisprotokoll eines Laufs: Benachrichtigungen, Zustellungsergebnisse, Bestätigungszeitüberschreitungen, übersprungene Ziele, Wiederholungen, Auflösung – die umfangreichste Quelle für „Was ist passiert / warum es eskalierte“.
• UptimeLens:list_escalation_policies – die Bereitschafts-Alarmierungsregeln.
• UptimeLens:get_escalation_policy – Details einer Richtlinie: geordnete Schritte nummeriert 1..N (die Zahlen currentStep/nextStep in list_escalation_runs beziehen sich darauf), Verzögerung jedes Schritts, Zielstrategie und Ziele. Lösen Sie Zeitplanziele über who_is_on_call und Benutzerziele über list_team_members auf.
• UptimeLens:list_team_members – Personen im Team; Quelle der userId, die create_on_call_override benötigt.

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

• UptimeLens:acknowledge_escalation – weiteres Paging für einen aktiven Lauf stoppen. Eingabe: runId.
• UptimeLens:resolve_escalation – die Page dauerhaft schließen. Eingabe: runId. Anders als beim Bestätigen funkt ein aufgelöster Lauf nie wieder, also verwenden Sie es, wenn das zugrunde liegende Problem als behoben bestätigt ist – nicht als Möglichkeit, einen lauten Alarm zu stoppen.
• UptimeLens:bulk_acknowledge_escalation – viele aktive Läufe auf einmal bestätigen. Eingabe: runIds (1–50). Teilweiser Erfolg: bereits aufgelöste/unbekannte Läufe werden als übersprungen gezählt, nicht als Fehler. Verwenden Sie nach list_escalation_runs(state=active), um einen Stapel zu leeren.
• UptimeLens:snooze_escalation – Paging für einen Lauf für eine bestimmte Anzahl von Minuten pausieren. Eingabe: runId, durationMinutes (1–240).
• UptimeLens:escalate_escalation – den nächsten noch nicht benachrichtigten Schritt sofort anfunken, anstatt seinen Timer abzuwarten („Jetzt eskalieren“). Eingabe: runId. Nichts wird übersprungen: der als nextStep angezeigte Schritt wird ausgelöst; nach dem letzten Schritt beginnt die nächste Wiederholung sofort, und wenn keine Wiederholung mehr übrig ist, wird der Lauf als erschöpft geschlossen (nextStep ist 0 – teilen Sie dem Benutzer mit, dass niemand mehr zum Anfunken übrig ist). Der Lauf wird wieder aktiv und seine Dringlichkeit wird high. Abgelehnt für Testläufe und beendete Läufe.
• UptimeLens:create_on_call_override – einen Benutzer für einen Zeitplan während eines Zeitfensters in Bereitschaft versetzen. Eingabe: scheduleId, userId, endAt; optional startAt (Standard ist jetzt), reason. Erfordert die Bereitschaftsüberschreibungsfunktion (siehe Voraussetzungen).
• UptimeLens:update_on_call_override – eine bestehende Überschreibung direkt bearbeiten: ihr endAt oder reason ändern und (nur bevor sie beginnt) ihr userId oder startAt. Eingabe: id (aus dem Ergebnis von create_on_call_override oder entdeckt über list_on_call_overrides, wenn Sie sie nicht gerade erstellt haben) plus die zu ändernden Felder; ein Feld weglassen bedeutet, es unverändert zu lassen. So verkürzen, verlängern oder übertragen Sie eine Deckung; verwenden Sie delete_on_call_override, wenn der Tausch gar nicht stattfinden soll. Erfordert die Bereitschaftsüberschreibungsfunktion.
• UptimeLens:delete_on_call_override – eine Überschreibung vollständig löschen: der Tausch wird storniert und die normale Rotation gilt wieder. Eingabe: id. Verwenden Sie dies anstatt einer Bearbeitung, wenn die Deckung gar nicht stattfinden soll.
• UptimeLens:create_cover_request – einen Teamkollegen bitten, ein Zeitfenster zu übernehmen, anstatt es zuzuweisen: erstellt eine pending Anfrage und sendet eine E-Mail an den Zielbenutzer, der annehmen muss, bevor sie zu einer aktiven Überschreibung wird. Eingabe: scheduleId, userId (wer gebeten wird), startAt, endAt; optional reason. Verwenden Sie create_on_call_override, wenn die Schicht sofort ohne Nachfrage zugewiesen werden soll.
• UptimeLens:accept_cover_request – eine pending Deckungsanfrage annehmen → sie wird zu einer aktiven Überschreibung (der Zielbenutzer übernimmt die Schicht). Eingabe: id (ein pending Eintrag aus list_on_call_overrides). Nur der Zielbenutzer oder ein Admin kann annehmen.
• UptimeLens:decline_cover_request – eine pending Deckungsanfrage ablehnen (es wird keine Überschreibung erstellt). Eingabe: id (ein pending Eintrag aus list_on_call_overrides). Nur der Zielbenutzer oder ein Admin kann ablehnen.

Kernworkflow: Behandlung eines Bereitschaftsalarms

Die meisten Schreibwerkzeuge benötigen eine ID, die nur ein Lesewerkzeug liefern kann, also entdecken Sie immer zuerst. Kopieren Sie diese Checkliste und arbeiten Sie sie ab:

Bereitschaftsantwort:
- [ ] 1. Finden Sie die aktiven Eskalationsläufe (list_escalation_runs, state=active, isTest=false)
- [ ] 2. Wählen Sie den betreffenden Lauf aus (sortieren Sie nach startedAt; prüfen Sie Dringlichkeit und currentStep/totalSteps)
- [ ] 3. Fügen Sie bei Bedarf Kontext hinzu (incidentId → get_incident; triggeringMonitorId → list_status_changes → get_root_cause)
- [ ] 4. Entscheiden Sie: Bestätigen (übernehmen, Paging stoppt) oder Pausieren (N Minuten pausieren, Paging wird fortgesetzt)
- [ ] 5. Bestätigen Sie die Aktion mit dem Benutzer, dann rufen Sie das Schreibwerkzeug mit der ID des Laufs auf

Schritt 1 – aktive Läufe finden. Rufen Sie list_escalation_runs mit state="active" auf. Verwenden Sie isTest=false für echte, incident-ausgelöste Pages; isTest=true sind „Page-yourself“-Testläufe und sollten nicht als Live-Incidents behandelt werden.

Schritt 2 – Lauf auswählen. Jeder Lauf hat eine id (dies ist die runId für Schreibwerkzeuge), urgency (high/low), currentStep von totalSteps (wie weit die Eskalation fortgeschritten ist – 1-basiert; höher bedeutet, dass mehr Personen benachrichtigt wurden; nextStep ist, wer als nächstes benachrichtigt wird), und startedAt. Wenn mehrere aktiv sind, sortieren Sie nach startedAt (älteste zuerst) und zeigen Sie high-Dringlichkeit zuerst an.

Schritt 3 – Kontext (optional). Wenn der Lauf eine incidentId hat, rufen Sie get_incident für Auswirkung und Zeitachse auf. Wenn er eine triggeringMonitorId hat, rufen Sie list_status_changes mit dieser Monitor-ID auf, um die letzten Up/Down-Änderungen zu sehen, dann get_root_cause mit einer statusChangeId aus dieser Liste für netzwerkdiagnose pro Probe. Verwenden Sie dies nur, um dem Benutzer bei der Entscheidung zu helfen; beginnen Sie hier keine vollständige Untersuchung.

Schritt 4 / 5 – handeln. Wählen Sie Bestätigen vs. Pausieren vs. Eskalieren (unten), bestätigen Sie, dann schreiben Sie.

Bestätigen, Auflösen, Pausieren oder Eskalieren

• Bestätigen (acknowledge_escalation) bedeutet „Ich übernehme das jetzt“ – das Paging stoppt, während Sie arbeiten. Dies ist die richtige Antwort für „übernehmen“, „Ich hab’s“ oder „stummschalten“ einer Page. Das Bestätigen eines Laufs, der nicht mehr aktiv ist, gibt einen EscalationRunAlreadyResolved-Fehler zurück – harmlos (er wurde bereits bestätigt oder aufgelöst); melden Sie ihn als bereits erledigt und versuchen Sie es nicht erneut.

• Auflösen (resolve_escalation) bedeutet „das ist vorbei“ – der Lauf wird dauerhaft geschlossen und funkt nie wieder. Verwenden Sie es, wenn der Benutzer sagt, das zugrunde liegende Problem ist behoben, nicht nur, dass er sich darum kümmert. Ein Lauf löst sich auch von selbst auf, wenn sein Incident aufgelöst wird, daher ist das manuelle Auflösen für den Fall gedacht, dass die Page das Problem überlebt hat. Da es nicht rückgängig gemacht werden kann, bevorzugen Sie im Zweifelsfall das Bestätigen.

• Pausieren (snooze_escalation) bedeutet „für durationMinutes stumm schalten, dann wieder anfunken“ – ein Aufschub, keine Übernahme. Es ist nicht idempotent: Jeder Aufruf setzt das Pausenfenster auf jetzt + N Minuten zurück, sodass ein erneuter Aufruf die Stille verlängert. Verwenden Sie die kleinste passende Dauer (1–240), und pausieren Sie niemals anstelle des Bestätigens, wenn der Alarm tatsächlich einen Verantwortlichen benötigt.

• Jetzt eskalieren (escalate_escalation) bedeutet „das braucht mehr Leute, jetzt“ – der nextStep des Laufs wird sofort benachrichtigt, anstatt nach seiner Wartezeit, die Dringlichkeit wird high (Ruhezeiten gelten nicht mehr), und ein bestätigter Lauf wird wieder aktiv. Verwenden Sie es, wenn der Benutzer sagt, der aktuelle Bearbeiter kann es nicht bewältigen oder niemand antwortet; es ist das Gegenteil von Pausieren, rufen Sie also niemals beide im selben Durchgang für denselben Lauf auf. Teilen Sie dem Benutzer mit, welcher Schritt benachrichtigt wird (nextStep von get_escalation_run).

Das Bestätigen des falschen Laufs schaltet eine echte Page stumm und niemand wird alarmiert, bestätigen Sie daher, dass die runId mit dem Alarm übereinstimmt, den der Benutzer meint.

Abdeckungslücken

who_is_on_call gibt einen gapReason zurück, wenn niemand Bereitschaft hat:

• schedule_disabled – der Zeitplan ist deaktiviert; die Richtlinie verlässt sich auf andere Ziele.
• no_active_rotations / no_rotation_members – der Zeitplan hat niemanden, der gerade für das Paging zugewiesen ist.
• outside_active_window – es liegt außerhalb der aktiven Zeiten dieses Zeitplans.

Wenn eine Lücke besteht und jemand die Page übernehmen muss, setzt create_on_call_override einen bestimmten Benutzer für ein Zeitfenster in Bereitschaft. Entdecken Sie scheduleId über list_on_call_schedules und userId über list_team_members (Teammitglieder zeigen keine E-Mail oder Telefonnummer – gleichen Sie nach Name/Rolle ab).

who_is_on_call meldet nur die jetzt bestehende Lücke. Um Lücken bevor sie jemanden anfunken, zu finden, rufen Sie get_on_call_schedule für den Zeitplan auf – sein Array gaps listet jedes nicht abgedeckte Fenster in den nächsten N Tagen mit denselben Gründen auf, und coveragePercent fasst zusammen, wie gut der Zeitraum abgedeckt ist. Dies ist der proaktive Begleiter von who_is_on_call.

Vor dem Schreiben bestätigen

Lesen und triagieren Sie frei. Rufen Sie bei den Schreibwerkzeugen zuerst die Handlung auf, die Sie ausführen werden, und holen Sie die Zustimmung des Benutzers ein – diese ändern, wer angefunkt wird:

• Bestätigen / Pausieren: Nennen Sie den Lauf (Dringlichkeit, was ihn ausgelöst hat) und für Pausieren die Minuten.
• Auflösen: Sagen Sie deutlich, dass die Page dauerhaft geschlossen wird und nicht erneut funkt. Fragen Sie, ob das zugrunde liegende Problem tatsächlich behoben ist – „Mach es still“ ist eine Anfrage zum Bestätigen oder Pausieren, nicht zum Auflösen.
• Überschreibung: Nennen Sie den Zeitplan, den Benutzer und das genaue Zeitfenster (startAt–endAt, UTC RFC3339). Wenn das Fenster Mitternacht überschreitet, ist das Datum von endAt der Folgetag; endAt muss nach startAt liegen.
• Überschreibung löschen / Deckungsanfrage ablehnen: Nennen Sie, wessen Schicht zur normalen Rotation zurückfällt. Das Stornieren einer Deckung ändert, wer angefunkt wird, genauso wie das Erstellen einer.

Die meisten dieser Aktionen sind umkehrbar – eine Überschreibung kann bearbeitet oder verkürzt werden, eine Bestätigung oder Pausierung kann re-eskaliert werden –, daher ist das Ziel eine klare menschliche Entscheidung, keine Genehmigungsmauer. Zwei sind nicht:

• Dauerhafte Handlungen: Das Auflösen eines Eskalationslaufs (resolve_escalation) ist endgültig – der Lauf wird niemals erneut anfunken. Das Löschen einer Überschreibung (delete_on_call_override) setzt die normale Rotation wieder ein. Für beide sollte der Benutzer die Konsequenzen klar verstehen, bevor er fortfährt.