Monitors

A monitor is one thing we check on a schedule from outside your infrastructure. Each one appears on your public page as a service with its own current state and its own uptime history, and when it fails your team is told before your customers are.

Dashboard → Monitors. The screen lists every monitor with its current state, its response-time trend and the allowance active for this account.

Key features

• Website, TCP, DNS, ping, mail-server and WebSocket checks. Cron-job heartbeat monitors remain in development preview and are disabled in production.
• Checks every 1, 2, 3, 4 or 5 minutes, with the first check within a minute of saving.
• Assertions on status code, body text and JSON fields, so a 200 with an error inside still counts as down.
• Grouping and ordering for the public page.
• Certificate-expiry warnings for encrypted targets. Domain-registration warnings require a separately enabled rollout.
• Automatic incidents, opt-in per monitor, in every language you use.

Adding a monitor

Account owners and admins can read and change stored destinations, credentials, and request assertions. Operators can edit an existing monitor's name, group, check interval, and automatic incidents, or pause and resume it. Those edits preserve its request settings. Viewers have read-only access to safe details. Public status responses do not include monitor destinations.

Dashboard → Monitors → Add monitor. This is the form you get. It is live: switch the kind and the fields change with it.

What are we watching?

Kind	What it does	Use it for
Website	Fetches an https:// or http:// URL and judges the response.	Sites, APIs, health endpoints.
A port	Opens a TCP connection to a host and port. Nothing is sent or read; the check passes if the connection is accepted.	Databases, message brokers, SSH, mail submission.
A DNS record	Resolves a name and, optionally, checks the answer.	Confirming a record still exists and still points where you think.
Ping	Sends an ICMP echo and waits for the reply.	A router, a gateway, an appliance — anything with no service to connect to.
A mail server	Greets the server and reads its reply. Nothing is sent and no mailbox is touched.	Mail that leaves your product: receipts, resets, alerts.
A WebSocket	Opens a socket and checks the upgrade is accepted.	Live feeds, chat, dashboards — anything a page holds open.
A cron job	Waits for your job to call a private URL. A missed check-in is the failure.	Backups, nightly imports, queue workers, anything scheduled.

Name

Taken from the address unless you type one. This is what your status page calls the service, so write it the way a customer would say it. The name is set per language; the other languages are filled in for you and stay editable (see Languages).

From the name in your default language we derive a slug: Checkout API becomes checkout-api. That is the stable identifier the badge, the widget, the feed's service filter and both APIs use.

Check interval

How often the address is checked, per monitor, so the endpoint that matters can be checked harder than the marketing site. The choices are 1, 2, 3, 4 or 5 minutes. New monitors default to 5 minutes. The faster cadences come with Monitoring and automatic detection, and the selector marks the ones this account does not include rather than hiding them.

Group

Optional. Type a group name, or pick one you already use. Monitors in the same group appear on the public page under one heading that visitors can collapse, and the heading shows the worst state inside it, so a group with one service down reads as a group with a problem. Leave it empty and the service sits at the top level.

Automatic incidents

Off by default. Turn it on and an incident is published to your page when this monitor stays down for 15 minutes, and resolved again when it recovers. The details, and the reasons for the delay, are in Incidents.

Website monitors

The URL may be https:// or http://. Plain http:// is there because a great many internal tools and staging hosts speak nothing else, and a check you cannot create is a check nobody has. It comes with one rule: a plain http:// address cannot carry credentials, in the basic-auth fields or in a header. Over an unencrypted connection anyone between us and the target can read them, and nothing on your screen would say so.

Beyond that, everything under Request settings is optional:

Setting	Default	Notes
Method	GET	GET, HEAD, POST, PUT, PATCH or DELETE.
Expected status	200–299	Any range between 100 and 599. Widen it if a healthy endpoint answers 301 or 401.
Query parameters	none	One per line, as name: value. Added to the URL's query string.
Headers	none	One per line, as Name: value. Sent with every check.
Request body	none	Sent exactly as written. Only valid with a method that can carry one.
Basic auth	none	Username and password, if the endpoint needs them.

Monitor is successful if

A status code alone will not catch an endpoint that returns 200 with an error inside it. Four optional assertions run against the body once the status check has passed; a response that passes the status check but fails one of these counts as down.

Assertion	Passes when
Body contains	The response body contains that text.
Body does not contain	It does not. Useful for a page that renders an error banner while still returning 200.
JSON field	The field exists. Written as $.status or $.checks[0].ok; names and array indexes only.
Expected JSON value	That field equals this value. Needs a JSON field to check.

Certificates

Every encrypted target has its certificate watched, and your team is warned ahead of its expiry. The monitor's row shows how long the certificate has left.

That means an https:// website, a wss:// socket, a port you tick Connect with TLS on, and a mail server on implicit TLS. A plain http:// or ws:// address has no certificate, and neither does a STARTTLS mail server from the outside; those rows say so rather than showing a check that never completes.

Port monitors

A host and a port. Tick Connect with TLS if the port expects a TLS handshake, as managed Redis or Postgres usually do. The check passes when the connection is accepted; nothing is written and nothing is read, so it cannot tell you the service behind the port is healthy, only that something is listening.

Port 25 cannot be reached from here at all. For mail servers, monitor the submission or IMAP port (587, 993) instead.

DNS monitors

Enter the bare name to resolve, example.com, no scheme and no path, and a record type: A, AAAA, CNAME, MX, NS, TXT, SRV, CAA, SOA or PTR.

