Someone is watching. Here's who, and for what.
'Monitoring & alerts' is on every rate card and rarely explained. This page is the explanation: the actual watch list, what fixes itself with nobody woken, who hears about the rest, and what a bug that no monitor can see turns into.
The watch list
Ten signals, checked continuously. This is policy — what we check for and what happens when it fires — not a measured performance figure.
| Layer | Signal | What fires it | First response | Auto or human |
|---|---|---|---|---|
| Edge & network | Reachability and response code | Repeated failed checks, or a non-2xx response, from more than one vantage point | Confirmed as real (not one flaky check), then routed to the right response below | Auto, then human |
| Edge & network | Edge vs. origin error split | A run of 4xx or 5xx responses measured at the origin, not just at the edge in front of it | Narrows "the site is down" to where in the stack the failure actually sits | Auto |
| Certificates | TLS certificate expiry | A certificate entering its renewal window | Renewed automatically; a human is only pulled in if the renewal itself fails | Auto, then human |
| DNS | DNS resolution | A domain's records failing to resolve, or resolving somewhere unexpected | Escalated straight to a human — a DNS fault rarely fixes itself | Human |
| Application | Error rate / 5xx share | The share of requests returning a server error climbing past a set threshold over a rolling window | Logged and watched if it stays low; a human is pulled in once it holds above threshold | Auto, then human |
| Process & containers | Process and container health | A crashed process, a hung worker, or a failed health check on a running container | Restarted automatically, logged, and left there unless it keeps happening | Auto |
| Background jobs | Queue liveness and scheduled-job completion | A queue backing up with nothing consuming it, or a scheduled job that starts but doesn't finish inside its window | Retried once automatically; a repeat failure is what pages a human | Auto, then human |
| Capacity | Disk and memory headroom | Usage crossing a threshold set well ahead of the point it would actually cause an outage | Flagged to a human early, while it's still a maintenance task and not an emergency | Human |
| Database | Connections, replication, and backup completion | A connection pool running out, replication falling behind, or a nightly backup that never reported success | Logged and, for anything past a safe margin, handed to a human the same day | Auto, then human |
| Deploy pipeline | Deploy or build failure | A deploy that fails partway, or a build that doesn't complete | The pipeline halts and the last known-good version keeps serving; a human is notified | Auto, then human |
The Capacity and Database rows above are where a resize starts — see Scaling for what a human does with that early flag. The Background jobs row has its own page — see Background jobs for what runs a job and what happens when one fails.
What fixes itself
Most of the watch list never reaches you at all. A known, safe failure gets handled and logged automatically, as long as it stays low severity.
- Restarting a crashed process or a hung worker
- Retrying a failed background job once before flagging it to a human
- Redeploying the last known-good build when a deploy fails partway
- Renewing a TLS certificate ahead of its expiry
- Rerouting a request away from an origin that is failing its health check, where the edge network in front of it supports it
- Logging every one of the above, whether or not anyone gets woken
Who gets woken
Three tiers, from nothing to an outage. The watching and its automatic responses run continuously — the humans behind the second and third tier work business hours, with priority handling on an outage and best effort outside them.
| Tier | What counts | What happens first | Who hears, and when |
|---|---|---|---|
| Auto-handled | A known, safe failure with an established fix — a crashed process, a failed health check, a stuck deploy | Restart, retry, or redeploy the last known-good version, done automatically | No one, unless it recurs — it goes in the log, not a message to you |
| You hear from us | Something that touched the app and needs a person to pick the right response, not just a retry | A human looks at it and decides what to do — revert, restore, or a fix in code | You, in writing, on the same quote channel as everything else — business hours for anything that isn’t urgent |
| Outage handling | The site or a core function is down, or badly degraded, for real users | Worked ahead of the routine queue | You, as soon as there is something to say, with priority handling; out-of-hours response is best effort, not a staffed round-the-clock desk |
This isn't a staffed round-the-clock operations centre, and we'd rather say that plainly than let "around the clock" do more work than it should — see the honest limits below. The auto-handled tier's own log isn't a live feed either. See Logs for what it holds, and for how long.
What you actually hear from us
The same four parts, every time — this is the page's most concrete artifact after the watch list itself.
- 1
What broke
In plain language — what a person would say, not a stack trace pasted in.
- 2
What it affected
Which part of the app, and whether it was visible to visitors or only caught internally.
- 3
What we did
The action taken, and whether it has finished or is still in progress.
- 4
What's next
Whether it's closed, still being watched, or waiting on something from you.
Worked example
- What broke
- The database ran low on spare connections during a traffic spike.
- What it affected
- API responses were slow for a few minutes. The site stayed up the whole time.
- What we did
- Raised the connection limit and restarted the pool.
- What's next
- Watching it through the rest of today. Nothing needed on your side.
When the alert is your code, not the machine
The interesting failures are the ones nothing above catches on its own — a bug that answers with a perfectly healthy status code and the wrong data. Here's where that goes.
- 1You
Something fires, or you write in
Either a signal on the watch list trips, or you report something that doesn’t look right yourself.
- 2CustomHosted
Triage
A human decides whether this is infrastructure — a retry, a restore, a rollback — or something in the application's own code.
- 3CustomLabs
If it's a code bug
It gets briefed as a change, the same as any other feature request — this is what the Agentic iteration — CodeHerder add-on covers.
- 4CodeHerder
It ships through the same pipeline
An agent opens the pull request, a human reviews and merges it, and the loop redeploys it.
- 5CustomHosted
You're told it's closed
A note confirming what happened and that it’s done, in the same shape every time.
Read how a change gets briefed in the first place on Brief a change, how it ships on The Loop, and a real one followed end to end on Case files.
The honest limits
Not buried in a footnote — the same discipline as every other honesty band on this site.
Not a 24/7 operations centre
The watching and the automatic responses run continuously. The humans behind tiers two and three work business hours, with priority handling on an outage and best effort outside them.
No public live dashboard
Status is posted by hand, on purpose — see the page that explains why — not a real-time feed anyone can watch tick over.
Third-party services aren't watched by us
Anything living in a service we don’t run watches itself on its own schedule, not ours.
Not your business metrics
Uptime, error rate, and capacity, not signups, revenue, or conversion. Those stay yours to watch.
A healthy HTTP 200 with wrong data
Nothing on the watch list above catches wrong output that looks like success. That one arrives as a report from you, and becomes a briefed change instead of an alert.
Monitoring questions
The follow-ups that come up once "monitoring & alerts" stops being a line on a rate card and starts being something you're relying on.
01What do you actually watch?
The watch list above — reachability, certificates, DNS, error rate, process and container health, background jobs, capacity, database health, and the deploy pipeline. It is stated as policy, what we check for and what happens when it fires, not as a measured performance figure.
02Why no detection time or uptime percentage on this page?
Because we haven't measured either one across every stack we run, and an invented number would be exactly the kind of claim this site refuses to print. The one uptime figure we do stand behind is the 99.9% target in the SLA — a target, not a stopwatch result.
03What happens if something breaks outside business hours?
The automated watching and its automatic responses don't stop at 5pm — restarts, retries, and redeploys of the last known-good version keep running around the clock. The humans behind an outage give it priority and a best-effort response; this isn't a staffed 24/7 operations centre, and we'd rather say that plainly than imply otherwise.
04Can monitoring catch a bug in my own code?
Only the kind that shows up as a signal on the list above — a crash, a spike in server errors, a hung process. A bug that quietly returns the wrong answer with a perfectly healthy HTTP 200 won't trip anything here. That one reaches us as a report from you, and becomes a briefed change through the same pipeline as any other fix.
05Is there a dashboard I can watch myself?
No live one — the status page is a hand-posted summary, on purpose, not a real-time feed. What you get instead is a note when something actually happens, laid out the same way every time; see the anatomy of that note above.
06Who ends up carrying the pager if I host it myself instead?
You would. The hours ledger prices "monitoring and carrying the pager" at around 3 hours a month for one small stack — here, that row moves to us as part of every plan.
What monitoring connects to
- Status
The posted summary this page’s watching eventually feeds — hand-written on purpose, not a live feed.
- Recovery
This page's after-picture: what happens once something is already broken, not just how it's found.
- Patching
This page's sibling: keeping something from going wrong, rather than finding out that it has.
- Domains
The certificate-expiry and DNS-resolution signals above, backed with the full lifecycle and record sheet.
- Support
How to reach a human directly, and what response times to expect.
- SLA
The binding 99.9% uptime target — the one figure this page defers to rather than restates.
- The hours ledger
What carrying the pager yourself actually costs, hour by hour.
- Scaling
What happens after the Capacity row above fires: the ladder, the move, and what a human does with an early flag.
- Background jobs
The Background jobs row above, worked in full — where a job runs, the clock, and who owns whether it is safe to run twice.
- Under attack
This page's watch list carries no attack signal of its own — the honest boundary between watching for a fault and watching for an attack.
Something look wrong?
Write in through the quote channel — if it turns out to be a bug in your own code, it becomes a briefed change through the same pipeline as any other fix.