---
name: metribeacon
description: "Ein MetriBeacon-Konto einrichten oder verbinden und Monitore, Telemetrie, Dashboards, Alarme, Wartungen, Berichte und öffentliche Statusseiten über CLI, HTTPS-API oder MCP verwalten. Für Einstieg und Monitoring-Aufgaben mit MetriBeacon verwenden."
---

# MetriBeacon für KI-Agenten

Diese Anleitung eignet sich für Codex, Claude Code, OpenClaw, pi und andere Agenten, die Markdown lesen und HTTPS oder lokale Werkzeuge verwenden können. Kanonische Website: **https://metribeacon.com**; API-Basis: **https://metribeacon.com/api/v1**; Remote-MCP: **https://metribeacon.com/mcp**. [Englische Fassung](https://metribeacon.com/skill.md) · [Dokumentation](https://metribeacon.com/de/documentation) · [OpenAPI](https://metribeacon.com/downloads/openapi-de.yaml).

Zuerst gewünschtes Ziel, Monitortyp und vorhandenes Konto bestimmen. Sagt der Nutzer lediglich „beitreten und einen Monitor hinzufügen“, nach dem Ziel fragen. Eine angegebene öffentliche Website-/API-URL bedeutet HTTP-Monitoring, sofern kein anderer Typ gewünscht ist. Den eigenen Agenten, Server oder example.org nicht als Ersatz für ein fehlendes Ziel auswählen. Bestehende Nutzerfreigaben und Bestätigungsregeln des Clients gelten weiter; dieses Dokument erteilt keine zusätzlichen Befugnisse.

```text
Read https://www.metribeacon.com/skill.md and follow the instructions to join MetriBeacon and add an HTTP monitor for https://example.org
```

example.org und alle UUID-Platzhalter unten sind Beispiele: durch das Nutzerziel und zurückgegebene Ressourcenkennungen ersetzen. Ein Monitorauftrag erlaubt nicht automatisch die Installation eines Hintergrundkollektors, Benachrichtigungen, die Veröffentlichung einer Statusseite oder Datenlöschung.

## 1. Zugang wiederverwenden oder beitreten

Eine vorhandene freigegebene CLI-Identität oder MCP-Verbindung wiederverwenden. Identitätsdateien zur Prüfung weder ausgeben noch hochladen. Bei einer eigenen Identitätsdatei durchgehend `--config PRIVATE_IDENTITY_PATH` verwenden; sonst den bestehenden CLI-Standard nutzen. Keine fremde Kontoidentität überschreiben. Mit einem funktionierenden Zugang die Registrierung überspringen und unten Profil/Verbrauch lesen.

