A go-live runbook for a serverless browser app

Launching an app with a backend is a fraught thing. There are servers to provision and scale, databases to migrate without downtime, connection pools to size, and the persistent fear that a surge of launch-day traffic will topple something. A serverless, in-browser app deletes almost all of that. There is no server to fall over because there is no server; the app is static files served from a content network, and every visitor’s device does the work. The first thing to say about a serverless go-live, then, is that the scariest launch risks — the ones that keep backend teams up at night — simply do not exist. That is a genuine and underrated advantage of the architecture, and it changes the whole texture of launch day.

But “fewer risks” is not “no risks”, and the risks that remain are quieter and easier to miss precisely because the loud ones are gone. Nobody forgets to scale a database when there is no database, but it is very easy to ship a launch where the share previews are broken, the analytics never fired, a critical asset 404s on a fresh cache, or search engines cannot index a thing. None of those will crash the app; all of them will quietly undercut the launch. A runbook for a serverless go-live is therefore less about surviving load and more about catching the subtle, silent failures before real traffic does. What follows is the actual ordered checklist, grouped the way we work through it.

The runbook starts at the most basic and most embarrassing-to-get-wrong layer: does the thing that is about to be public actually contain what you think it does. A clean production build from the exact commit you intend to ship, not a stale artifact and not your development build, is the foundation, and verifying it on a fresh load — with the cache cleared, as a first-time visitor would experience it — is the check that catches the most humbling launch bugs. The classic serverless failure is an asset that loads fine for you because it is cached from development but 404s for a genuine first-time visitor whose browser has never seen it.

So the first group of checks is concrete and physical: every image, font, script, and model loads on a cold cache; nothing in the network tab is red; the routes you expect all resolve, including the deep ones nobody clicks during development. For an app that loads large assets like AI models on demand, this includes confirming those deferred loads actually work from a clean state, not just that the page renders. This is unglamorous and it is where a surprising share of launch problems live, because development hides them behind a warm cache. Test as a stranger, on a fresh load, before anything else.

With the app itself confirmed, the next group is everything about how the app presents itself to the rest of the internet, because these are invisible in normal use and so are the easiest to ship broken. Page titles and descriptions should be present and correct on every route. Share previews — the card that appears when someone posts a link in a chat or on social — should render with the right image, title, and description, which means actually pasting a link into a couple of platforms and looking, because social crawlers are notoriously picky and a preview that looks fine in your head can come up blank in practice. A launch where every shared link shows a grey box is a launch that quietly loses half its word-of-mouth.

The indexing checks belong here too. The sitemap should exist, list the real routes, and be reachable; the robots rules should permit what you want crawled and block what you do not; canonical URLs should point where they should. For a content-bearing app these are not afterthoughts — they determine whether the work becomes findable at all. This is also the part of the runbook most amenable to automation, since a build step can verify that every route is in the sitemap and every page has metadata, which is exactly the kind of check described in /product-blog/a-build-time-validation-gate-for-content. The more of this the build enforces, the less of it you have to remember on launch day.

A serverless app cannot blame a slow server for a slow experience, because the performance the user feels is set by the assets you ship and how the device handles them. So the runbook checks the metrics that govern that feeling — how fast the page becomes interactive, how much the layout shifts as it loads, how heavy the first load is — on a realistic device and connection rather than a developer’s fast machine and fast network. A launch that feels instant in the office and sluggish on a mid-range phone over mobile data has not really been tested, because most real visitors are closer to the phone than the office. The number that usually matters most here is first-load JavaScript, for the reasons laid out in /product-blog/code-splitting-a-large-web-app.

For an app that promises to work offline or on-device, the offline path is part of go-live, not a bonus. If the pitch is that the tool runs without uploading anything and keeps working after the first load, then the runbook has to actually verify that: load the app, go offline, and confirm the core function still works. This is the kind of promise that is easy to make and easy to quietly break in a refactor, and launch day is the right time to confirm the headline claim is still true. An app whose central differentiator silently stopped working is worse than one that never claimed it, so the claim gets checked before the public does.

Here is the check that is most often left until it is too late: making sure you can see what is happening before the traffic arrives. Analytics and error reporting need to be live and verified at go-live, not wired up afterwards once you notice the numbers are missing, because the launch window is exactly when you most need to know whether things are working — and it is the one window you cannot replay. An error tracker that was not actually capturing errors during the first day of real use has cost you the most informative data you will ever get, and there is no going back for it.

So the runbook confirms, with a real test event rather than an assumption, that page views are being recorded, that a deliberately triggered error shows up in the error tracker, and that whatever signal tells you the app is healthy is actually flowing. For a serverless app this monitoring is your only window — there are no server logs to fall back on, so client-side reporting is the entire picture, which makes it more important here than in a backend app, not less. Turning it on and proving it works before opening the doors means that if something does go wrong on launch day, you find out from your dashboard rather than from a confused user, which is the difference between a quick fix and a slow, blind panic.

The last group is the one you hope not to use and must have ready anyway: the rollback. The enormous advantage of a static, serverless deploy is that rolling back is trivial compared to a backend — there is no database migration to reverse, no data to reconcile, just a previous set of files to point traffic back at. But trivial-in-principle is not the same as ready-in-practice, and the time to confirm you know exactly how to revert to the last good version is before launch, calmly, not during an incident with adrenaline running. A rollback you have never actually performed is a plan, not a capability.

So the runbook ends by making the rollback concrete: the previous deploy is known and retained, the command or action to restore it is understood by whoever is on call, and ideally it has been rehearsed at least once so it is muscle memory rather than a frantic search through documentation. Knowing you can be back to safety in under a minute changes the psychology of launch day entirely — it lets you ship with the confidence that a mistake is recoverable rather than catastrophic, which is the whole point of having a runbook. The combination of a serverless architecture and a rehearsed rollback turns go-live from a high-wire act into a reversible decision.

None of these checks is clever. That is the point. A go-live runbook is not a display of engineering sophistication; it is a way of making launch day boring, and boring is exactly what you want when something is becoming public. The value is not in any single item but in having the list at all, worked in a consistent order, so that the things that are easy to forget under the mild pressure of shipping get caught every time rather than most of the time. The same launch done from memory will eventually ship the broken share preview or the missing analytics; the same launch done from a list will not.

The serverless context shapes the list but does not shrink its importance. You inherit a gift — no servers to topple, a trivial rollback — and in exchange you take on responsibility for a set of quieter checks that a backend team might have other systems to catch. Work the runbook, in order, as a stranger on a cold cache, with monitoring proven live and a rollback rehearsed, and a serverless go-live becomes what it should be: a calm, reversible, well-lit step rather than a leap in the dark. The architecture removes the drama; the runbook removes the surprises.