Uptimerobot Management

UptimeRobot Management

Operate UptimeRobot from evidence, keep credentials out of output, and make every mutation deliberate and reviewable.

Choose the interface

• Prefer the official UptimeRobot CLI for routine monitor, incident, group, maintenance-window, alert-contact, integration, tag, and status-page work. It provides schemas, redaction, structured output, dry runs, and delete confirmations.
• Prefer the official remote MCP server at https://mcp.uptimerobot.com/mcp when an MCP-capable client is already connected. Use OAuth when practical; use an API key only when OAuth is unavailable.
• Use scripts/manage_uptimerobot.py for credential-safe context checks, current OpenAPI operation discovery, repeatable request previews, constrained API escape hatches, or bounded cursor pagination.
• Use the dashboard for visual confirmation, OAuth setup, policy/account settings not exposed by the other interfaces, and final human review. Do not infer hidden state from a screenshot.

Read references/command-guide.md for exact commands and references/api-reference.md for API, authentication, pagination, rate-limit, and redaction details.

Establish context

1. Identify the intended account, monitor or resource IDs, environment, and time range. Do not assume similarly named monitors are interchangeable.
2. Run python scripts/manage_uptimerobot.py context. Report credential presence and source names only, never values.
3. For read-only work, prefer UPTIMEROBOT_READ_ONLY_API_KEY. Fall back to UPTIMEROBOT_API_KEY only when necessary.
4. For mutations, require the main account key in UPTIMEROBOT_API_KEY or an OAuth-authorized MCP session. A monitor-specific or read-only key is insufficient.
5. Keep both configured helper credentials exclusive to the generated Authorization header. Credential values must contain at least eight characters. Reject either active value at semantic boundaries in request paths, queries, or bodies even when percent-encoded, form-encoded, or repeatedly encoded.
6. Confirm whether the user asked for inspection, a proposed change, or execution. Inspection never implies mutation.

Inspect before changing

1. Capture the target resource and its current state with normalized JSON.
2. Correlate monitor status with incidents, response-time or uptime statistics, maintenance windows, alert contacts, integrations, and status-page visibility as relevant.
3. Distinguish an active outage from a paused monitor, scheduled maintenance, notification delivery failure, stale status-page data, or a monitor configuration defect.
4. Record IDs, status, timestamps, affected destinations, filters, pagination bounds, and source interface. Redact credential-like monitor fields, heartbeat url/pingUrl capability URLs, webhook destinations, integration capability values, cookies, passphrases/private keys, configured POST values, and nested request/response headers. Preserve ordinary monitor URLs and non-secret values.
5. If a result is paginated, follow only validated same-origin cursors that retain the exact normalized collection endpoint path, preserve repeated filter pairs, reject malformed or repeated links, and state the page and byte caps used.

Apply safe mutations

1. Restate the exact resource, requested end state, user-visible impact, and rollback or compensating action.
2. Preview first. Use CLI --dry-run where supported, omit helper --send, or present the MCP tool arguments before invoking a mutating tool.
3. Obtain explicit authorization for the specific mutation when the current request does not already authorize it. Treat delete, bulk pause/start/update, incident publication, integration changes, status-page publication, and credential-bearing monitor edits as high impact. The helper additionally requires its reported exact --confirm value for deletes and bulk monitor operations; that value binds the operation ID when available, method, normalized path, encoded query, and canonical JSON body digest.
4. Execute once. Do not automatically retry a mutation after a timeout, transport loss, transient server failure, or response-consumption failure. Treat write-side HTTP 500, 502, 503, and 504, transport loss, and any post-attempt response read/size/UTF-8/strict-JSON failure as indeterminate: the mutation may have succeeded, so re-read the exact target before any manual retry. Treat a successfully consumed definitive 4xx, including 429, as definitive.
5. Re-read the resource and adjacent state. Verify the intended fields, monitor runtime status, incident/status-page effect, and notification routing rather than trusting only the write response.
6. Report the before/after state, interface used, verification evidence, and any unresolved warnings.

Triage common requests

Monitor outage or flapping

Inspect the monitor, current and recent incidents, activity/alerts, response-time and uptime statistics, maintenance overlap, and relevant integrations. Do not reset statistics or pause the monitor merely to clear a noisy dashboard.

Monitor creation or update

Use uptimerobot monitors schema <type> before authoring a request. Confirm URL/host, interval, timeout, regions, HTTP method, expected status, keyword/JSON checks, authentication, SSL behavior, alert contacts, group, and tags. Keep secrets in supported secret inputs or environment variables and verify with a follow-up get while retaining default redaction.

Integrations and alert contacts

Inventory both resources and map which monitors or account policies use them. Test or replace routing deliberately; deleting an integration or contact can silently reduce outage notification coverage.

Maintenance windows

Check timezone, recurrence, scope, start/end, and overlap. Verify affected monitors after creation or update. Do not use maintenance windows as a permanent suppression mechanism.

Public status pages and incidents

Separate internal monitor state from public communication. Review page monitors, visibility, custom domain, subscriber behavior, active incidents, announcements, and pinned content. Publishing or resolving a public incident is an external communication and requires explicit intent.

Bulk operations

Resolve the exact group/tag filters and enumerate the projected monitor set before a bulk pause, start, or update. Set an explicit safety bound and verify every per-monitor result.

MCP rules

• Configure https://mcp.uptimerobot.com/mcp as a streamable HTTP server and prefer OAuth authorization.
• Treat MCP and API/CLI calls as sharing the account quota.
• Keep a read-only API key read-only; do not replace it with the main key merely to make a mutation succeed.
• OAuth client revocation may require UptimeRobot support. Disconnecting a client locally or rotating an API key does not necessarily revoke an OAuth grant.
• Apply the same preview, authorization, single-write, and post-write verification rules to MCP tools.

Output contract

Return:

• account/resource scope and interface used;
• findings with IDs, status, timestamps, and filters;
• redacted preview for proposed mutations;
• execution and post-write verification evidence when authorized;
• pagination/rate-limit bounds and any incomplete coverage;
• risks, rollback guidance, and next actions.

Never print API keys, authorization headers, monitor passwords, custom HTTP headers, cookies, heartbeat or known-provider path-token webhook capability URLs, integration values, configured POST values, passphrases/private keys, configured credential values or their encoded forms, or other credential-like values. Repeatedly decode structured key names before classifying them. Keep ordinary monitor URLs—including generic /hooks/status paths on ordinary hosts—and non-secret fields visible so findings remain useful.