API

Monitor API workflows

Create and maintain checks with explicit, reviewable requests.

List and inspect

GET /monitors returns the accessible monitor array. GET /monitors/{monitor_id} returns one monitor. Use /stats?range=7d for history and /details for the latest regional details.

Create a website monitor

The following example creates a real monitor when run with a write key. Confirm the target is yours to monitor. The five-minute interval avoids assuming a one-minute entitlement. Optional placement selects available regions; omit it to use the server’s default placement.

Example
curl --fail-with-body -X POST "https://uptiva.linuxmaster.cloud/api/monitors" \
  -H "Authorization: Bearer $UPTIVA_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{"type":"website","name":"Public website","target":"https://example.com","interval":"5m","alert_after":2}'

The required base fields are name and target. Type-specific validation still applies. Use GET /regions before specifying placement. The MonitorIn schema describes all fields, limits and defaults.

Update with care

PUT /monitors/{monitor_id} accepts the monitor input shape, including required fields. It is not a partial PATCH. Read the current settings, build the intended request and preserve the values you still need. Do not blindly copy response-only fields or masked credentials into a write payload.

Pause or resume

Example
curl --fail-with-body -X PUT "https://uptiva.linuxmaster.cloud/api/monitors/MONITOR_ID/paused" \
  -H "Authorization: Bearer $UPTIVA_API_KEY" \
  -H "Content-Type: application/json" \
  --data '{"paused":true}'

Use false to resume. A successful pause update returns 204 without a JSON response body. Resuming can be refused when the account is over its current allowance.

Groups, cloning and templates

List groups with GET /groups and create one with POST /groups. Move a monitor through its /group operation. Cloning creates another monitor and consumes available capacity; templates are managed through /monitor-templates. Consult the request schema for each operation instead of reusing a monitor input everywhere.

Delete deliberately

DELETE /monitors/{monitor_id} returns 204 on success. Deletion is a destructive operation: verify the identifier and the intended account before calling it. Do not automatically retry a creation or deletion after an uncertain network response without first checking the current state.

Type-specific behavior

SSL, domain, DNS, heartbeat and log monitors have different schedules and input rules. Read the monitor-type guides before constructing their requests. Host metrics and log ingestion are separate from ordinary API-key monitor management.