When it breaks
What happens when something breaks: what counts as an incident, the first hour step by step, how you hear about it, and what it costs.
Business-hours humans. Priority on an outage. Continuous machine watching in between.
Three tiers, and one split
The escalation ladder from Monitoring, reused whole — this page adds only the split it doesn't draw.
- 1
Auto-handled
A known, safe failure with an established fix — a crashed process, a failed health check, a stuck deploy
No one, unless it recurs — it goes in the log, not a message to you
- 2
You hear from us
Something that touched the app and needs a person to pick the right response, not just a retry
You, in writing, on the same quote channel as everything else — business hours for anything that isn’t urgent
- 3
Outage handling
The site or a core function is down, or badly degraded, for real users
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
The one split this page owns: a platform fault against a bug in your own code.
A platform fault
Something in the infrastructure we run — a network path, a certificate, a database, a deploy pipeline.
Fixed on our side. You are told, not asked to help fix it.
A bug in your code
Your own application doing the wrong thing, even though the infrastructure underneath it is healthy.
Briefed as a change and shipped through the same pipeline as any other fix — see the CodeHerder tie-in below.
The first hour, step by step
No stopwatch figure — a timeline of who does what, and what is actually true at each step.
- 1
It starts
A watch signal trips, or you write in yourself.
Nobody has looked at it yet. It may still turn out to be a flaky check.
Auto
- 2
Confirmed
The signal is checked from more than one vantage point before a person is pulled in.
It is a real problem, not noise.
Auto
- 3
Triaged
A human decides whether this is a platform fault or a bug in your own code.
The right response gets picked — a restart, a restore, a rollback, or a briefed fix.
Us
- 4
You hear from us
A written note goes out on the same quote channel as everything else.
What broke, what it affected, and what happens next — see the note anatomy below.
Us
- 5
It's worked
An outage is worked ahead of the routine queue, not behind other requests.
Priority handling. Not a promise of a fixed time.
Us
- 6
Out of hours
The same priority applies, but the response is best effort, not a staffed desk.
Automated watching and its automatic responses keep running regardless of the hour — see Monitoring.
Us
- 7
It's closed
You confirm it looks right on your end.
The written follow-up and any credit path start from here — see "After it closes" below.
You
One channel, and a note in the same shape every time
The quote channel carries this the same way it carries everything else on this site.
One channel
The same quote channel as every other request — no separate incident portal to learn.
You hear again if it changes
Nothing you have to poll for. A new note goes out if the picture changes before it's closed.
A closing note
The same shape as the note above, marked closed — see "After it closes" for what it points back to.
What the note itself actually says — Monitoring's own anatomy, reused whole:
- 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.
Seven symptoms, and where each one actually gets fixed
Each row names the first action, and links to the page that owns the fix in full.
| Symptom | First action | Owned by |
|---|---|---|
| Site returns errors | Split the edge from the origin to see where in the stack the failure actually sits. | Delivery |
| Site is slow | Check headroom against the tier — the next rung on the ladder is a scheduled move, not a guess. | Scaling |
| Database refuses connections | Check the connection pool against its limit — a leak in the app, or a tier that has been outgrown. | Databases |
| Disk is full | Confirm what's actually filling it, then move to a bigger disk or clear what doesn't need to stay. | Files |
| Certificate expired | Renew it — this almost never happens on its own, since renewal runs ahead of expiry by default. | Domains |
| A deploy broke it | Revert the merge — the same pipeline that shipped it redeploys the last known-good version. | Environments |
| Traffic flood | Absorbed at the edge network before it reaches a static site or a dedicated instance. | Under attack |
The honest split, while it's still open
Some of it is always yours, whichever tier the incident turns out to be.
Telling us what you see
What looks wrong, and roughly when it started — the timestamp that unlocks every record.
Reading the record, if you want the detail
The walk from a note to the line that says why is a page of its own. See Logs.
Knowing which failure mode you are in
A broken change, lost data, or a failed machine each take a different path back — see the full set. See Recovery.
Confirming a fix before it is called done
A quick look on your end, before the note closes.
Deciding what ships in your own code
If the cause is a bug in the app, the fix is briefed and reviewed by you, not decided for you.
What happens after it closes
A written follow-up, a line in the record, and a credit path if the month missed target.
A closing note
The same shape as the note you got when it started, marked closed.
A line in the record
Who restored what, and when — kept for the life of the account, alongside every other change record. See Logs.
A credit, if the month missed target
A credit toward a future invoice, on the ladder below. It is never paid out as cash.
| If the month falls below | Credit |
|---|---|
| Below 99.9% monthly uptime | 10% of that month's fees |
| Below 99.0% monthly uptime | 25% of that month's fees |
| Below 95.0% monthly uptime | 50% of that month's fees |
Claim it, with the account and the dates affected, through the SLA.
What it does to the bill
What an incident does to your invoice, and what carrying one yourself would cost instead. The credit ladder that can move the number the other way is in § 07, above.
An incident, or a rollback
Both are handled at no extra charge — see the service-credit ladder for when an incident moves the number the other way.
Carrying this yourself is priced on The hours ledger: 2 incidents a year, 4 hours each — one evening-eating outage or failed restore, a couple of times a year — infrequent, but not zero.
What we can honestly show you
There is no customer incident record to publish. There is a small failure surface, and a page posted by hand on purpose.
This site's own failure surface is small
customhosted.com is itself a static site served from the edge network — see the attack-surface table for exactly how small that leaves it. See Under attack.
Status is posted by hand, on purpose
A hand-posted summary is an honest one. See the honest limits below for what that leaves out. See Status.
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.
No public incident history yet
Nothing here is posted publicly after the fact. What you get is the written note above.
No root-cause report to a fixed deadline
A closing note says what broke and what we did. A formal, timed root-cause report is not something this page commits to.
Third-party outages, we cannot fix
A dependency living in a service we do not run goes down on its own schedule, not ours.
No staffed round-the-clock desk
The automated watching runs continuously. The people behind an escalation work business hours, with priority on an outage and best effort outside them.
When an incident becomes a briefed change
Some incidents cannot be closed by a restart or a restore. The fix has to happen in the code. CustomLabs is the consulting side of this: it briefs the change, and reviews and merges what CodeHerder opens.
Triage says it is your code, not the platform
The infrastructure underneath is healthy. The fix has to happen in the application itself.
It answered correctly and returned the wrong thing
Nothing on the watch list catches wrong output that looks like success. That one reaches us as a report from you.
The same incident keeps coming back
A restart that keeps being needed is a symptom. Stopping it happening again is a change to the code.
Each of those ships the same way — Agentic iteration — CodeHerder ($25/mo):
- 1
A routine scan flags a dependency
The same kind of check that watches the infrastructure layers above, run against your application’s own dependency list.
CustomHosted
- 2
It's triaged as application-level, not infrastructure
A library your own code imports isn't ours to patch silently — it can change how the app behaves.
CustomHosted
- 3
Briefed as a change
Written up the same way any other change request is — this is what the Agentic iteration — CodeHerder add-on covers.
CustomLabs
- 4
An agent opens the pull request
The upgrade lands as a real pull request against the repository, with the test suite run against it.
CodeHerder
- 5
A human reviews and merges
Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind.
CustomLabs
- 6
It ships through the same pipeline
The same pipeline that deploys everything else on your stack ships this too — no separate process to babysit.
CustomHosted
- 7
You're told it's done
A note confirming what changed and that it merged, in the same shape as every other note on this site.
CustomHosted
Incident questions
What people ask once "someone will handle it" stops being enough of an answer.
01What actually counts as an incident?
Anything on the third tier of the escalation ladder — the site or a core function down, or badly degraded, for real users. See the ladder above for the other two tiers, and what each one means for who hears about it.
02How fast will you respond?
We don't publish a stopwatch figure, because we haven't measured one across every stack we run. What we publish instead: the first-hour timeline above, and priority handling on a real outage.
03Do I get a credit if you miss the SLA?
Yes, on the ladder above — below 99.9% monthly uptime moves 10% of that month's fees, and it grows from there. Claim it, with the account and the dates affected, through the SLA.
04Is there a public incident history I can check?
Not yet. Status is a hand-posted summary of the current state, not a public log of past incidents — see the honest limits above.
05What if it turns out to be a bug in my own code, not your infrastructure?
It gets briefed as a change, the same as any other feature request — this is what the Agentic iteration — CodeHerder add-on covers. An agent opens the pull request, CustomLabs reviews and merges it, and the loop redeploys it.
06Does an incident cost extra?
An incident, or a rollback: both are handled at no extra charge — see the service-credit ladder for when an incident moves the number the other way.
07What if it happens outside business hours?
The automated watching and its automatic responses keep running around the clock. The people behind an escalation give it priority and a best-effort response — this isn't a staffed 24/7 desk, and we'd rather say that plainly.
What the hour connects to
- What visitors see
What the person using your app actually sees while this page's first hour plays out.
- Monitoring
The before-picture: the watch list and the escalation ladder this page's first hour reuses whole.
- Logs
The walk from a note to the line that says why, once this page's first hour has already run.
- Recovery
What actually gets your data back, and the retention ladder behind it.
- Status
The posted current state — hand-written on purpose, and this page's own worked artifact for why.
- SLA
The binding uptime commitment, the claim window, and the credit ladder in full.
- Billing
The rest of the invoice — what moves the number, and what never does.
- Support
The one channel in, for an incident or anything else.
- The hours ledger
What carrying the pager and the incident tax yourself actually costs, hour by hour.
- Outside services
Why a dependency living in a service we don't run goes down on its own schedule, not ours — the honest limit above, expanded in full.
- Without us
No staffed round-the-clock desk, named here, expanded into what actually keeps running when nobody is awake.
Want the ladder and the credit terms in writing?
The SLA is the binding text behind this page. Anything else — brief it through the same quote channel as any other request.