Checks before a change ships

№ 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
Build
Turns the source into something that actually runs — a static build, or a new deployable copy of the app.
2
Format & lint
Catches a style slip or an obvious mistake before a person ever reads the diff.
3
Type check
Confirms the code is internally consistent — the right shape of value going into the right place.
4
Unit test
Confirms one small piece of logic does what it claims, on its own, apart from the rest of the app.
5
End-to-end test
Drives the built app the way a visitor would, and confirms a real path through it still works.
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
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
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
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
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
A human reviews and merges
CustomLabs
Someone reads the diff before it goes anywhere near production — nothing here is auto-applied blind.
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
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
Brief the change
You
Describe it in plain language, the same way as any other change under the Agentic iteration — CodeHerder add-on.
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
CI builds it
CustomHosted
The same build and checks that gate every other change on this platform run against this one too.
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
You click the real thing
You
No diff-reading required — load the page, use the feature, decide if it's right.
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
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
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
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.
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 ↗.

№ 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

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 →

The proof a change works.