---
title: "Managed vs. Self-Service Monitore"
description: "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:

1. **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`.
2. **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](/de/api/change-requests).

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