Managed vs. Self-Service Monitors
Every monitor has an ownership class that controls who may edit it and who receives its alerts.
Every monitor — website, DNS, ICMP, SMTP, SSH, FTP, IMAP/POP, domain expiry, and DNSBL — carries an ownership class (managementType) with one of two values:
managed(default) — the organization runs the monitor on the customer's behalf. It is read-only in the customer portal; customers request edits through the change-request flow. Alerts follow the organization's full escalation setup, including org-level integrations (webhooks, OpsGenie, org SMTP).self_service— the customer owns the monitor. Customer users (includingreadonly-role portal logins) can create, edit, and delete their own self-service monitors, bounded by a package quota. Alerts go to the customer's recipients only — org-level integration channels are skipped.
Existing monitors were classified managed, so nothing changed for them until you explicitly flip a monitor.
Who can do what
| Action | Customer portal user | Organization admin |
|---|---|---|
| View a monitor | ✓ (own customer scope) | ✓ |
Edit/delete a self_service monitor | ✓ (own monitors) | ✓ |
Edit/delete a managed monitor | ✗ — unless the customer has the canEditManaged exception | ✓ |
| Create monitors | ✓ as self_service, if allowed and within quota | ✓ (any class) |
Change a monitor's class (managed ⇄ self_service) | ✗ — always organization-only | ✓ |
| Request a change / request managed status | ✓ (change request) | approves/rejects |
Customers can never grant themselves rights: a customer-scoped API caller's writes to permission fields are ignored server-side, and flipping the class of a monitor is rejected with 403 (managementTypeOrgOnly).
Permissions and inheritance
Self-service behavior is configured at two tiers with a null-means-inherit model:
- Package config (
PATCH /api/package-configs/:packageType) sets the defaults for every customer on the package:allowSelfService(defaultfalse) andmaxSelfServiceUrls(default0), plus the channel-permission defaultsenableEmailAlerts,enableSmsAlerts,enableWebhookAlerts,enableIntegrationAlerts,enablePostRequestEscalation. - Customer overrides (
POST/PATCH /api/customers) can set the same fields per customer.null(or omitting the field) means inherit from the package config. The per-customercanEditManagedflag additionally allows a specific customer to editmanagedmonitors without owning them.
Resolution is always: customer value → package default → platform default, and it fails closed (absence = least privilege).
The self-service quota
maxSelfServiceUrls bounds a customer's total number of self_service monitors across all monitor types — five self-service websites plus three self-service ICMP monitors count as eight. When the quota is reached, creating another self-service monitor (or flipping an existing monitor to self_service) fails with 403 (selfServiceQuotaReached).
Change requests
For managed monitors, the portal shows a Request change action instead of edit controls. A request has a kind:
change— free-text ask ("please raise the check interval").request_managed— the customer asks the organization to take over responsibility for a monitor. Accepting this request flips the monitor tomanagedautomatically.
Requests land in the organization's change-request inbox (Dashboard → Change Requests), where an org admin accepts or rejects them. Open requests are capped at 10 per customer. See the Change Requests API for the endpoints.
What this means for alert delivery
The ownership class drives escalation routing at the worker level:
managed— unchanged, full org escalation (org integrations + customer recipients per your escalation config).self_service— notifications are delivered to the customer's own recipients only. Organization-level integration channels (channels not bound to a customer or monitor) are skipped, so your ops tooling isn't paged for monitors a customer runs themselves.