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: msph_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
• Response header assertions — require a header to contain a text or match a regex (Content-Type contains application/json), or forbid one. A "contains"/"matches" assertion fails when the header is missing; the "must not" forms pass when it is
• JSON body assertions — test a value inside a JSON response by path: data.status equals ok, data.items[0].price greater than 0. Operators: equals, not equals, contains, exists, greater than, less than. Use [*] once in a path to test the items of an array (items[*].status) and choose whether any item or every item must match. Values are typed by how they look — true/false, null, a number, otherwise text; wrap in double quotes to force text. JSON assertions can't be combined with the keyword fields on the same monitor
• Diagnostic check — when an advanced monitor fails, the dashboard shows which assertion broke: the reason each probe location reported, every assertion evaluated separately, the response headers and the first 2 KB of the body. One is captured automatically when the monitor goes down, you can run one on demand, and past runs are kept for your plan's retention period

curl -X POST https://api.monsphere.com/api/v1/organizations/{orgId}/monitors \
  -H "X-Api-Key: msph_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 ..." }
  }'

The same endpoint checked with header and JSON assertions instead of keywords:

"config": {
  "headerAssertions": [{ "header": "Content-Type", "value": "application/json" }],
  "jsonAssertions": [
    { "path": "status", "operator": "equals", "value": "ok" },
    { "path": "services[*].healthy", "operator": "equals", "value": "true", "quantifier": "all" }
  ]
}

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
• Banner capture — record the service's reply line (an SSH or SMTP greeting with its version) and see on the dashboard when it changes. Only for services that speak first or answer your send text; a port that stays silent, like HTTP, would time out

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.