Leave expected value empty and the check passes on any answer at all: the name resolves. Fill it in and the answer set must contain it, which is what catches a record that still resolves but now points somewhere wrong. Round-robin records are fine.

A few types answer a different question. SRV watches which server handles a service, and compares the target host rather than its weight. CAA watches which authorities may issue certificates for the name, written as issue=letsencrypt.org. SOA watches the primary name server, which is what changes when a zone moves. PTR is the one that runs backwards: give it an IP address rather than a name, and it checks what that address says it is.

Resolver is optional. Leave it empty and we ask our own resolver, which is what you want when you are watching your own zone. Put a public resolver's address there — 1.1.1.1, 8.8.8.8 — and the check asks that one instead, which is how you see what your users' resolver sees while a change propagates.

Ping monitors

A host and nothing else. We send one ICMP echo and wait for the reply, which is the only check available for something that runs no service to connect to — a router, a gateway, a printer, an appliance.

Two things to know. A great many hosts drop ICMP on purpose, so a ping monitor on a host that never answers is measuring a firewall rule, not an outage. And a ping tells you a machine is reachable, not that anything on it works; where there is a port to open or a URL to fetch, those say more.

Mail server monitors

A host, a port, and how the connection is encrypted. The check connects, waits for the server's greeting, says EHLO and reads the reply. That is the whole conversation: nothing is sent, nothing is delivered, no mailbox is touched, and we never sign in.

Encryption	Usual port	What happens
STARTTLS	587	Connects in the clear, then upgrades after the greeting.
Implicit TLS	465	Encrypted from the first byte.
None	—	Stays unencrypted. For an internal relay.

Pick the port and the encryption follows it, which is nearly always right. Port 25 cannot be reached from here; use 587 or 465.

Mail is the failure people find out about last, because nothing on the website changes when it stops. This check is what tells you before your customers do.

WebSocket monitors

A wss:// or ws:// address. The check opens the socket and passes once the server accepts the upgrade; it then closes without sending a message.

A WebSocket usually fails in a way an HTTP check on the same host cannot see: the page loads, the API answers, and only the live feed is gone. This is the check that notices.

Cron job monitors

Cron job monitors are built and held behind a deployment switch while the receiver is proved out. They are not yet available on the hosted service, and the console offers the type only on a deployment with the switch on. What follows describes how they work where they are on.

A cron job monitor waits for your job to check in. Saving one gives you a private URL; add one request to the end of your job, and the monitor records every run.

Setting	Default	What it means
Expected every	5 minutes	How often the job is supposed to run.
Grace period	60 seconds	How late a run may be before the monitor counts as down.
Track runtime	off	Have the job call a /start URL first, and a run that takes longer than its limit is reported too.

The URL is shown once, when you create the monitor, and can be rotated later from the monitor. Your job can also call a /fail URL to report a run that ended badly, which marks the service down without waiting for the deadline.

A cron job monitor stays off the public page until it has received its first ping, so a job you are still wiring up never shows as a failure. Cron job monitors have no response time: they report that a job ran, not how long a request to them took. They need the Heartbeat monitors capability.

When a monitor counts as down

Two consecutive failed checks. A single failure never changes what your public page shows; it is recorded, but the monitor keeps its previous state until a second check agrees. One dropped packet should not publish an outage.

The moment the state does flip, your own team is told (see Slack). Whether anything appears on your public page is a separate decision, covered in Incidents & maintenance.

Recovery is immediate: one successful check and the monitor is up again.

There is no manual override. A service is up or down because a check said so, and an incident is the place to explain anything the check cannot see.

Response time

Every website, port and DNS monitor also records how long each check took. Your public page shows the average beside the service, and expands into a day-by-day trend across the same history window the uptime bar covers (Branding); the same trend is on the monitor's row in the dashboard.

Question	Answer
What is averaged?	Completed checks only. Checks inside a scheduled maintenance window are left out, exactly as they are left out of uptime; work you announced should not show up as your service getting slower.
How is the headline figure calculated?	Across the whole window, weighted by how many checks each day actually ran. A quiet day cannot pull the average as hard as a full one.
What about a day with nothing?	It is left out of the chart rather than drawn as 0 ms. A service with no measurements at all in the window shows no chart, and no figure.

Order on the public page

Services appear in the order you arrange them. Drag a monitor by its handle, or use the up and down buttons on its row, and the public page follows. Within a group the same controls order the group's members. Put the service customers care most about first.

Domain registration

Domain-registration warnings are still being built. Delivery is paused by default and requires a separately enabled rollout; adding a monitor does not enable these warnings.

When enabled for your page, the feature checks registration expiry and can notify owners and admins by email, Slack and a domain.expiring webhook at 14 days, 3 days and on the expiry date. The monitor shows its registration-check state and any known expiry date. Keep your registrar's renewal reminders enabled.

Pausing and deleting

Pause stops checks and removes the monitor from your public page, keeping its history. Use it for a service you are decommissioning, or one you know will be noisy for a while. If the monitor was down and had opened an incident automatically, pausing it closes that incident rather than leaving it stranded open.

Delete removes the monitor and its history permanently, and frees one monitor slot for the account.

Allowlisting our checks

If your service sits behind a firewall, a WAF or bot protection, make sure your checks can reach the endpoint. InBrief checks include a User-Agent that names InBrief. Use it to find check requests in your logs, but do not treat it as proof of identity: any caller can send the same header.

Keep authentication and access controls in place. If you need an exception, scope it to the monitored endpoint and use a credential your service verifies. Do not bypass authentication or WAF protections based only on the User-Agent. Check addresses can change; no fixed source-IP range is promised here.

Next up