There is a quiet lie in how launches are usually celebrated. We treat "it shipped" as the finish line — the confetti moment, the screenshot, the done. But a launched app is not a finished object; it is a living system that real people now depend on. The day you Go Live is the day the meaningful work of operating it begins.
This guide covers what that operating work consists of, and how much of it can be handled for you rather than discovered the hard way. It is organised as layers, because that is genuinely how it works: several independent things catch problems at different stages, and knowing which layer catches what tells you where to look when something goes wrong.
Why "it worked when I launched" is not enough
An app can be perfect at the moment of launch and degrade an hour later, for reasons that have nothing to do with you. A later change introduces a regression. A dependency behaves differently. Traffic patterns shift. A credential expires. The gap between "it worked when I shipped it" and "it works right now" is exactly where outages live — and the only way to close that gap is to keep watching after the launch, continuously.
An app is not a thing you finish. It is a thing you operate. Monitoring is the difference between operating it on purpose and operating it by accident.
Layer one: repair before anything ships
The cheapest problem is the one that never reaches production, so the first layer sits before the deploy rather than after it. Every build self-corrects before you see it. It verifies typecheck, tests, the production build and runtime errors, repairs what failed and re-checks — with a behavioural pass and a visual pass alongside.
The important part is the acceptance rule. A build is accepted only when it is green and in scope; otherwise it is held for your review rather than shipped broken. "In scope" is doing as much work in that sentence as "green" — a change that passes every check but did something you did not ask for is still a change you should look at before it goes anywhere.
Think of this layer as the reason most incidents you would otherwise have had never become incidents. It is invisible when it works, which is unfortunate for its reputation and excellent for your evening.
Layer two: a ledger of what actually exists
The second layer answers a question that is surprisingly hard to answer about any real system: what does this app actually do, and does all of it still work?
Repository → Features is that ledger. It lists every feature the agent has built for the project, with a verification status against each entry. A passing build re-verifies every feature on the list; a failing one flags what it touched. This turns a vague worry — "I hope the thing I built last month still works" — into something you can look at.
It is also the fastest way to understand a blast radius. When a build fails, the flagged features tell you what the change was near, which is usually more informative than the error message itself.
Layer three: the record of what shipped
Repository → Deploy keeps a deploy history: every Go Live, what shipped, when, and whether it failed. Including the failures matters. A deploy log that only records successes is a log that cannot answer the most common question anyone asks it, which is "what changed just before this started going wrong."
This is the first place to look when you need to identify a bad release. The same tab also carries the deployment status card — the live URL, when it last shipped, the sandbox preview URL, and the Cloudflare project provisioned on the first Go Live.
Layer four: agents that keep watching
Everything above happens around a build. The fourth layer keeps going when nothing is being built at all. The Agents tab lets you switch on agents that keep watching after the build ends — over a project lifecycle, a URL, or a business event, around the clock. Open alerts surface on the same tab.
The value here is sequence. Detection is only useful if it reaches you, and you want to be the one who notices before the people relying on your app do. An alert turns a silent failure into a problem you can act on while it is still small.
The cost of finding out late
Every problem has a window between when it starts and when someone notices. The longer that window, the more it costs — in lost trust, lost transactions, and the stress of a fire that has been burning unseen. Good monitoring shrinks that window toward zero. The cheapest incident is the one you caught before anyone else felt it.
Worth noting where this sits commercially: continuous workspace monitoring is a paid-plan capability, with priority monitoring and alerts on the highest tier. It is not part of the free plan, which covers building and previewing rather than operating.
Going backwards: version history and rewind
The single thing that most changes how it feels to operate an app is knowing you can go back. Shipping stops being a held breath when a bad change is recoverable rather than permanent. It is worth being precise about how that works here, because "undo" means different things in different products.
Every build checkpoints the code, and Repository → Changes keeps a version history you can rewind the sandbox to. That is the mechanism: a history of accepted states, and a rewind that returns you to one of them. It is not a single button on a live deployment that instantly swaps production back — it is a version history you navigate, and then a redeploy from the state you chose.
The rewind is itself reversible
This detail matters more than it sounds. The current state is snapshotted before a rewind happens, which means going back does not destroy what you are going back from. Undo has an undo. That removes the last psychological barrier to using the feature at all — nobody hesitates over a reversible action.
Data goes back with the code
A rewind that restores code and leaves the database in a newer shape is a rewind that produces a second, stranger outage. Where the project has a provisioned database, its data is snapshotted and restored alongside the code. Code and schema move together, which is the only version of this that is actually safe.
Progressive rollout: not needing to go back
Better than a fast recovery is not needing one. Progressive rollout routes a slice of traffic to a new build so you can watch it, then widen it or pull it back. A change that is only in front of a fraction of your users is a change whose blast radius you chose in advance rather than discovered.
And sometimes: fix forward
Going back is not always the right move. For a small, well-understood problem it is often faster to fix it in the preview and redeploy, because the live site follows the same one-action path it did the first time. The rule of thumb: rewind when you do not yet understand what broke, fix forward when you do.
The post-launch health loop
repair → every build verifies, repairs and re-checks before you see it
accept → green and in scope, or held for your review
features → the ledger re-verifies on a pass, flags what a failure touched
deploy → every Go Live recorded, failures included
watch → standing agents over a lifecycle, a URL or a business event
alert → open alerts surface before users are affected
roll out → send a slice of traffic first, then widen or pull back
rewind → Changes holds a version history; the rewind is reversible,
and a provisioned database is restored alongside the codeReading your own usage
One surface that is easy to overlook belongs in any honest description of operating an app: Manage → Usage shows builds run, how many shipped, total spend and the last build, plus a per-run breakdown and the credit ledger for the account.
This is operational information, not just billing information. A month where the ratio of builds run to builds shipped drops sharply is telling you something — usually that a change you are pushing on is fighting back. Noticing that pattern early is worth as much as any alert.
An operating routine you can actually keep
Monitoring only helps if it turns into habits. A routine that survives contact with a busy week looks roughly like this.
- Before you go live: read the feature list, not just the page you happen to be looking at.
- When you ship something meaningful: send it to a slice of traffic first if the change warrants it, and watch.
- When an alert arrives: check the deploy history first. "What shipped just before this" answers most incidents on its own.
- When you do not understand the failure: rewind rather than experiment on production. The rewind is reversible, so it costs you nothing to try.
- When you do understand it: fix forward in the preview and redeploy.
- Weekly: glance at the usage summary. The ratio of builds run to builds shipped is a quiet health signal.
What this means for how you build
When you trust that launches are watched and reversible, your whole tempo can change. You ship smaller changes more often, because each one is safe to make and easy to undo. You stop hoarding changes into terrifying big-bang releases. The combination of verification before the deploy, a record of what shipped, and a version history you can rewind to is what makes a fast, iterative way of working sustainable rather than reckless.
There is a second-order effect worth naming. Small releases are not just safer individually; they make every incident cheaper, because the set of things that could have caused it is small. Teams that ship rarely spend their incidents doing archaeology. Teams that ship constantly usually already know the answer.
So treat Go Live as a beginning. The launch is the moment your app becomes real to other people — and everything described here is what lets you keep that promise to them on day two, day ten, and day one hundred.