# Someone is watching. Here's who, and for what.

> See what we watch and what fires on its own. Learn who hears about the rest and what the alert note contains. Escalation follows a fixed ladder.

Source: https://customhosted.com/monitoring/

№ 01 Monitoring

'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.

№ 02 What's watched

## 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](https://customhosted.com/scaling) for what a human does with that early flag. The Background jobs row has its own page — see [Background jobs](https://customhosted.com/background-jobs) for what runs a job and what happens when one fails.

№ 03 The quiet majority

## 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

№ 04 Escalation

## 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](https://customhosted.com/logs) for what it holds, and for how long.

№ 05 The message itself

## 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. 1 — What broke — In plain language — what a person would say, not a stack trace pasted in.
2. 2 — What it affected — Which part of the app, and whether it was visible to visitors or only caught internally.
3. 3 — What we did — The action taken, and whether it has finished or is still in progress.
4. 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.

№ 06 When it's not the machine

## 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.

1. 1 — You — Something fires, or you write in — Either a signal on the watch list trips, or you report something that doesn’t look right yourself.
2. 2 — CustomHosted — Triage — A human decides whether this is infrastructure — a retry, a restore, a rollback — or something in the application's own code.
3. 3 — CustomLabs — 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.
4. 4 — CodeHerder — It ships through the same pipeline — An agent opens the pull request, a human reviews and merges it, and the loop redeploys it.
5. 5 — CustomHosted — 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](https://customhosted.com/brief), how it ships on [The Loop](https://customhosted.com/loop), and a real one followed end to end on [Case files](https://customhosted.com/case-files).

№ 07 Said plainly

## 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.

№ 08 Answers

## 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.

1. 01 What 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.
2. 02 Why 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.
3. 03 What 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.
4. 04 Can 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.
5. 05 Is 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.
6. 06 Who 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.

№ 09 Keep reading

## What monitoring connects to

- [Under load This page's own escalation ladder, reused whole — who hears about a crowd, tier by tier.](https://customhosted.com/under-load)
- [Status The posted summary this page’s watching eventually feeds — hand-written on purpose, not a live feed.](https://customhosted.com/status)
- [Incidents What happens once this page's ladder hands off: the first hour, how you hear about it, and what it costs.](https://customhosted.com/incidents)
- [Recovery This page's after-picture: what happens once something is already broken, not just how it's found.](https://customhosted.com/recovery)
- [Patching This page's sibling: keeping something from going wrong, rather than finding out that it has.](https://customhosted.com/patching)
- [Domains The certificate-expiry and DNS-resolution signals above, backed with the full lifecycle and record sheet.](https://customhosted.com/domains)
- [Support How to reach a human directly, and what response times to expect.](https://customhosted.com/support)
- [SLA The binding 99.9% uptime target — the one figure this page defers to rather than restates.](https://customhosted.com/legal/sla)
- [The hours ledger What carrying the pager yourself actually costs, hour by hour.](https://customhosted.com/hours)
- [Scaling What happens after the Capacity row above fires: the ladder, the move, and what a human does with an early flag.](https://customhosted.com/scaling)
- [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.](https://customhosted.com/background-jobs)
- [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.](https://customhosted.com/under-attack)
- [Outside services Why a service we don't run watches itself, on its own schedule — this page's watch list stops at our own infrastructure.](https://customhosted.com/outside-services)
- [Without us This page's auto-handled tier and escalation ladder, split into what runs with nobody awake and what waits for a person.](https://customhosted.com/without-us)

## 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.

[Get a quote →](https://customhosted.com/contact)