# The proof a change works.

> See what runs against a change before it ships and who owns each check. Learn what a failure does and what happens with no tests.

Source: https://customhosted.com/checks/

№ 01 Checks

A pull request that says 'checks passed' is easy to gloss over. This page is what actually runs, whose it is, and what happens when there is nothing to run at all.

№ 02 What a check actually is

## A yes-or-no question, asked by a machine

A script that answers yes or no. A machine runs it against every change, before a person ever looks.

№ 03 The kinds of check

## Six shapes, one job each

"Testing" is not one thing. Every change on this platform meets some or all of these.

1. 1 — Build — Turns the source into something that actually runs — a static build, or a new deployable copy of the app.
2. 2 — Format & lint — Catches a style slip or an obvious mistake before a person ever reads the diff.
3. 3 — Type check — Confirms the code is internally consistent — the right shape of value going into the right place.
4. 4 — Unit test — Confirms one small piece of logic does what it claims, on its own, apart from the rest of the app.
5. 5 — End-to-end test — Drives the built app the way a visitor would, and confirms a real path through it still works.
6. 6 — Guard — Checks a published claim against the real, built site, so the number on the page and the number it enforces can never drift apart.

№ 04 Whose checks they are

## What we bring, against what stays yours

- We bring this — Build, deploy, and health checks — Every change on this platform is built, checked, and health-checked before it ships — the same pipeline, on every plan, every time.
- We bring this — Published-claim guards — A number this site publishes is checked against the real, built output on every deploy — see the worked artifact below for what that looks like on this site itself.
- Yours to supply — Your own test suite — What your application should do, and how to tell it did, is your call. It needs your own knowledge of what correct looks like for your app.

| Shape | Plan | What runs |
| --- | --- | --- |
| Static | Static Starter | Build, plus every guard that checks a published claim against the built site — there is no running process to health-check. |
| Dedicated | Dedicated S, Dedicated M, Dedicated L | Build, deploy, and a health check before the new process takes over traffic, plus every guard above. |
| Custom | Custom | The same build, deploy, and guard checks, sized to whatever the workload actually runs. |

№ 05 Where a check runs in the loop

## Before staging, and again before production

A change starts one of two ways. A scan flags a dependency, or you brief one. An agent opens the pull request either way, and both paths meet the same checks.

A scan flags a dependency

1. 1 — A routine scan flags a dependency — CustomHosted — The same kind of check that watches the infrastructure layers above, run against your application’s own dependency list.
2. 2 — It's triaged as application-level, not infrastructure — CustomHosted — A library your own code imports isn't ours to patch silently — it can change how the app behaves.
3. 3 — Briefed as a change — CustomLabs — Written up the same way any other change request is — this is what the Agentic iteration — CodeHerder add-on covers.
4. 4 — An agent opens the pull request — CodeHerder — The upgrade lands as a real pull request against the repository, with the test suite run against it.
5. 5 — A human reviews and merges — CustomLabs — Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind.
6. 6 — It ships through the same pipeline — CustomHosted — The same pipeline that deploys everything else on your stack ships this too — no separate process to babysit.
7. 7 — You're told it's done — CustomHosted — A note confirming what changed and that it merged, in the same shape as every other note on this site.

You brief a change

1. 1 — Brief the change — You — Describe it in plain language, the same way as any other change under the Agentic iteration — CodeHerder add-on.
2. 2 — Agent opens the pull request — CodeHerder — Reads the live codebase and makes the change on its own branch — a real diff, not a description of one.
3. 3 — CI builds it — CustomHosted — The same build and checks that gate every other change on this platform run against this one too.
4. 4 — It stands on staging — CustomHosted — The branch deploys to the standing staging environment automatically — a real URL, not a diff on a screen.
5. 5 — You click the real thing — You — No diff-reading required — load the page, use the feature, decide if it's right.
6. 6 — Merge ships production — You — Approving the pull request merges it, and the same pipeline that just built staging redeploys production.

№ 06 When a check fails

## Nothing new ships until it passes

- Deploy or build failure — What fires A deploy that fails partway, or a build that doesn't complete — First response The pipeline halts and the last known-good version keeps serving; a human is notified

1. 1 — 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.
2. 2 — 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.
3. 3 — Outage handling — **The site or a core function is down, or badly degraded, for real users.** Worked ahead of the routine queue.

- Revert the merge — The same pipeline that shipped the change redeploys the last known-good version. No data touched, because none was.
- Promote the previous deploy — On static hosting, the last deploy is already built and kept. Going back is a request through the usual channel, a straight promotion of it rather than a rebuild.
- A data problem is a restore, not a rollback — If the thing that's wrong is data rather than code, that's the other procedure entirely — see Recovery for the backup and point-in-time paths, and where that boundary actually sits.

№ 07 When there are no tests at all

## Most small applications start with none

That is honestly common. Here is what still runs, and what to do about the rest.

