Monitors

Monitors

Monitors run HTTP, HTTPS, TCP, UDP, or PING checks from the current Helsinki, Finland probe. Each Monitor belongs to a workspace and owning team and may create an implicit incident trigger for down and recovery transitions. The current service does not provide geographically independent probes.

Create a Monitor

Choose a type and target, then set the interval, timeout, retries, the Helsinki probe, owning team or service, and whether to create an incident trigger. HTTP and HTTPS checks also accept method, headers, body, expected status codes, expected response text, and expected headers.

Use the authenticated POST /organizations/:organization_id/checks endpoint or the matching dashboard form. Notification channels are configured on the incident trigger and currently support email, SMS, and voice.

Execution and state

The scheduler atomically claims due Monitor work and the Helsinki worker records each execution with an idempotency key. Fresh results update the aggregate Monitor state; stale results cannot overwrite a newer state. Configure retries only with a retry interval of at least one second.

Verify a controlled failure and recovery from Helsinki before relying on a Monitor in production. Additional regions will be listed only after workers are deployed to separate hosts in those locations.

HTTPS certificate validation

HTTPS checks verify the peer certificate and hostname during the connection. MonoDuty does not currently store certificate metadata, track expiry dates, or send certificate-expiry warnings. Use a dedicated certificate inventory or expiry monitor if you need that capability.