How Monitoring Works

Understand the check cycle, monitor types, confirmation counts, and state transitions that power Signalog's monitoring engine.

The check cycle

Signalog runs checks on a configurable interval — from 30 seconds to 15 minutes. A scheduler dispatches checks at the configured interval for each monitor. Checks run from multiple regions simultaneously when multi-region is enabled, and results are aggregated to determine the monitor’s state.

Each check produces a result containing the status code, response time, region, timestamp, and whether it passed or failed.

Monitor types

HTTP monitors

The most common type. Signalog sends an HTTP request to your endpoint and evaluates the response.

A check passes when all of the following are true:

  • The response status code matches the expected code (default: 200).
  • The response arrives within the timeout period (default: 30 seconds).
  • If keyword monitoring is enabled, the response body contains (or excludes) the specified string.
  • If contract validation is enabled, the response body matches the expected schema.

SSL certificate monitors

SSL monitors track your certificate’s expiration date. Signalog connects to the host, reads the TLS certificate, and records the number of days until expiry.

You configure alert thresholds — for example, alert when the certificate expires in fewer than 30 days, then again at 14 days and 7 days. This gives you time to renew before visitors see browser warnings.

Heartbeat monitors

Heartbeat monitors work in reverse — instead of Signalog pinging your service, your service pings Signalog. Each heartbeat monitor has a unique token-based URL.

Configure the expected interval (e.g., every 5 minutes). If Signalog doesn’t receive a ping within the grace period, the monitor transitions to Down. This is ideal for cron jobs, background workers, and batch processes that run on a schedule.

# Ping from your cron job
curl -s https://hb.signalog.dev/ping/YOUR_HEARTBEAT_TOKEN

Synthetic monitors

Multi-step checks that simulate user workflows. See the synthetic checks guide for details.

Confirmation count

The confirmation count prevents false positives from transient network issues. When a check fails, Signalog does not immediately change the monitor state. Instead, it runs additional confirmation checks.

  • Confirmation count of 1 — Alert on the first failure (no re-check).
  • Confirmation count of 2 — Re-check once. Alert only if both checks fail.
  • Confirmation count of 3 — Re-check twice. Alert only if all three fail.

Confirmation checks run immediately (not on the regular interval), so there’s minimal delay in detecting real outages.

State transitions

Every monitor is in one of three states:

  • Up — Checks are passing. The service is healthy.
  • Down — Checks are failing consistently (past the confirmation count). Alerts have been triggered.
  • Degraded — Checks are passing but response times are abnormally high (when anomaly detection is enabled).

State transitions (e.g., Up to Down, Down to Up) trigger alert notifications and, if configured, automatic incident creation. Each state change is recorded with a timestamp, creating a complete history of your service’s availability.

The transition from Down back to Up (recovery) also triggers a notification, so your team knows the issue is resolved.

Next steps