The page your visitors get when it isn't working
Every page on this site explains an outage from your side. Here is what the person loading your app actually sees while it happens.
Four ways a visitor hits a broken page
Two are on purpose. Two are not.
An address that does not exist
A typo, an old link, or a page you took down. The visitor asked for something that was never there, or is not there any more.
A planned change
You asked for a maintenance window. The site is briefly unavailable on purpose, for a reason you control.
An unplanned failure
Something broke that nobody asked to happen. See the escalation ladder below for how it gets found and fixed.
An app that is up but refusing
The server answers, but sends back an error instead of the page — a bug, a full database, or a dependency it needs that is down.
What the visitor gets, by hosting shape
A static site and a dedicated instance fail in different ways, so they show a visitor different things.
- Static
- How long it is downNone — there is no running process to restart.What the visitor getsThere is no origin to fail. Every address either matches a built page, or gets the not-found page below — nothing in between.
- Dedicated
- How long it is downA few seconds while the process restarts. A health check confirms it answers correctly before the window closes.What the visitor getsA request that arrives mid-restart can come back as a connection error. There is no holding page standing by to show instead. See the honest limits below.
- Custom
- What the visitor getsSized to the workload, including whatever holding-page or fallback path the architecture calls for. Scoped and quoted like any other Custom shape.
Where the page comes from, hop by hop
Each hop can answer on its own. The last one has nothing behind it to fall back to.
- 1
The browser asks
A visitor loads an address, the same way for every hosting shape.
- 2
The edge network checks its rules
The URL rules run first — see Delivery for the full table. A missing address is caught here, before anything is fetched fresh.
- 3
The edge checks its cache
A cached page answers straight from here on a static site, with no origin involved at all.
- 4
The origin answers, or does not
On a cache miss, the request reaches durable storage or your own instance. If that instance is not answering, there is no further hop to fall back to.
Three pages, and you write all three
Each is a file in your repository, not a platform default you cannot see.
The not-found page
Shown for an address that does not exist. A page that genuinely doesn't exist returns your own not-found page, with a real 404 status code attached — not a blank error document from somewhere else. Delivery
The holding page
Shown on purpose, for the length of a planned change, then swapped back out. See "Putting a maintenance window up" below for the sequence.
The error page
Shown when your app is up but answering wrong — a failed dependency, a full database, a bug in the code. It is your own page, not a generic document from somewhere else in the stack.
Putting a maintenance window up, and taking it down
The visitor never sees the raw change happen — only the holding page, then the finished result.
- 1
You ask for a window
Send it through the same quote channel as any other request. No charge — a single edge rule is an ops request, the same as a DNS record.
You
- 2
The holding page goes up
The real site is swapped out for the holding page at the edge, for exactly the window you asked for.
CustomHosted
- 3
The change happens
Whatever the window was for runs behind the holding page, out of view of any visitor loading the address.
CustomHosted
- 4
A health check confirms it
The real site has to answer correctly again before it comes back — the same health check described on Deploys.
CustomHosted
- 5
The real site comes back
The holding page is retired. A visitor loading the address now sees the finished change, not a note that one happened.
CustomHosted
When it is unplanned
Who hears first, and what stands there while we work.
| Tier | What counts | Who hears, and when |
|---|---|---|
| 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 |
| 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 |
| 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 |
Who hears first
A watch signal, or you writing in — see the escalation ladder above for what counts and who gets told. Monitoring
What the visitor sees while we work
It depends on the hosting shape above. A static site keeps answering from its edge cache. A dedicated instance that is not answering gives the visitor a connection error instead.
What you see while we work
The first-hour timeline, in full, on the page that owns it. Incidents
The posted summary, once it is over
A hand-written, honest summary of the current state, not a live feed. Status
This site's own not-found page
customhosted.com is itself a static site — its own failure surface proves the smallest case on this page.
This site's own not-found page is a file in this repository
Written, briefed, and shipped the same way any other page on this site is — nothing about it is a platform default you cannot see.
A static site's failure surface is exactly one page
There is no origin to fail and no error page to answer wrong. The only page a broken address can ever show is the not-found page above.
Brief the page, and it ships like any other change
A holding page or a not-found page is a content change. It shares the same path from here on.
- 1
Briefed as a change
Written up the same way any other change request is. The iteration add-on is what covers it.
CustomLabs
- 2
An agent opens the pull request
The change lands as a real pull request against the repository, with the test suite run against it.
CodeHerder
- 3
A human reviews and merges
Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind.
CustomLabs
- 4
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
- 5
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
If a shipped change is the fault, that is not a page to design around — it is a revert. See Deploys for the path back.
No separate line item
The visitor-facing pages ride on the same plan and the same add-on as any other change.
The not-found and error pages cost nothing extra
Both ship as ordinary pages in your repository, under the same plan as the rest of your site.
Asking for a maintenance window
No charge — a single edge rule is an ops request, the same as a DNS record.
Writing or changing one of the three pages is a briefed change
Agentic iteration — CodeHerder ($25/mo) covers it, the same as any other small change. Brief a change in plain words. An agent opens a pull request, a person reviews it, and the same pipeline ships it.
Said plainly
No origin, no page. That is the floor this whole page rests on.
No origin, no page
When a dedicated instance is not answering at all, there is nothing left to serve your holding page. The visitor gets a browser-level connection error, not your artwork.
A dedicated release restarts — it does not swap
A single dedicated instance has no second copy standing by to take traffic while the new version starts. A release is a short, health-checked restart, not an instant handoff between two running copies.
No autoscaling
A flat rate means fixed, known capacity. Nothing on this platform grows itself in the background and bills you for it afterwards.
No uptime or recovery-time figure printed here
This page describes what a visitor sees, not a measured availability number. See the SLA for the binding figures this site does publish. SLA
A static site has no error page of its own
There is no origin to answer wrong, so there is nothing for an error page to catch. Its only failure surface is the not-found page above.
What visitors see, answered
The questions people ask once "we'll add a nice error page" stops being good enough.
01What does a visitor see if my site is down?
Depends on the hosting shape and what's actually wrong — see "What the visitor gets, by hosting shape" above. A static site keeps answering from its edge cache; a dedicated instance that is not answering at all leaves nothing to serve a page with.
02Can I have a custom 404 page?
Yes. A page that genuinely doesn't exist returns your own not-found page, with a real 404 status code attached — not a blank error document from somewhere else. Writing or changing it is a briefed change under Agentic iteration — CodeHerder ($25/mo).
03How does a maintenance page go up and come down?
See "Putting a maintenance window up, and taking it down" above for the full sequence — asking for it costs nothing extra.
04Does a maintenance window cost extra?
No charge — a single edge rule is an ops request, the same as a DNS record.
05What happens if the server is completely unreachable?
When a dedicated instance is not answering at all, there is nothing left to serve your holding page. The visitor gets a browser-level connection error, not your artwork. That is the honest floor of this whole page.
06Do you publish an uptime percentage?
Not on this page. This page describes what a visitor sees during a failure, not a measured availability number — see the SLA for the figures this site actually commits to.
07Who finds out first when something breaks?
A watch signal, or you writing in — see Monitoring for the escalation ladder and Incidents for the first-hour timeline in full.
08What if a deploy itself is the problem?
That is a change to undo, not a page to design around — see Deploys for the revert path once a shipped change turns out wrong.
What visitors see connects to
- Incidents
The first hour and the comms to you — this page owns only what the visitor sees during it.
- Status
The posted operational summary, for you — written after the moment this page describes.
- Monitoring
Who hears first, and the escalation ladder this page's "when it is unplanned" band reuses whole.
- Delivery
The 404 rule and the maintenance-window price this page's not-found and holding pages reuse whole.
- Deploys
The health-checked restart behind this page's dedicated-instance row, and the revert path when a shipped change is the fault.
- Patching
The update cadence this page's "planned change" moment is one instance of.
- Scaling
The flat-rate, fixed-capacity limit this page's honest limits reuse whole.
- Under attack
What stands between a flood of junk traffic and the pages this page describes.
- Dedicated
The hosting shape whose restart, and whose silence, this page states plainly.
Want a not-found or a holding page that actually looks like your site?
Brief it through the same quote channel as any other request — Agentic iteration — CodeHerder ($25/mo) covers it.