Skip to main content

Monitors

Monitors are the foundation of Sentro. Each monitor periodically checks a target and records whether it is reachable and responding correctly. When a check fails, Sentro creates an incident and notifies your team through your configured alert channels.

Monitor types​

HTTP​

The most common monitor type. Sentro sends an HTTP request to your URL and verifies the response.

What you can configure:

  • URL -- Any https:// or http:// endpoint.
  • Method -- GET, HEAD, or POST.
  • Expected status code -- The HTTP status code that means "healthy" (default: 200).
  • Follow redirects -- Whether to follow 3xx redirects or treat them as failures.
  • Custom headers -- Add headers like Authorization, Accept, or custom tokens.
  • Keyword matching -- Require that the response body contains (or does not contain) a specific string. Useful for detecting soft failures where the server returns 200 but the page shows an error.
  • Degraded threshold -- A latency threshold in milliseconds. If the response is slower than this, the monitor is marked as "degraded" rather than "down", giving you an early warning.
  • Confirmations -- How many checks in a row must agree before Sentro records an outage or a recovery (default: 2, range 1--10). See Confirming a state change.

SSL certificate monitoring: Sentro automatically checks the SSL certificate of every HTTPS monitor. You can configure how many days before expiry you want to be alerted (default: 14 days). An SSL_EXPIRING alert rule notifies you before certificates expire.

Domain expiry monitoring: Sentro checks domain registration expiry via RDAP. Configure the alert window (default: 30 days) and create a DOMAIN_EXPIRING alert rule to get notified.

TCP​

Checks whether a specific port on a host is open and accepting TCP connections. Use this for databases, mail servers, game servers, or any service that does not speak HTTP.

What you can configure:

  • Hostname or IP -- The server to connect to.
  • Port -- The TCP port to check (1-65535).
  • Timeout -- How long to wait for a connection (default: 30 seconds).

PING​

Sends an ICMP echo request to test network reachability. Use this for servers, network devices, or infrastructure where you only need to know "is it reachable?"

What you can configure:

  • Hostname or IP -- The target to ping.
  • Timeout -- How long to wait for a reply (default: 30 seconds).

DNS​

Verifies that a domain name resolves to the expected value. Use this to detect DNS hijacking, propagation issues, or misconfigurations.

What you can configure:

  • Domain -- The domain to query.
  • Record type -- A, AAAA, CNAME, MX, TXT, or NS.
  • Expected value -- The value you expect the record to resolve to. If the actual value does not match, the check fails.

Check intervals​

How often Sentro checks your monitors depends on your plan:

PlanMinimum interval
Free3 minutes (180s)
Starter1 minute (60s)
Pro30 seconds
Max10 seconds

You can set any interval at or above your plan minimum. For example, on the Pro plan you could check a critical API every 30 seconds and a marketing site every 5 minutes.

Confirming a state change​

A request lost on its way across the public internet looks exactly like an outage at the moment it happens. Acting on a single check therefore produces outages that never existed -- and, one check later, a recovery from them.

Every monitor has a confirmations setting: how many checks in a row must agree before Sentro records a change. The default is 2.

SettingBehaviour
1Maximum sensitivity. Any single failed check opens an incident. Use only where a lost request is itself worth waking someone for.
2 (default)Filters isolated transport failures. Detection is delayed by at most one check interval.
3--10Conservative. For services with known instability, or where a false alarm is costly relative to the added delay.

Confirmation applies in both directions: an incident opens once the failures are confirmed, and closes once the recovery is. What it does not do is distort the record. An outage is recorded as starting at the first failed check and ending at the first check that answered normally, so waiting for confirmation never adds or removes downtime from your uptime figures.

Isolated failures still count against uptime and still appear in your check history. Confirmation decides when something is called an outage -- not whether it happened.

Monitor statuses​

Each monitor has a status that reflects its current state:

StatusMeaning
UPThe monitor is answering normally.
DOWNFailures have been confirmed and an active incident exists.
DEGRADEDThe monitor answers, but slower than the degraded threshold.
PAUSEDMonitoring is paused. No checks are being performed.

A failed check that has not yet been confirmed leaves the status unchanged. It is visible in the monitor's own check history, where you can see the raw result of every check.

Monitor groups​

Organize monitors into groups for easier management. Groups are color-coded (cyan, green, blue, purple, pink, orange, yellow, red) and can be sorted in any order. You can create up to 20 groups per organization.

Groups are purely organizational -- they do not affect how monitors are checked or how alerts are routed.

Check history and statistics​

Every check is recorded with:

  • Status code (HTTP monitors)
  • Latency in milliseconds
  • Whether the check passed or failed
  • Error details if the check failed
  • Timestamp

Sentro aggregates checks into daily statistics:

  • Uptime percentage -- The ratio of successful checks to total checks.
  • Average latency -- Mean response time across all checks that day.
  • Min/max latency -- The fastest and slowest responses.
  • Total checks and successful checks count.

Monitor limits​

The number of monitors you can create depends on your plan:

PlanMonitor limit
Free5
Starter25
Pro100
MaxUnlimited

Common scenarios​

Monitor a website​

Create an HTTP monitor with your homepage URL. Set the expected status code to 200 and optionally add a keyword check for a string that should always appear on the page (like your company name).

Monitor an API health endpoint​

Most APIs expose a /health or /status endpoint. Create an HTTP monitor pointing to it. If your health endpoint returns JSON, use keyword matching to verify the response contains "status":"ok" or similar.

Monitor a database​

Create a TCP monitor pointed at your database host and port (e.g., db.example.com:5432 for PostgreSQL). This verifies the database is accepting connections without requiring credentials.

Detect slow responses before outages​

Set a degraded threshold on your HTTP monitor. For example, if your API normally responds in 200ms, set the threshold to 2000ms. When response times cross this threshold, Sentro marks the monitor as degraded and you can create a DEGRADED alert rule to get notified before a full outage occurs.

Monitor SSL certificate expiry​

Every HTTPS monitor automatically tracks SSL certificate expiry. Create an alert rule with the SSL_EXPIRING trigger and set the alert window to however many days of lead time you want (e.g., 14 or 30 days).