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.

A check you save from the recorder without replaying it first runs once right away, and it isn't confirmed yet. Until a run of it passes, I count its failures but I don't open an incident or write to you, and I never show it as working: a break at that point may be in the recording rather than in your application.

A check that fills in forms, reads email or opens another site doesn't run until you verify you own the project's domain. Until then it doesn't count as working or as broken, and it never writes to you; once you verify, I run it at the next chance I get. A check that goes on to a second site outside the project's domain doesn't run even then.

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.

Not every run that can't check your site is my fault. When your site turns my browser away — a firewall, bot protection or rate limit — on two runs in a row of the same check, I send one email per blocked stretch to your confirmed email addresses, never to Slack, Discord or a webhook. It is not an alert: it opens no incident, doesn't move the failure count and doesn't say your application broke. The stretch ends when my runs get in again, and a run that fails on my side doesn't count either way.

A run your site turned my browser away from is not a run I missed: it never counts toward that apology, nor as a missed run in your monthly summary.

Speed does not wake you up

How long a check takes is never an alert. A check that takes longer than it used to has still passed, and I write about a check when it breaks — two failures in a row, as above — never because its 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 never triggers a message. Scheduled weekly and monthly summaries can include its measured timings. The speed alert is about your real visitors after a deploy, and it waits for your quiet hours too; it has its own section below.

The plainest of these numbers is how long each check takes. Open the project, open a check’s menu, 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. I can include those numbers in a scheduled summary, but their change never triggers an alert. 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 tells me about problems that reach people using your application: an error nothing caught, a promise nothing handled, a server error from a request your own page made, and a script, stylesheet or module from your own site that failed to load. 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 with Broken ticked in Alert settings.

I send at most one Visitor-error message per error group every six hours, and no more than five Visitor-error messages per project in any 24 hours. Errors past that still appear on your project page. The email, Slack and Discord message quotes what the browser said, shortened and with any links removed; a webhook gets the text as it was stored. Quiet hours hold it. Choosing Ignore this one silences that group permanently. Show me the error opens that error on your project page. A Visitor-error message is not a check incident, so it has no recovery message.

Visitor speed after a deploy

The same snippet also tells me how quickly each page loaded for the people using your application: the first byte, the first and the largest thing drawn, how much the layout moved, and how long the page took to answer a tap or a click. It sends them at most once per page load, with no identifier attached.

After a deploy I noticed, I compare the day after it with the week before it, separately on mobile and on desktop, using the 75th percentile of each figure. A deploy before or after it cuts those windows short, and back or forward navigations and prerendered pages are left out. I need at least 40 page loads on both sides before I compare anything; with fewer, that deploy is recorded as not having enough data, never as steady.

A figure only counts as slower when all three are true: it is at least 25% worse, it is worse by at least 500 ms for the largest paint, 100 ms for a tap or click, 0.05 for layout shift or 300 ms for the first byte, and it is now past good — 2.5 seconds, 200 ms, 0.1 and 800 ms. I decide once per deploy, no sooner than an hour after it: as soon as both sides have enough page loads, or once its day after is over.

When something got slower, I write once. It goes to the confirmed destinations covered by your plan with Slower ticked in Alert settings, the project must be active, unpaused and using browser checks, and I send at most one Visitor-speed message per project every 24 hours. Quiet hours hold it. It names when I noticed the deploy and each slower figure before and after. Show me what slowed down opens the numbers for that deploy, and Ignore this one stops that message reaching anyone it has not reached yet. It says when pages got slower, not why. It is not a check incident, and there is no message when they get faster again.

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, one Visitor-error message per error group every six hours and no more than five per project in any 24 hours, and one Visitor-speed message per project every 24 hours. An open incident stays visible in the dashboard while repeat messages wait.

If an incident is still open 6 or 24 hours after its alert, I send one reminder to the destinations that got the alert and have Reminder ticked. You choose After 6 h, After 24 h or Never under Reminder if still broken. It counts the runs that broke since the alert, or for a project that stopped answering, how long it has been, and it says whether somebody pressed I’m on it; taking it does not stop the reminder. This is my only reminder for that incident: after it I stay quiet until it works again. A paused check or project, an archived project and a frozen account get none.

Quiet hours cover urgent messages

Quiet hours are Hold alerts overnight on the Alerts page of your settings. If you set quiet hours, incident alerts, reminders, recoveries, Visitor-error messages and Visitor-speed messages that come due inside the window wait until it ends. They are not dropped, though a held reminder goes out only if its incident is still open, and archiving a project closes its incidents, so an alert still held for one is not sent. Apologies, project notices, account and trial messages, confirmations and summaries follow their own timing instead.

Quiet mode holds the same messages for as long as you choose. The Quiet mode button in the app, on Overview, in Search and on the Alerts page of your settings quiets all projects or one project for 1 h, 2 h, until tomorrow 08:00 or a time you pick, up to 7 days ahead. Checks keep running, incidents are still recorded, and quiet mode never closes a broken one. When it ends, or you press End now, the held messages go out right away. If you extend it they keep waiting, but never longer than 7 days after the first one was held. The sample alert, summaries and account messages do not wait for it. Quiet this project… in an alert, Slack or Discord message opens the same choice after you sign in; the link itself quiets nothing.

