---
title: "Change Requests"
description: "How customers request changes to managed monitors and how organizations resolve them."
---

Monitors with `managementType: managed` are read-only for customer-scoped users (see [Managed vs. Self-Service Monitors](/monitoring/managed-vs-self-service)). Instead of editing directly, a customer opens a **change request** against the monitor; the organization reviews it in its inbox and accepts or rejects it.

A change request has a `kind`:

| Kind | Meaning | Effect on accept |
|---|---|---|
| `change` | Free-text change wish for a managed monitor | None automatic: the org applies the change manually |
| `request_managed` | The customer asks the org to take over responsibility for a monitor | The monitor is flipped to `managed` automatically |

Endpoints:

- [Create Change Request](/api/change-requests/create-change-request): `POST /api/monitors/:monitorType/:monitorId/change-requests` (customer or org)
- [List Change Requests](/api/change-requests/list-change-requests): `GET /api/change-requests` (org admins)
- [Resolve Change Request](/api/change-requests/resolve-change-request): `PATCH /api/change-requests/:id` (org admins)

Open requests are limited to **10 per customer** across all monitor types; further creates return `429` (`tooManyOpenRequests`).