Modify, pause, resume, and delete a Monitor
Modify Monitor configuration safely, preserve hidden values, and understand how pause, resume, and soft-delete affect Checks, Incidents, evidence, and free-beta slots.
A Workspace Owner or Admin can modify, pause, resume, or delete a Monitor. A Member can view its safe operational data and run Manual Checks but cannot change its configuration or lifecycle. See the Workspace role permissions.
Modify a Monitor safely
Each availability-affecting change creates a new immutable Monitor Revision. An active Monitor returns to Pending, and an immediate Scheduled Check begins evidence for that Revision.
Availability-affecting settings are the Endpoint, method, accepted statuses, timeout, headers, body, and repeat-safety acknowledgement. Changing one resets the confirmation sequence. If an Incident is open, PointWarden ends it as superseded without creating a Recovery Notification Event; its retained history remains available.
A name change, schedule change, or Notifier subscription change updates future product behavior without creating a Monitor Revision. A schedule change starts a new regular schedule but does not reset the current Availability observation.
Expected-revision protection rejects a stale modification instead of overwriting newer configuration.
When this happens, reload the management page, review the latest Monitor Revision and lifecycle state, then apply your intended change again.
Preserve hidden configuration
Unchanged saved query values, header values, and request bodies continue into the new Monitor Revision without being disclosed to the browser.
- Leave New Endpoint URL (optional) blank to keep the complete saved Endpoint, including its encrypted query. Entering a URL replaces the complete value.
- Saved header names appear only on the management page so you can identify them; their values remain encrypted. New header rows keep the saved set unless you select Replace all saved headers.
- A blank POST or PUT body keeps an existing encrypted body. Select Remove the saved request body to remove it explicitly.
Review advanced configuration for validation limits and the Endpoint projection shown outside this management flow.
Pause, resume, and soft-delete
| Action | Checks and Incidents | Retained history | Free-beta slots |
|---|---|---|---|
| Pause | Stops Scheduled Checks and ends an open Incident without Recovery | Keeps retained Check Evidence and Incident history | Uses one saved slot but no active slot |
| Resume | Keeps the current Monitor Revision and starts an immediate Scheduled Check | Returns to Pending | Uses one saved slot and one active slot |
| Delete | Soft-deletes the Monitor, stops Checks, and ends an open Incident without Recovery | Keeps retained Check Evidence, Monitor Revisions, and Incident history | Uses no saved or active slot |
Pause
Pausing cancels pending Scheduled Check work, stops the regular schedule, and changes the Monitor to Paused. PointWarden makes no current Availability claim. An open Incident ends because monitoring stopped, not because Recovery was observed, so no Recovery Notification Event is created.
Resume
Resuming is allowed only when the Workspace remains within its five active Monitor limit. It keeps the current Monitor Revision, changes the Monitor to Pending, and starts immediate and regular Scheduled Check work. Previous Incidents stay closed; new evidence establishes the next Availability observation.
Delete
Deletion is a soft-delete. The Monitor disappears from normal Monitor views and cannot run Checks. An open Incident ends because the Monitor was deleted, without a Recovery Notification Event. Existing Check Evidence, Monitor Revisions, and Incident history remain subject to their normal retention instead of being rewritten as Recovery.
During the free beta, a Workspace may save up to 10 Monitors and keep up to five active. A Paused Monitor still uses a saved slot; a Deleted Monitor uses neither. See the free-beta limits.
Read the result
Use Check types to understand which evidence can change state, Availability and Coverage to interpret Pending or missing evidence, and the Incident and Recovery sequence to distinguish lifecycle endings from confirmed Recovery.
If a resumed Monitor remains Pending, start with troubleshoot persistent Pending. If current evidence later becomes stale, follow the freshness-warning path.