Cogny Sites Now Checks Every Deploy Before Your Visitors Get It

A deploy that builds can still be broken. The code compiles, the container starts, and then every page answers with a server error because a variable is missing or a migration didn't run. Until today Cogny Sites would put that version live, because the build succeeded.

Now every production deploy is checked before your visitors see it.

What happens on a deploy

1. Cogny builds your site as before.
2. The new version starts next to the live one, without visitors.
3. Cogny loads it: the home page (or your site's health path, if one is set) has to answer without a server error. A slow first start gets up to two minutes.
4. If your repository lists smoke URLs, every one of them has to answer as listed.
5. Only then do visitors switch to the new version.

If anything fails, the previous version keeps serving. The deployment is marked failed, and the message names the page and what it answered:

1 of 9 smoke URLs failed on the new version (.cogny/smoke-urls): /pricing: expected 200, got 500. Visitors still get the previous version: traffic was not switched to this one.

A passing check adds about 20 seconds to a deploy. Pull request previews aren't checked: they never had visitors to protect.

Tell Cogny what must work

The home page alone catches a site that is completely down. To catch a broken pricing page, sign-up flow or API route, list it. Add .cogny/smoke-urls.txt to your repository:

# <path> <expected status> [<path it must end on after redirects>]
/ 200
/pricing 200
/blog 200
/sitemap.xml 200
/login 200 /auth/signin
/api/health

• The status is the final one, after up to 5 redirects. A row without a status passes on anything that isn't a server error.
• # starts a comment. Up to 100 rows are checked.
• The check runs on the new version's own address. A page that redirects to your custom domain would end up on the live version instead, so list pages that answer on the version itself, and pages that work without signing in.

If you use an AI coding agent, ask it to add a row whenever it adds a page that must never break. The Cogny Sites guide for agents explains the format, so an agent that reads it knows what to do.

When a check fails

Your site stays up on the version that worked. To find out why the new one failed:

• In Cogny: open Sites → your site. The failed deployment shows the page and the status.
• From your own agent over MCP: get_site shows the same line, and get_site_logs shows what the new version printed when it failed.

Fix the cause and push again. If the row itself is wrong (a page you removed on purpose), fix the row.

Turning it off

The check is on for every site. If you need a deploy to go live without it, an owner or admin can turn it off under Sites → your site → Deploy check, or ask their agent to call set_site_deploy_check. With it off, a broken deploy reaches your visitors until the next one, so turn it back on when you're done.