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, plus heartbeat monitors for cron jobs.
• 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.
• Down and recovered emails to the people on the monitor's escalation policy (your owners and admins unless you change it), at most one per monitor every 30 minutes.
• An Acknowledge button on every down alert, so the team can see who is handling an outage.
• Certificate-expiry warnings for encrypted targets. Domain-registration warnings are coming soon.
• 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 add and delete monitors, and 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; see below.	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 2 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 target must be reachable over the public network. Local hostnames, private addresses and this installation's configured InBrief hostnames are refused. A separate public service can share the same parent domain; its resolved addresses and redirects still have to pass those checks.

If a check is unavailable, the monitor list and recent checks show the recorded reason when one is known. An unavailable attempt does not count as downtime or prove that the service is healthy.

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

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 frequency	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.
Job runtime	off	Tick Track start and finish signals and have the job call a /start URL first; a run that takes longer than its Maximum runtime 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 Alerts to your team). 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.

Alerts to your team

When a monitor goes down or comes back up, InBrief emails the first step of the monitor's escalation policy. Until you change it, that is the account's own address and every active owner and admin on the team, and nobody else. The subject names the service and the page, for example Service down: API (Acme). A down email also says what the last check returned, when there is a reason to give, and its button is Acknowledge. A recovery email's button is Open monitor.

Each monitor sends at most one email every 30 minutes, so a service that keeps failing and recovering does not fill everyone's inbox. A down and the recovery after it share that limit. Slack is not limited this way: every change posts to the channel (Slack).

A monitor that goes down during announced maintenance sends no email, and nor does its recovery afterwards: nobody was told it was down. Nothing in these emails reaches your subscribers.

The emails come with Monitoring, as its Down and recovered alerts feature. Free sends them too, for the monitors its allowance covers.

Acknowledging an outage

Acknowledging tells the rest of the team that you are handling an outage. Press Acknowledge on the monitor's page, choose it from the monitor's menu in the list, or use the button in the down email or the link in the Slack message. The email and Slack links open the monitor and ask you to confirm, so a forwarded email cannot acknowledge for somebody else. If you are signed out, you sign in and land back on the same monitor.

Once somebody acknowledges, the monitor page, the list and any live incident that names the service show who it was and when, and Slack gets a short message saying who is on it. Acknowledging stops the later steps of the escalation policy for this outage. It does not change the monitor's state, resolve anything, or post to your public page.

Owners, admins and operators can acknowledge. Viewers can see who acknowledged but cannot do it themselves. The first person to confirm is recorded, and anyone who confirms after them is told who got there first. Each outage starts unacknowledged: if the monitor recovers and goes down again, the new outage needs its own acknowledgement.

On-call and escalation

Dashboard → On-call holds the account's escalation policies. A policy is a list of up to 5 steps. Step 1 is alerted as soon as a monitor goes down. Each later step waits 5, 10, 15, 30 or 60 minutes after the step before it, and is alerted only if nobody has acknowledged the outage by then and the monitor is still down. A step can alert the owners and admins, everyone who can acknowledge (owners, admins and operators), or people you pick. Viewers are never alerted.

Every account has one default policy, and every monitor follows it unless you pick another on the monitor's Settings tab under Escalation policy. An account can keep up to 20 policies. The default you start with alerts the owners and admins at once and has no later steps, so nothing changes until you add one.

Later steps are emailed even inside the 30-minute limit above, because each one goes to people who have not heard about this outage yet, and Slack gets one message per step. If everybody a step names has left the team, that step goes to the owners and admins instead. Owners and admins edit the policies; everyone else on the team can read them. There are no rotations, schedules or phone calls.

Response time

Every website, port, DNS, ping, mail-server and WebSocket 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). In the dashboard, choose a monitor's response time to open the same trend under its row.

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. Choose Reorder above the list, then drag a monitor or use its up and down arrows, and the public page follows. Inside a group the same controls order the group's members. When a page has more than one group, each group's heading gets arrows that move the whole group. Choose Done to go back to the list. Put the service customers care most about first.

Domain registration

Domain-registration warnings are coming soon. Adding a monitor does not turn them on.

Once they are available on your page, InBrief 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