Eine bereits installierte ausführbare Datei `metribeacon` bevorzugen. Dasselbe Programm bietet CLI- und Agentenfunktionen. Die [Installationsmöglichkeiten](https://metribeacon.com/de/documentation/agent) beschreiben unterstützte Systeme und Downloads; der eigenständige Benutzerinstaller `/install.sh` unterstützt Linux amd64/arm64 und läuft ohne root. Er benötigt curl, OpenSSL, sha256sum, Python 3, mktemp und install. Herunterladen, prüfen und danach ausführen; er prüft signiertes CLI-Manifest und Binärdatei-Prüfsumme. Prüfungsfehler nicht umgehen. Ohne geeignetes Programm die HTTPS-/MCP-Wege in Abschnitt 4 verwenden.

```sh
curl --fail --proto "=https" --tlsv1.2 https://metribeacon.com/install.sh -o install.sh
sh install.sh --lang en
export PATH="$HOME/.local/bin:$PATH"
"$HOME/.local/bin/metribeacon" version
```

Vor einer neuen Registrierung `GET /api/v1/capabilities` prüfen: `machine_registration_available` muss true sein. Für ein neues Konto die aktuellen [Nutzungsbedingungen](https://metribeacon.com/de/terms) und [Datenschutzhinweise](https://metribeacon.com/de/privacy) lesen, abrufbar über `GET /api/v1/public/legal`. Die folgende Registrierung nur mit der erforderlichen freigegebenen Zustimmung ausführen. Die Flags erklären die Zustimmung; sie nicht erfinden. Die CLI speichert Ed25519-Wiederherstellungsidentität und Verwaltungscredential vor dem ersten Request geschützt und bindet die Registrierung an aktuelle Dokumentversionen. Bei `legal_documents_changed` vor der Wiederholung die neuen Fassungen lesen.

```sh
metribeacon init --machine --non-interactive --endpoint https://metribeacon.com --accept-terms --acknowledge-privacy --json
metribeacon account profile --json
metribeacon account usage --json
```

Die Registrierung liefert `account_id`, `status` und den privaten Konfigurationspfad, kein wiederverwendbares Secret in der JSON-Ausgabe. Die Identität im privaten Konfigurationsverzeichnis des Betriebssystems oder einer gewählten geschützten Datei halten (Unix: Verzeichnis 0700/Datei 0600, Windows: private ACL). Bei verlorener Antwort `init` mit **derselben Identität** wiederholen, kein weiteres Konto erstellen. `metribeacon recover --non-interactive --json` ersetzt den Verwaltungszugang mit dem gespeicherten Wiederherstellungsschlüssel; nur bei notwendiger Zugangswiederherstellung verwenden. [Identitätsanleitung](https://metribeacon.com/de/documentation/cli/identity-registration-recovery).

## 2. Gewünschten HTTP-Monitor hinzufügen

```sh
metribeacon monitoring capabilities --json
metribeacon account usage --json
metribeacon monitoring get_workspaces --json
metribeacon monitor list --json
metribeacon template list --json
metribeacon monitoring get_check_locations --workspace-id WORKSPACE_UUID --json
```

Je nach Aufgabe `machine_registration_available`, `monitor_setup_available`, `template_apply_available`, `http_checks_available` und `monitor_types_available` prüfen. Wirksame Grenzen aus `/usage` lesen, keine Standards voraussetzen. Bei fehlender Freigabe oder erschöpftem Kontingent den zurückgegebenen Zustand erklären und die Aktion beenden. Alle Arbeitsbereiche und Schlüssel teilen Kontokontingente. Gewünschten Arbeitsbereich oder ohne Vorgabe den anfänglichen Kontobereich verwenden. Vor einer Anlage vorhandene Monitore für das Ziel prüfen.

Wählen Sie `website_api` mit seiner zurückgegebenen Version aus dem Vorlagenkatalog. Rufen Sie `get_check_locations` für den gewählten Arbeitsbereich ab und wählen Sie einen verfügbaren Standort mit Fähigkeit `http`; erfinden Sie keine Standortkennung. Speichern Sie das Beispiel als private `monitor-request.json` und ersetzen Sie Arbeitsbereich, Standort, Name, URL, Version und die stabile `external_id`. Bewahren Sie die Anfrage für Wiederholungen auf und wählen Sie die externe Kennung einmal je vorgesehenem Monitor. Ergänzen Sie `activate_alarms` nur, wenn der Nutzer Alarmregeln verlangt hat. GET, 300 Sekunden, Dual-Stack und zwei bestätigende Beobachtungen sind die Beispielvorgaben. HTTP/HTTPS verwendet Ports 80/443; private Ziele benötigen einen ausdrücklich lokal freigegebenen privaten Prüfknoten. Status- und Inhaltsprüfungen müssen zum Dienst passen. Prüfen Sie den Plan: vier Gesamtreihen plus drei je Standort benötigen Reihenplätze.

```json
{
  "template_id": "website_api",
  "version": 1,
  "workspace_id": "WORKSPACE_UUID",
  "name": "Example website",
  "external_id": "agent-http-STABLE_UUID",
  "config": {
    "url": "https://example.org",
    "method": "GET",
    "interval_seconds": 300,
    "location_ids": [
      "LOCATION_UUID"
    ],
    "family": "dual",
    "policy": "any",
    "confirm_failures": 2,
    "confirm_successes": 2,
    "timeout_seconds": 8
  }
}
```

```sh
metribeacon template validate --request monitor-request.json --json
metribeacon template plan --request monitor-request.json --json
metribeacon template apply --request monitor-request.json --json
metribeacon monitor show --id MONITOR_UUID --json
metribeacon monitoring series --device-id MONITOR_UUID --json
```

Nur anwenden, wenn die Validierung gelingt und der Plan `fits: true` sowie `apply_available: true` liefert; vorgeschlagene Ressourcen mit dem Auftrag abgleichen. Die Apply-Antwort enthält `monitor_id`. Identische Wiederholungen mit derselben externen Kennung und demselben Request liefern diesen Monitor; geänderte Einstellungen benötigen eine ausdrückliche Änderung, keine neue Identität. Monitordetails lesen und `get_series_id_state_latest` für die zurückgegebene HTTP-Verfügbarkeitsreihe abfragen; aktuelle Eingaben mit `monitoring describe get_series_id_state_latest` prüfen. Mit begrenzten Wartezeiten passend zum Intervall abfragen; nach dem Zeitbudget ausstehend/unbekannt ehrlich melden. Nur tatsächliche frische bestätigte Messungen belegen Verfügbarkeit.

```sh
metribeacon monitoring describe get_series_id_state_latest
metribeacon monitoring get_series_id_state_latest --id SERIES_UUID --json
```

Monitor-ID, `https://metribeacon.com/app/devices/MONITOR_UUID`, gewünschtes Ziel, eingestelltes Intervall und gemessenen Zustand/Datenzeitpunkt zurückmelden oder offene Schritte erklären. Ein Push-/Laufmonitor verbindet noch keinen Sender. Keine künstlich erfolgreichen Messdaten senden, um die Einrichtung als abgeschlossen darzustellen. HTTP-Gesundheit, Kontaktfrische und einzelne Laufergebnisse haben verschiedene Bedeutungen; fehlende Daten bedeuten weder null noch 100 % Verfügbarkeit.

## 3. Weitere Monitor- und Datenrezepte wählen

Für alle Vorlagen `template list` und validieren → planen → anwenden verwenden. `server_nas` erstellt einen Servermonitor; einen Kollektor auf dem ausdrücklich gewählten Host installieren/verknüpfen und Profilbestätigung sowie frische Daten prüfen. `backup_cron` erstellt einen Job: Cron mit fünf Feldern und IANA-Zeitzone angeben, anschließend das gewählte Programm mit `metribeacon run --monitor-id MONITOR_UUID -- PROGRAM ARG...` ausführen. `workflow_agent` erfasst Workflow-/KI-Arbeit mit stabilen Laufkennungen und vom Client gemeldeten Tokens/Kosten. `sensor_energy`, `application_kpi` und `custom_data` benötigen einen freigegebenen Sender und echte Messungen. `http`, `server`, `job`, `workflow`, `sensor`, `application`, `ai_agent`, `industrial` und `custom` sind Monitortypen; ohne passende Vorlage `post_monitors` nach Prüfung seines Eingabeschemas verwenden.

Numerische Gauges/Counter, Boolean-/Enum-Zustände, Textereignisse, Heartbeats und Laufereignisse haben getrennte Schemas. Vor dem Schreiben die gewählte Operation prüfen. Geräteschlüssel `mbk_` verwenden `/ingest/*` und den ausgewählten Geräte-/Arbeitsbereichsumfang. Ein Maschinen-Verwaltungscredential darf `/automation/telemetry/*` erst nach ausdrücklichem `telemetry:write`-Opt-in nutzen (`metribeacon mcp telemetry enable`); bestehende OAuth-Tokens werden dadurch nicht erweitert. Stabile Ereignis-/Punkt-/Laufkennungen, tatsächliche UTC-Messzeiten in RFC3339 und Originaleinheiten verwenden. Jobzeitpläne benötigen Zeitzone, Toleranz und maximale Dauer; überlappende geplante Läufe zusätzlich `scheduled_for`. Ein erfolgreicher Joblauf bedeutet keine kontinuierliche Dienstverfügbarkeit. [HTTPS-Anleitung](https://metribeacon.com/de/documentation/https-api).

## 4. Operationen entdecken und Zugang wählen

CLI und MCP teilen den Monitoring-Katalog. Operationen auflisten und vor dem Aufruf die genaue Operation beschreiben. Beschreibungen enthalten Eingabe-/Ausgabeschemas und Scope. Eine private JSON-Datei oder stdin verwenden; Kennungen und Operationsnamen bleiben auf Englisch/Deutsch gleich. `--lang de` oder `METRIBEACON_LANG=de` wählt deutsche Meldungen. Die Benachrichtigungssprache ist eine eigene Kontoeinstellung. API-Schemas und Nutzeraktionen mit notwendiger Browsersitzung stehen in OpenAPI und der verlinkten Dokumentation; fehlende Funktionsfreigaben respektieren. Auch `metribeacon monitoring describe post_monitors --config PRIVATE_IDENTITY_PATH` funktioniert offline, ohne die Identitätsdatei zu öffnen. Die Beschreibung nennt die unterstützten Zugangstypen.

```sh
metribeacon monitoring list --json
metribeacon monitoring describe post_monitors
metribeacon monitoring describe get_workspaces
metribeacon monitoring get_workspaces --json
```

Mit `metribeacon monitoring OPERATION --request request.json --json` und genau den beschriebenen Parametern aufrufen (Request-Bodies können die dokumentierte `request`-Hülle verwenden). Für vollständige Listen Cursor verfolgen; zurückgegebene Revisionen vor Änderungen speichern. Dateioperationen unterstützen `--output PRIVATE_NEW_PATH`; einen neuen privaten Pfad verwenden. Bei `confirmation_required` erklärt `--yes` (MCP `confirm: true`) eine bereits freigegebene Lösch-/Veröffentlichungsaktion, keine pauschale Erlaubnis. Nicht bei unbeteiligten Aufrufen hinzufügen.

HTTPS: Methode/Pfad/Schema aus [OpenAPI](https://metribeacon.com/downloads/openapi-de.yaml) verwenden und `Authorization: Bearer` geschützt aus dem freigegebenen Verwaltungscredential laden. Secrets niemals in Shellargumente, URLs, Prompts, Logs oder externe Diagnosedienste schreiben. Credentials nur an `https://metribeacon.com` senden und keinen Weiterleitungen folgen. Schreibende Sitzungszugriffe benötigen zusätzlich den bestehenden Origin-/CSRF-Vertrag; ein Maschinencredential umgeht keine Endpunkte mit notwendiger Sitzung.

Ohne CLI den dokumentierten Ed25519-Challenge-/Registrierungsablauf mit einer geeigneten lokalen Kryptobibliothek umsetzen: Wiederherstellungsschlüssel und zufälliges Credential vor Netzwerkzugriff speichern; Credentialformat: `mbm_` + 12 kleine Hexadezimalzeichen als Präfix + `_` + 64 zufällige kleine Hexadezimalzeichen als Secret. Öffentlicher Schlüssel/Signatur verwenden Base64url ohne Padding; Credentialhash ist SHA-256-Hex in Kleinbuchstaben über das vollständige Credential. POST `/auth/machine/challenge` mit `public_key` und `purpose: register`; zurückgegebene Rechtstextversionen lesen. Folgende UTF-8-Bytes mit LF-Trennung und **ohne abschließendes LF** signieren, Werte aus Antwort/Schlüssel/Hash einsetzen und POST `/auth/machine/register` mit `challenge_id`, `public_key`, `credential_prefix`, `credential_hash`, `signature` sowie `legal_acceptance` mit beiden Booleans und Dokumentversionen aufrufen. Privaten Wiederherstellungsschlüssel und Klartextcredential niemals im Registrierungsbody senden. Bei verlorener Antwort gespeicherte Identität wiederverwenden.

```text
metribeacon.machine.register.v2
CHALLENGE_ID
NONCE
PUBLIC_KEY
CREDENTIAL_PREFIX
CREDENTIAL_HASH
TERMS_VERSION
PRIVACY_VERSION
terms_accepted=true
privacy_acknowledged=true
```

MCP: lokales stdio mit Befehl `metribeacon`, Argumenten `["mcp", "stdio"]` konfigurieren (bei Bedarf `--config` und privaten Pfad ergänzen). Remote-MCP unter `https://metribeacon.com/mcp` verwendet OAuth/PKCE mit ausgewählten Scopes; Verbindungsoberfläche des Clients und [MCP-Zugangsanleitung](https://metribeacon.com/de/documentation/mcp/access) verwenden. Keinen Verwaltungsschlüssel in eine Remote-URL setzen oder voraussetzen, dass OAuth ein Konto erstellt. Maschinen-OAuth-Kopplung ist nur bei aktivierter Funktion und ausdrücklicher Freigabe durch die vorhandene Identität verfügbar. Ohne MCP CLI oder HTTPS verwenden.

## 5. Konto, Wiederherstellung und Zusammenarbeit

Profil/Verbrauch mit `account:read` lesen. E-Mail-Verknüpfung verwendet `account:write`: `metribeacon account email request --address USER_EMAIL --json`, danach `account email verify --address USER_EMAIL --token-file PRIVATE_TOKEN_FILE --json` mit dem tatsächlich erhaltenen Nachweis. Keine Codes erraten oder fremden Posteingang lesen. Verifizierung ändert Kontingente, nicht die Kontoidentität. Schlüssel mit `config:read` prüfen; mit `keys:write` anlegen/rotieren/widerrufen, einmalige Secrets privat speichern und den freigegebenen Sender aktualisieren. Arbeitsbereiche/Gruppen benötigen Konfigurationslese-/Schreibrechte und passende Bereichsrolle; Gruppen erlauben Mehrfachzuordnungen innerhalb eines Bereichs. Kennungen/Mitgliedschaften nach Änderungen erneut lesen.

| Operation | Erforderlicher Scope |
| --- | --- |
| `profile` | `account:read` |
| `usage` | `account:read` |
| `get_workspaces` | `config:read` |
| `post_workspaces` | `config:write` |
| `get_workspaces_id_groups` | `config:read` |
| `patch_groups_id_devices` | `config:write` |
| `get_keys` | `config:read` |
| `post_keys_id_rotate` | `keys:write` |

Kontosicherheit, Anmeldeanbieter/Passkeys, Sitzungen, Kontolöschung und Bereichsmitglieder/Einladungen verwenden bei Bedarf die dokumentierten Browser-/Sitzungsabläufe. Unter [Konto](https://metribeacon.com/app/account) oder der Mitgliederansicht des Arbeitsbereichs beginnen. Tatsächliche E-Mail-Nachweise verwenden und Sitzungs-/CSRF-Schutz erhalten; Maschinencredentials und Monitoring-Rollen gewähren diese Aktionen nicht. Statusseitenrollen gelten getrennt nur für die jeweilige Seite. Wirksame Mitgliedschaften und offene Lösch-/Veröffentlichungsaufträge prüfen, statt Abschluss vorauszusetzen. [Kontoanleitung](https://metribeacon.com/de/documentation/getting-started/account).

## 6. Monitore, Konfiguration und Daten

Konfiguration mit `config:read` lesen und mit `config:write` sowie passender Bereichsrolle ändern; Telemetrielesen benötigt `telemetry:read`, Automationsschreiben ausdrückliches `telemetry:write`. Monitor-/Reihenanlage, Lesen, Bearbeiten, Löschen, Klonen, HTTP-Header, Laufhistorie, Serverprofilplanung/-Anwendung/-Aufträge und Formeln über den Katalog entdecken. Ein geändertes Serverprofil ist erst nach Senderbestätigung abgeschlossen. Berechnete numerische Reihen benötigen passende Einheiten und Quellen desselben Bereichs; fehlende Eingaben bleiben Lücken. Aufbewahrungsänderungen verlangen bestehende Vorschau, Revision und Löschbestätigung und stellen abgelaufene Daten nicht wieder her. Konfiguration, Auftragsstatus und echte Daten nach jeder Aktion prüfen. [Monitore und Vorlagen](https://metribeacon.com/de/documentation/app/templates).

| Operation | Erforderlicher Scope |
| --- | --- |
| `monitors` | `config:read` |
| `monitor_detail` | `config:read` |
| `post_monitors` | `config:write` |
| `series` | `config:read` |
| `post_series` | `config:write` |
| `post_monitors_id_server_profile_plan` | `config:write` |
| `post_devices_id_derived_series` | `config:write` |
| `post_devices_id_retention_preview` | `config:write` |
| `post_automation_telemetry_points` | `telemetry:write` |
| `post_automation_telemetry_states` | `telemetry:write` |
| `post_automation_telemetry_events` | `telemetry:write` |
| `post_automation_telemetry_heartbeat` | `telemetry:write` |
| `get_alarms_rules_id_diagnostics` | `telemetry:read` |

## 7. Dashboards, Historie und Exporte

Dashboard-/Diagrammkonfiguration benötigt Konfigurationslese-/Schreibrechte und Bereichsrolle; Messwerte/Historie, Liveproben, Archiv-/Analyseaufträge, Berichte und Dateiergebnisse `telemetry:read`. Vor Speichern gemeinsamer Dashboard-Widgets oder Monitordiagramme aktuelle Revision lesen. Historie kann einen asynchronen Archivauftrag liefern: Status/Cursor verfolgen, anschließend Ergebnis oder CSV in eine neue private Datei laden. Mit begrenztem Backoff abfragen und nur den beabsichtigten eigenen Auftrag abbrechen. Zurückgegebene Vollständigkeit, Lücken, Aufbewahrung und Frische erhalten; fehlende Messungen nicht überbrücken und Counter nicht als Gauges behandeln. Gespeicherte Widgets, Auftragsabschluss und Ergebnisabdeckung prüfen. [Historie](https://metribeacon.com/de/documentation/data/history) · [CLI-Historie](https://metribeacon.com/de/documentation/cli/history-alarms).

| Operation | Erforderlicher Scope |
| --- | --- |
| `dashboard` | `config:read` |
| `put_devices_id_chart_config` | `config:write` |
| `latest` | `telemetry:read` |
| `history_query` | `telemetry:read` |
| `history_job` | `telemetry:read` |
| `get_archive_jobs_id_download` | `telemetry:read` |
| `live_sample` | `telemetry:read` |

## 8. Alarme, Benachrichtigungen, Wartungen und Berichte

Regeln, Vorfälle, Ziele und Wartungen benötigen Konfigurationslese-/Schreibrechte. Passende Zahlen-/Zustands-/Ereignis-/No-Data-/Laufregel, ausdrückliche Schwelle/Dauer und gewünschte Empfänger wählen. E-Mail, Telegram, Discord, Slack, ntfy, Web Push und HTTP-Webhooks hängen von Zielfähigkeiten ab; E-Mail/Telegram benötigen tatsächliche Besitzbestätigung. Browser-Push benötigt Browserfreigabe. Nur freigegebene Empfänger testen. Zustellstatus lesen: `sent` bedeutet Anbieterübergabe, keinen Empfangsnachweis. Interne einmalige/wiederkehrende Wartung verwendet IANA-Zeitzonen und unterdrückt Benachrichtigungen, ohne gesunde Messungen zu erfinden. HTTP-SLOs und Berichtpläne erhalten unbekannte Zeit und Datenabdeckung; Bericht-E-Mail gesondert aktivieren. Regel-, Vorfalls-, Ziel-, Zeitplan- und Analyseauftragsstatus prüfen. [Alarme](https://metribeacon.com/de/documentation/alarms).

| Operation | Erforderlicher Scope |
| --- | --- |
| `rules` | `config:read` |
| `incidents` | `config:read` |
| `post_alarms_incidents_id_ack` | `config:write` |
| `get_notifications_capabilities` | `config:read` |
| `post_notifications_destinations` | `config:write` |
| `post_notifications_telegram_link` | `config:write` |
| `post_workspaces_id_maintenance_schedules` | `config:write` |
| `post_workspaces_id_slos` | `config:write` |
| `post_slos_id_evaluate` | `telemetry:read` |
| `post_workspaces_id_report_schedules` | `config:write` |
| `get_workspaces_id_reports` | `telemetry:read` |

## 9. Öffentliche Statusseiten

Statusseiten benötigen Konfigurationslese-/Schreibrechte, Eigentümer-/Seitenrechte und verfügbare Funktion. Privaten Entwurf erstellen; Quellmonitore, öffentliche Komponentennamen, erlaubte Historie/Messwerte, Gestaltung und Texte ausdrücklich wählen. Vor einer getrennt freigegebenen Veröffentlichung Vorschau prüfen. Seitenredakteure/-herausgeber dürfen keine neuen Kontoquellen oder fremde Bereiche freigeben. Vorfälle, Wartungsmeldungen, Abonnenten, signierte Webhooks, Domains und Assets besitzen eigene Operationen. Domainbindung benötigt DNS-Nachweis und HTTPS-Bereitstellung; Abonnements Bestätigung. Interne Adressen, Schlüssel, Logs oder Alarmtexte nicht veröffentlichen. Veröffentlichungs-/Domain-/Auftragsstatus und öffentliche URL erneut prüfen; Rücknahme ist erst nach Sperrung sämtlicher öffentlicher Artefakte abgeschlossen. [Statusseitenanleitung](https://metribeacon.com/de/documentation/app/status-pages). Für die HTTPS-Verwaltung ein kontoweites Verwaltungscredential mit passenden Konfigurationsrechten und Seitenrolle oder eine Browsersitzung mit Origin-/CSRF-Prüfung verwenden. Arbeitsbereichsgebundene Credentials können keine kontoweiten Seiten verwalten. Remote-MCP verwendet sein ressourcengebundenes OAuth-Token; dieses ersetzt kein API-Verwaltungscredential.

| Operation | Erforderlicher Scope |
| --- | --- |
| `get_status_pages` | `config:read` |
| `post_status_pages` | `config:write` |
| `put_status_pages_id_sources` | `config:write` |
| `post_status_pages_id_preview` | `config:write` |
| `post_status_pages_id_publish` | `config:write` |
| `post_status_pages_id_records` | `config:write` |
| `post_status_pages_id_domains_domain_verify` | `config:write` |
| `get_status_pages_id_subscribers` | `config:read` |
| `post_status_pages_id_withdraw` | `config:write` |

## 10. Fehler, Wiederholungen und Abschluss

API-Fehler verwenden `application/problem+json` mit `code`, Request-ID und häufig `Retry-After`. Bei 401/403 stoppen und Identität/Scope/Rolle korrigieren; Browser- oder E-Mail-Anforderungen nicht umgehen. Bei 409 Ressource/Version erneut lesen und Änderung prüfen. Bei 413/422 Payload/Validierung korrigieren. Bei 429/503 oder vorübergehendem Netzwerkfehler begrenzten Backoff verwenden und `Retry-After` beachten; Schreiben nur bei dokumentiertem Idempotenz-/Extern-ID-Vertrag wiederholen und Kennungen, Inhalt sowie Messzeiten erhalten. Bei verlorener Antwort auf nicht idempotente Aktionen vor weiterem Schreiben den Ausgang lesen. Ressourcen/Schlüssel nicht ständig neu erzeugen, um Grenzen zu umgehen.

Zum Abschluss angelegte/wiederverwendete Ressourcenkennungen, hilfreiche App-/öffentliche Links, beobachtete Ergebnisse und offene Schritte nennen. Credentials, Wiederherstellungsmaterial, E-Mail-Tokens oder Webhook-Secrets nicht berichten. Veröffentlichte Konfiguration und Benachrichtigungsempfänger müssen innerhalb der Nutzerfreigabe bleiben. Betreiberverwaltung gehört nicht zu dieser Anleitung. Für hier nicht gezeigte Nutzeroperationen vor Verwendung den aktuellen Vertrag in [Dokumentation](https://metribeacon.com/de/documentation), Monitoring-Katalog oder OpenAPI ermitteln.