Managed vs. Self-Service Monitore

Jeder Monitor trägt eine Ownership-Klasse, die bestimmt, wer ihn bearbeiten darf und wer seine Alarme erhält.

Jeder Monitor — Website, DNS, ICMP, SMTP, SSH, FTP, IMAP/POP, Domain-Ablauf und DNSBL — trägt eine Ownership-Klasse (managementType) mit einem von zwei Werten:

managed (Standard) — die Organisation betreibt den Monitor im Auftrag des Kunden. Im Kundenportal ist er schreibgeschützt; Änderungswünsche laufen über den Change-Request-Flow. Alarme folgen der vollständigen Eskalation der Organisation, inklusive Org-Integrationen (Webhooks, OpsGenie, Org-SMTP).
self_service — der Kunde besitzt den Monitor. Kunden-Nutzer (auch Portal-Logins mit der Rolle readonly) können ihre eigenen Self-Service-Monitore anlegen, bearbeiten und löschen, begrenzt durch ein Paket-Kontingent. Alarme gehen ausschließlich an die Empfänger des Kunden — Org-Integrationskanäle werden übersprungen.

Bestehende Monitore wurden als managed klassifiziert — für sie ändert sich nichts, bis du einen Monitor explizit umstellst.

Wer darf was

Aktion	Kundenportal-Nutzer	Organisations-Admin
Monitor ansehen	✓ (eigener Kunden-Scope)	✓
`self_service`-Monitor bearbeiten/löschen	✓ (eigene Monitore)	✓
`managed`-Monitor bearbeiten/löschen	✗ — außer der Kunde hat die `canEditManaged`-Ausnahme	✓
Monitore anlegen	✓ als `self_service`, sofern erlaubt und im Kontingent	✓ (jede Klasse)
Klasse eines Monitors ändern (`managed` ⇄ `self_service`)	✗ — immer nur die Organisation	✓
Änderung anfragen / Managed-Status anfragen	✓ (Change Request)	genehmigt/lehnt ab

Kunden können sich niemals selbst Rechte einräumen: Schreibzugriffe eines kunden-gescopten API-Aufrufers auf Berechtigungsfelder werden serverseitig ignoriert, und das Umstellen der Klasse eines Monitors wird mit 403 (managementTypeOrgOnly) abgelehnt.

Berechtigungen und Vererbung

Self-Service-Verhalten wird auf zwei Ebenen konfiguriert, mit einem null-heißt-erben-Modell:

Paket-Konfiguration (PATCH /api/package-configs/:packageType) setzt die Standards für alle Kunden des Pakets: allowSelfService (Standard false) und maxSelfServiceUrls (Standard 0), dazu die Kanal-Berechtigungsstandards enableEmailAlerts, enableSmsAlerts, enableWebhookAlerts, enableIntegrationAlerts, enablePostRequestEscalation.
Kunden-Overrides (POST/PATCH /api/customers) können dieselben Felder pro Kunde setzen. null (oder das Weglassen des Felds) bedeutet vom Paket erben. Das per-Kunde-Flag canEditManaged erlaubt einem bestimmten Kunden zusätzlich, managed-Monitore zu bearbeiten, ohne sie zu besitzen.

Die Auflösung ist immer: Kundenwert → Paket-Standard → Plattform-Standard, und sie fällt geschlossen aus (Abwesenheit = geringste Berechtigung).

Das Self-Service-Kontingent

maxSelfServiceUrls begrenzt die Gesamtzahl der self_service-Monitore eines Kunden über alle Monitor-Typen hinweg — fünf Self-Service-Websites plus drei Self-Service-ICMP-Monitore zählen als acht. Ist das Kontingent erreicht, schlägt das Anlegen eines weiteren Self-Service-Monitors (oder das Umstellen eines bestehenden Monitors auf self_service) mit 403 (selfServiceQuotaReached) fehl.

Change Requests

Bei managed-Monitoren zeigt das Portal statt Bearbeitungs-Controls eine Änderung anfragen-Aktion. Eine Anfrage hat einen kind:

change — Freitext-Wunsch („bitte das Check-Intervall erhöhen").
request_managed — der Kunde bittet die Organisation, die Verantwortung für einen Monitor zu übernehmen. Das Annehmen dieser Anfrage stellt den Monitor automatisch auf managed um.

Anfragen landen im Change-Request-Posteingang der Organisation (Dashboard → Change Requests), wo ein Org-Admin sie annimmt oder ablehnt. Offene Anfragen sind auf 10 pro Kunde begrenzt. Die Endpunkte beschreibt die Change-Requests-API.

Was das für die Alarm-Zustellung bedeutet

Die Ownership-Klasse steuert das Eskalations-Routing auf Worker-Ebene:

managed — unverändert, volle Org-Eskalation (Org-Integrationen + Kunden-Empfänger gemäß deiner Eskalations-Konfiguration).
self_service — Benachrichtigungen gehen ausschließlich an die eigenen Empfänger des Kunden. Organisationsweite Integrationskanäle (Kanäle ohne Kunden- oder Monitor-Bindung) werden übersprungen — dein Ops-Tooling wird nicht für Monitore alarmiert, die ein Kunde selbst betreibt.