- Hosting does not write you a test suite — A test suite needs your own knowledge of what correct looks like for your app. That is not something hosting can supply.
- The guards we bring still gate the deploy — Build, deploy, and every published-claim guard run regardless. A repository with no tests of its own is not a repository with no checks at all.
- A briefed change can add a first test — Brief "add a test for this," and the pull request that adds a first assertion comes back the same way any other change does, under Agentic iteration — CodeHerder ($25/mo). See [Brief a change](https://customhosted.com/brief).
- A real suite is CustomLabs build work — Writing the tests that actually assert your application is correct is a build engagement, not a hosting line. CustomLabs takes that on directly. See [customlabs.io ↗](https://customlabs.io).

№ 08 Worked artifact

## This site's own 17 checks

Every one of them gates every deploy of this site, including this page.

- check:anchors — Every hub page's "On this page" index still matches its own numbered bands, in order.
- check:a11y — Every route is crawled for accessibility faults, at two sizes, in both themes.
- check:ledger — The public build-history page still matches what this repository's own history says.
- check:llms — The machine-readable site directory lists every route exactly once, and every link actually resolves.
- check:perf — Every route stays inside its own published page-weight budget.
- check:security-txt — The security-contact file is present, and not expired.
- check:supply-chain — The dependency-safety rules — locked versions, no install scripts, a release cooldown — are still in place.
- check:seo — Every route carries one canonical URL, one title, one description, and valid structured data — and nothing meant to stay out of the index does.
- check:forms — The form page's own field caps, its POST-only check, its honeypot field, and its log retention still match the real contact-form terraform.
- check:images — Every image stays under its published weight ceiling, and every picture carries alt text, its dimensions, and a loading value.
- check:limits — Every module that publishes a limits array is collected on /limits, and its published count matches what the page actually renders.
- check:logins — No password input exists anywhere on the site, every form carries a known id with no off-site action, and /logins' own worked artifact still renders.
- check:compliance — No affirmative compliance or certification claim appears anywhere on the site, and /your-data's residency and deletion bands still render.
- check:spacing — No run-together word slipped past a stripped space next to a link or other inline element, on any route.
- check:reveal — Every section that fades in on scroll actually appears, on a phone-sized screen as well as a desktop one.
- check:twins — Every route's Markdown twin exists, starts with the page's real heading, carries no stray HTML, and is linked from the page exactly once.
- check:quotes — No published quote bills an add-on its plan already includes, and the estimator prices only through the same code as the quote form.

A guard is negative-tested before it is trusted — deliberately broken once, to confirm it actually fails, not just added and assumed to work.

№ 09 What it costs

## Nothing metered

- Checks are not metered — Every change runs the same pipeline of checks, on every plan, as many times as it needs to. There is no per-check fee and no cap on how many run in a month.
- Adding a test is a briefed change — Adding or extending your own test suite goes through the same loop as any other change — the Agentic iteration — CodeHerder add-on ($25/mo). The hours ledger prices a full brief-to-merge pass at about 2 hours of your own time, assuming a small copy or config change, briefed and reviewed start to finish.

№ 10 Said plainly

## The honest limits

- A passing check is not the same as a correct change — The pipeline confirms the code builds and behaves as tested. It cannot confirm the change is what you actually wanted — that read is still yours.
- A check proves only what it was written to prove — A green build means every check that exists passed. It says nothing about the ones nobody wrote.
- No coverage figure, published or implied — This page names what runs and why. It publishes no coverage percentage, no pass rate, and no bug-reduction claim — this site holds no artifact for any of them.
- A flaky test in your repository is yours to fix — A test that fails on and off, for no code reason, blocks a deploy the same as a real failure. Fixing or removing it is a briefed change like any other.

№ 11 Answers

## Check questions

What actually runs before my change goes live?

17 automated checks on this site alone, plus your own build, lint, type, and test checks where you have them — see the worked artifact above for the full list.

Do you write tests for my app?

Not on our own. A briefed change can add a first test harness, and CodeHerder can add a test as part of a change you brief — see "When there are no tests at all" above for the honest split.

What happens when a check fails?

A failed check produces nothing new to publish. The pipeline halts and the last known-good version keeps serving; a human is notified. See "When a check fails" above for the escalation ladder behind it.

My repository has no tests at all. Now what?

The guards we bring still gate every deploy regardless. A first test harness is a briefed change; a real suite that asserts your application is correct is CustomLabs build work — see the section above.

Does a passing check mean the change is correct?

The pipeline confirms the code builds and behaves as tested. It cannot confirm the change is what you actually wanted — that read is still yours.

What does running these checks cost?

Nothing extra by itself — checks are not metered. Adding to your own test suite is a briefed change under Agentic iteration — CodeHerder ($25/mo). See "What it costs" above.

№ 12 Keep reading

## What checks connects to

- [Brief a change The input, before a branch exists — what a good brief needs before an agent ever opens one.](https://customhosted.com/brief)
- [Review The human approval decision that comes after the checks on this page have already run.](https://customhosted.com/review)
- [Deploys Everything that happens once a change merges — this page stops at the checks that gate it.](https://customhosted.com/deploys)
- [Environments The standing staging environment a checked change lands on before you click it yourself.](https://customhosted.com/environments)
- [Patching Where a dependency bump becomes a briefed pull request, run against the same checks as any other change.](https://customhosted.com/patching)
- [Repository The "some tests" trait a repository can start with — or without — and what a briefed change can and cannot supply.](https://customhosted.com/repository)
- [In flight The "no cap on how many run in a month" line above, quoted where it answers the pace question directly.](https://customhosted.com/in-flight)

## Got a repository with no tests in it yet?

Brief a first one, or ask CustomLabs to build a real suite — either way, the same checks gate every deploy.

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