When I write, and when I stay quiet

A check gets a second look

One failed browser check tells you almost nothing. A deploy was halfway out, a third-party script hung, a network hiccup landed on the one second I happened to look. So the first failure buys that check a second look rather than an incident alert: I try it again ten minutes later.

If that check fails again, I open an incident and write to you. The threshold for one check incident is two consecutive failures and is not configurable. Outside availability checks use the same two-failure threshold, but keep their regular ten-minute rhythm instead of adding a separate retry.

When the fault is mine

Sometimes a run fails on my side: the browser died, the job could not be collected, something in my own infrastructure gave up. That is recorded as my error, not as your application breaking. It does not move the failure count, it never opens an incident, and that run sends no alert claiming your application broke.

It also never shows up as a pass. A run I could not complete leaves the check in an unknown state and stays out of your summaries, because green here means I verified it — never that nothing shouted.

If I miss the same check three runs in a row, I send a separate apology by email. That apology opens no incident and says the gap was mine. I send at most one missed-run apology per project every seven days.

Speed does not wake you up

Speed is never an alert. A check that takes longer than it used to has still passed, and I write when a check breaks — two failures in a row, as above — never because a number moved. That is a rule of the product rather than a stage it is going through: however much I learn about how long your pages take, a slower check still writes to nobody.

The plainest of these numbers is how long each check takes. Open the project, expand About this check, and once I have successful runs on two separate days you get the fastest, the latest and the slowest of the last thirty days, with a small curve behind them. Only runs that passed are counted, and each of those days counts once, as the middle of that day’s runs, so one unlucky run cannot move the picture on its own. Editing a check starts its curve over, because different steps take a different amount of time and the runs from before the edit are no longer comparable. It is there to be looked at, not to be acted on.

What that number is not: it is my own run, from one place in central Europe, in my own browser, on my own machine — not what the people using your application met on their own devices and networks. It is no verdict on your Core Web Vitals, which only real visits can answer, and it is never a pass or a fail.

Where I put the numbers

There is more than that one number. Every one of them sits under the result it belongs to, never beside it — a check that passed can still show you it was not as fast as usual, and that is something to look at rather than something I write about. They all come from the same place, my own run in my own browser, so none of them is a verdict either.

Open a single run and Where the time went splits it into three parts that do not overlap: the journey I walked, getting the app ready, and my side. My side is my own start-up and cleanup — starting a browser, opening a clean window, saving the recording — so a run that took longer because of me does not read as your application slowing down. Under that I list every page load I finished and every step, so you can see which page load and which step added the time, and tell the whole walk apart from one page load or one step.

A page load is broken up the way a browser meets it: finding the server, connecting, securing the connection, the first byte and downloading the page, then the first thing drawn, the largest thing drawn, when the page finished loading, how long the page was busy and how much the layout moved. Below them I group the requests and downloads by what they were and whether they came from your site or from somewhere else, with how many requests and how many bytes came down. Five counts cover the whole run: the errors my browser saw and the crashes on the page, the requests that did not finish, and the answers in the 400s and the 500s.

One run is one sample, so a check I have timings for carries a Timings link of its own, with the same numbers over the last thirty days of that check and how many runs I compared behind each one. I only compare runs I measured the same way: editing a check, changing how I sign in, or a change in my own browser starts a new baseline, and I say which of the three it was instead of comparing across the break.

A deploy I noticed gets a block of its own, What I saw after I noticed this deploy, underneath the results of the checks that ran: the same numbers before and after, the difference I observed, and how many runs each side is made of. It is what I saw afterwards, not why — there is no cause in it and no threshold. While the runs on both sides are too few, I say I need more of them before I can call it a change. If I only know a deploy happened somewhere inside a window of time, I leave the runs in that window out and say where the window was. And if something in your application broke afterwards, or I did not measure enough of what came after, I say which of the two it was and compare nothing.

On the project itself there is one quiet sentence, with no heading and no colour, naming the check that took me the longest and how long that was, and linking to that check’s own numbers. When there is nothing measured to say it about, there is no sentence — never a zero, and never a dash.

Visitor errors have their own rule

The optional Visitor-errors snippet reports problems that reach people using your application. I write when the same Visitor error reaches three page loads within one hour. The project must still be active, unpaused and using browser checks; the error group must not be ignored; and there must be a confirmed destination still covered by your plan.

I send at most one Visitor-error message per error group every six hours. Quiet hours hold it. Choosing Ignore this one silences that group permanently. A Visitor-error message is not a check incident, so it has no recovery message.

Each repeat limit has a boundary

I send at most one incident alert per check every six hours, one availability alert per project every six hours, and one Visitor-error message per error group every six hours. An open incident stays visible in the dashboard while repeat messages wait.

Quiet hours cover urgent messages

If you set quiet hours, incident alerts, recoveries and Visitor-error messages that come due inside the window wait until it ends. They are not dropped. Apologies, project notices, account and trial messages, confirmations and reports follow their own timing instead.

And when it works again

The first successful run closes its check incident. A recovery goes only to a destination that received the incident alert before it; if nobody was told it broke, nobody gets a message saying it works again. Availability incidents follow the same delivered-alert boundary. Visitor errors have no recovery message.

When I cannot get a project ready

Some projects need something from me before any check runs: getting past a cookie notice, or starting from a page I have to sign in to reach. That setup runs ahead of every check that depends on it, so when it stops working, the checks behind it do not run. If the setup fails twice in a row, I send one email about it. It goes to your confirmed email destinations covered by your plan, or to your verified account email if you have no confirmed extra email, and quiet hours hold it until the window ends.

That email says nothing about your application. A setup I could not finish moves no check’s failure count and opens no incident, and it is sent once for each spell of trouble: if the setup works again before the email goes out, I say nothing at all. There is no recovery message for it — the project page shows the setup working again.

Other messages follow their own event

Some project news is email-only: the missed-run apology, certificate or domain expiry notice, deploy confirmation, and the notice that I stopped checking an unreachable project. They go only to confirmed email destinations covered by your plan. If you have no confirmed extra email, your verified account email is the fallback. None waits for two failed checks.

A plan-ceiling notice goes to the verified email of an active account. Trial messages go to the verified account email, including after the account is frozen. Weekly and monthly reports choose one confirmed report email, or the verified account email as a fallback. Those messages are about their own event or schedule, so the check-incident threshold does not apply.

A destination confirmation is the one message I can send to the new, unconfirmed destination. It carries the confirmation link and no project details. Until it is confirmed, that destination receives nothing else.

Where all of this arrives

Incident alerts and Visitor errors go to every confirmed destination covered by your plan: email, Slack, Discord or your own endpoint. Recoveries use those same four channel kinds, but return only to destinations that received the matching incident alert. If you have no confirmed extra email, your verified account email is the fallback. Where I write covers extra addresses, Slack, Discord and your own endpoint, and why each one confirms itself first.