Website Monitoring

Website monitors don't require an agent — they're checks MonSPHERE performs directly against a target URL or host, from one or more regions, on a schedule you define.

Monitor types

Looking to monitor a cron job or background worker instead of a URL? See Cron Job Monitoring — a completely different, inbound check model.

Creating a monitor

curl -X POST https://api.monsphere.com/api/v1/monitors \
  -H "X-Api-Key: msk_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Marketing Site",
    "type": "https",
    "target": "https://monsphere.com",
    "intervalSeconds": 60
  }'

Status lifecycle

A monitor has a status (active/paused, whether it's currently being checked) and a currentStatus (pending/up/down, the result of the most recent check). A monitor transitioning to down is what alert rules evaluate against.

Multi-region probing

Every check runs from one or more independent probe regions you pick when creating (or later editing) a monitor — a monitor is only reported down once every region assigned to it agrees it's down, so a single region's own network hiccup never fires a false alert. Leaving no region selected checks nothing; there's no silent "all regions" fallback, so region assignment is always explicit and visible on the monitor itself.

HTTP/HTTPS assertions

Every http/https monitor gets, at no extra cost:

• Expected status code(s) — beyond the default "any 2xx"
• A required keyword — the response body must contain it
• HTTP Basic Auth credentials (stored encrypted, never returned by the API)
• Custom request method (GET by default)
• SSL certificate verification toggle, for internal/self-signed endpoints

Advanced HTTP Monitoring goes further:

• Regex assertions — treat the keyword (and its inverse below) as a real regular expression instead of a literal substring, for content checks a plain keyword can't express
• Forbidden keyword — fail the check if the response body does contain a given string or pattern (an error banner, a maintenance page, a stack trace) instead of only checking for something's presence
• Custom request headers and body — send an Authorization header, an API key, or a JSON payload with every probe, so you can monitor an authenticated API endpoint the same way as a public page

curl -X POST https://api.monsphere.com/api/v1/organizations/{orgId}/monitors \
  -H "X-Api-Key: msk_live_..." -H "Content-Type: application/json" \
  -d '{
    "name": "Orders API",
    "type": "https",
    "target": "https://api.example.com/health",
    "intervalSeconds": 60,
    "config": { "keyword": "^\\{\"status\":\"ok\"", "keywordIsRegex": true, "forbiddenKeyword": "\"degraded\"" },
    "requestHeaders": { "Authorization": "Bearer ..." }
  }'

Availability of Advanced HTTP Monitoring depends on your plan — check Settings > Plan, or ask your organization's Owner.

TCP monitoring

The default tcp check confirms a connection opens on the given host/port — enough to catch a service that's completely down, but not one that's up and refusing to answer correctly.

Advanced TCP Monitoring adds:

• TCP-over-TLS — probe a TLS-wrapped port (SMTPS, a bare TLS service with no HTTP on it) directly, with an optional "skip certificate verification" toggle for internal/self-signed services
• Query/response validation — send a fixed payload after connecting and require a matching reply (plain text or regex) before the check passes, e.g. send PING and require PONG, or send a protocol-specific greeting and check the service's real banner — confirming the service actually answers correctly, not just that the port is open

Availability of Advanced TCP Monitoring depends on your plan — check Settings > Plan, or ask your organization's Owner.

DNS monitoring

Beyond resolving successfully, a dns monitor can specify a record type (A, AAAA, CNAME, MX, TXT, ...) and one or more expected values — the check fails if the domain resolves to anything other than the values you listed, catching a hijacked or silently changed record rather than just a resolution failure.

SSL expiry monitoring

ssl-type monitors track certificate expiry independently of uptime — you can be alerted 30, 14, or 7 days before a certificate expires, before it ever causes an outage.