---
title: "Managed vs. Self-Service Monitors"
description: "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 (including `readonly`-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:

1. **Package config** (`PATCH /api/package-configs/:packageType`) sets the defaults for every customer on the package: `allowSelfService` (default `false`) and `maxSelfServiceUrls` (default `0`), plus the channel-permission defaults `enableEmailAlerts`, `enableSmsAlerts`, `enableWebhookAlerts`, `enableIntegrationAlerts`, `enablePostRequestEscalation`.
2. **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-customer `canEditManaged` flag additionally allows a specific customer to edit `managed` monitors 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 to `managed` automatically.

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](/api/change-requests) 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.