# When it breaks

> See what counts as an incident and the first hour step by step. Read the first response for each symptom and what it costs.

Source: https://customhosted.com/incidents/

№ 01 Incidents

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.

№ 02 What counts as one

## Three tiers, and one split

The escalation ladder from [Monitoring](https://customhosted.com/monitoring), reused whole — this page adds only the split it doesn't draw.

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

№ 03 The first hour

## The first hour, step by step

No stopwatch figure — a timeline of who does what, and what is actually true at each step.

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

№ 04 How you hear

## 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](https://customhosted.com/monitoring) 's own anatomy, reused whole:

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.

№ 05 First response by symptom

## 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](https://customhosted.com/delivery) |
| Site is slow | Check headroom against the tier — the next rung on the ladder is a scheduled move, not a guess. | [Scaling](https://customhosted.com/scaling) |
| Database refuses connections | Check the connection pool against its limit — a leak in the app, or a tier that has been outgrown. | [Databases](https://customhosted.com/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](https://customhosted.com/files) |
| Certificate expired | Renew it — this almost never happens on its own, since renewal runs ahead of expiry by default. | [Domains](https://customhosted.com/domains) |
| A deploy broke it | Revert the merge — the same pipeline that shipped it redeploys the last known-good version. | [Environments](https://customhosted.com/environments) |
| Traffic flood | Absorbed at the edge network before it reaches a static site or a dedicated instance. | [Under attack](https://customhosted.com/under-attack) |

№ 06 What you own while it runs

## 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](https://customhosted.com/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](https://customhosted.com/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.

№ 07 After it closes

## 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](https://customhosted.com/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](https://customhosted.com/legal/sla).

№ 08 What it does to the bill

## 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](https://customhosted.com/hours): 2 incidents a year, 4 hours each — one evening-eating outage or failed restore, a couple of times a year — infrequent, but not zero.

№ 09 The worked artifact

## 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](https://customhosted.com/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](https://customhosted.com/status).

№ 10 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.
- 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.

№ 11 CodeHerder

## 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. 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. 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. 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. 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. 5 — A human reviews and merges — Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind. — CustomLabs
6. 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. 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

№ 12 Answers

## Incident questions

What people ask once "someone will handle it" stops being enough of an answer.

1. 01 What 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.
2. 02 How 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.
3. 03 Do 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.
4. 04 Is 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.
5. 05 What 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.
6. 06 Does 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.
7. 07 What 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.

№ 13 Keep reading

## What the hour connects to

- [What visitors see What the person using your app actually sees while this page's first hour plays out.](https://customhosted.com/what-visitors-see)
- [Monitoring The before-picture: the watch list and the escalation ladder this page's first hour reuses whole.](https://customhosted.com/monitoring)
- [Logs The walk from a note to the line that says why, once this page's first hour has already run.](https://customhosted.com/logs)
- [Recovery What actually gets your data back, and the retention ladder behind it.](https://customhosted.com/recovery)
- [Status The posted current state — hand-written on purpose, and this page's own worked artifact for why.](https://customhosted.com/status)
- [SLA The binding uptime commitment, the claim window, and the credit ladder in full.](https://customhosted.com/legal/sla)
- [Billing The rest of the invoice — what moves the number, and what never does.](https://customhosted.com/billing)
- [Support The one channel in, for an incident or anything else.](https://customhosted.com/support)
- [The hours ledger What carrying the pager and the incident tax yourself actually costs, hour by hour.](https://customhosted.com/hours)
- [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.](https://customhosted.com/outside-services)
- [Without us No staffed round-the-clock desk, named here, expanded into what actually keeps running when nobody is awake.](https://customhosted.com/without-us)

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

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