Documentation

Appearance

Service monitors #

Use a service monitor when the failure exists outside one device. Dataplicity monitors HTTP endpoints, CORS baselines, DNS records, and heartbeats.

Monitor an HTTP endpoint #

Prerequisites are an absolute HTTP or HTTPS URL reachable from Dataplicity and permission to manage monitors.

  1. Open Service endpoints, choose Endpoint, and add a monitor.
  2. Enter a concise label and URL.
  3. Optionally add one header in Name: Value form. Treat its value as a secret and use a narrowly scoped credential.
  4. Keep status 200, or add accepted codes such as 204.
  5. Optionally require a response-body substring such as ready.
  6. Save, wait for a result, and inspect HTTP status, response time, checked time, and error.

Endpoint checks are dispatched by a global scheduler and are also subject to the organisation's minimum monitor interval. The effective cadence can therefore be slower than a stored interval. Disabling a monitor stops polling. Hiding it from a status page does not.

Detect CORS drift #

A CORS monitor checks a domain and path, captures expected response headers, and compares later responses with the confirmed baseline.

  1. Choose CORS, enter the domain and an optional path.
  2. Run the baseline preview.
  3. Review and confirm the expected headers.
  4. Save and test against a non-production target.

Changing the domain or path invalidates the old baseline. Reconfirm only after verifying that a changed policy is intentional. CORS checks use warning severity.

Monitor DNS records #

DNS monitors expand a base domain and optional prefixes, then evaluate A, AAAA, CNAME, NS, or TXT records.

Current Service Endpoint Monitors DNS view with a healthy fleet.example.test delegation baseline
DNS monitors compare current delegation with a configured baseline.

Choose a comparison mode that reflects the provider:

  • Pinned answers requires exact values.
  • Rotating pool requires overlap with the expected answer set.
  • Managed edge tolerates dynamic provider pools.

Rules can require exact values, overlap, non-empty answers, required or forbidden text, regular-expression matches, or answer-count bounds. DNS caching, TTLs, resolver differences, and staged propagation can produce temporary differences. Preview from more than one resolver before accepting a new baseline.

Monitor scheduled work #

A heartbeat has a private ping URL and one of four intervals: 1, 5, 15, or 60 minutes. Call the URL only after successful work:

sh
curl --fail --silent --show-error "$DATAPLICITY_HEARTBEAT_URL"

The displayed state progresses through up, degraded, failed, and down as pings become late. Protect the URL and regenerate it if exposed.

Troubleshooting #

  • No HTTP result: confirm public reachability, TLS validity, and header format.
  • Unexpected body failure: matching is a substring check, so verify casing and actual response body.
  • CORS drift: compare each captured header before re-baselining.
  • DNS drift: choose a mode appropriate to static or dynamic answers.
  • Late heartbeat: confirm the job calls the URL only on success and uses the intended interval.