If a check works again while its alert is held, by quiet hours or quiet mode, the alert is not dropped: the destinations that would have got it get one message saying when it broke and that it works again since, and no separate works-again message follows. Your own endpoint gets incident.opened and then incident.closed.

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 and still has Works again ticked in Alert settings; if nobody was told it broke, nobody gets a message saying it works again. Availability incidents follow the same delivered-alert boundary. Visitor errors and Visitor speed have no recovery message.

An incident alert links to I’m on it, and a broken check in the app has the same button. I’m on it records that you took it; it does not pause alerts or close the incident. The works-again message says when it was taken.

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, and so does the domain ownership email: when your DNS record isn’t there yet, I keep looking every few minutes for three days and write once, when I find it or when I stop. Trial messages go to the verified account email, including after the account is frozen. About a week before I delete the data of a frozen account for good, I send one more email to that same address, even without a project, and I send it again after each further freeze. Weekly and monthly summaries go to the one confirmed email ticked under Weekly summary in Alert settings, or to your first confirmed email covered by your plan when none is ticked, or to the verified account email as a fallback. Those messages are about their own event or schedule, so the check-incident threshold does not apply.

Every weekly or monthly summary ends with a link to turn that summary off. The page it opens only asks; nothing changes until you press Turn it off, and then only that one summary stops for the account. Alerts don’t change, and neither does the other summary. To turn it back on, use Alert settings. Activity keeps a copy of each summary I send, and Read it there shows the message as it went out. For a summary sent before I kept copies, Activity says I didn’t keep one.

Each summary names its week or month and lists the projects I could check, including projects I could not verify. It compares run and incident counts with the immediately preceding summary when I kept that summary’s figures. An older email without saved figures, or a skipped period, starts a new baseline rather than showing zero.

When timing figures are enabled, I show the middle of the retained measurements for each check’s server response, main content drawn and whole journey. The journey includes waits and my own work; it is not just your application loading. A comparison needs at least three measurements on each side from the same check definition and browser environment. Changes to either start a new baseline. Missing, expired or incomplete measurements are not zero, and a limited read gives no timing comparison.

Real visitor figures stay separate, with mobile and desktop each shown on their own. With at least twenty measurements of a figure, I show main content drawn and input response at the point where three out of four measurements are at or below it. A comparison needs twenty on each side. It describes recorded page loads, not individual people, and changes in traffic or the pages they open can move it. None of these summary figures changes a check’s result or sends another alert.

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.

“Send a sample alert” in Alert settings sends, on request, a made-up Broken alert about an invented check on example.com. It says up front that you asked for it and that nothing is broken, so you can see what a real one looks like. It goes to every confirmed destination covered by your plan that gets Broken alerts — email, Slack, Discord or your own endpoint. It never waits for quiet hours, opens no incident and moves no check’s failure count, and you can ask for it at most three times an hour.

Before the addresses I visit from or the name my browser carries change, I send one heads-up email to the verified email of every account that watches at least one project and isn’t frozen, at least two weeks before the change. It lists the date and the new values, and until then the abuse page shows them under How to recognise my browser. A change called off before the email goes out sends nothing, and it never goes to your other destinations.

After each payment for your plan, I email you a receipt with the period, the amount, the card when Stripe names it, and one button to the invoice. When a payment doesn’t go through, I email once for that invoice, however often Stripe tries again, with the reason and the next try when Stripe gives them. Both go only to your verified account email, frozen account or not, and never to your other destinations. Neither has a link to turn it off: a receipt is your record of a payment, and the failed-payment email is how you hear that checks may pause. A $0 invoice sends no receipt, and a failure already paid by the time I write sends nothing.

Export under Settings, Account & privacy, packs a copy of your data: your account and its settings, your projects and their findings, checks, runs and their steps, incidents, alerts and destinations, and your Founding 100 spot if your account took one, as JSON, plus the screenshots I still keep from those runs. Recordings, network traces, Visitor data and the sign-in values your checks use stay out, and a Slack, Discord or endpoint destination shows only its host, never its full address. When the copy is ready, I email your verified account email, frozen account or not. That email only says your export is ready; it carries none of your data and no download link. You download it from Account & privacy after signing in, for 7 days, and you can ask for a new one once every 24 hours. While your account is being deleted, there is nothing to export.

Where all of this arrives

Incident alerts, Visitor errors and Visitor speed go to every confirmed destination covered by your plan: email, Slack, Discord or your own endpoint. Each one gets only the kinds ticked for it in Alert settings: Broken covers incident alerts and Visitor errors, Reminder covers the one reminder of a still-open incident and needs Broken, Works again covers recoveries, and Slower covers Visitor speed. Which destinations your plan covers is decided first, by the order you added them, so turning a switch off never lets another one in. Recoveries use those same four channel kinds, but return only to destinations that received the matching incident alert. A reminder does the same over email, Slack or Discord; your own endpoint gets no reminder. If you have no confirmed extra email, your verified account email is the fallback, with its own switches. Broken always has to reach at least one of them, so I refuse the change that would leave nobody told. Project news goes to every confirmed email; the switches choose the rest. Summaries go to one email, the one you tick. Where I write covers extra addresses, Slack, Discord and your own endpoint, and why each one confirms itself first.