You Shipped It — Now What?
Maya's change is live. The pipeline went green, the canary stayed healthy, and Pageturn's new "favorites" button is now in front of real readers. It is tempting to call that the finish line and move on to the next thing. But for the running half of the work — Sam's half — going live is the starting gun, not the tape at the end.
Because live software is software that can misbehave in ways no test on Maya's laptop could catch. Real users do unexpected things, traffic surges at odd hours, a server fills up, a dependency slows down. Someone has to actually know whether Pageturn is working out there — and the only way to know is to watch it, deliberately and continuously. That watching is what this whole chapter is about, and it starts here.
Why "live" isn't the same as "done"
When a change is deployed, the building work is finished but the running work has only begun. A live app is not a parked car; it's more like a flight in progress. The deploy is takeoff — and any pilot will tell you that the minutes right after takeoff are exactly when you watch the instruments most closely, not when you sit back. (We'll drop the cockpit; from here we'll just say watching the running app.)
So "running software needs constant watching" is not a slogan — it's the plain reality of operations. Pageturn doesn't stay healthy on its own just because it launched cleanly. Conditions change every minute it's up, and the only way to keep it serving readers is to keep looking at it.
What are you actually watching for?
Watching is vague until you name the questions. There are three plain ones, and almost everything in monitoring is a way to answer them. Is it up — can readers reach Pageturn at all? Is it fast — do pages load quickly, or is everyone waiting? Is it erroring — are some requests quietly failing even while the site looks fine?
That last one matters most, because it's the one you'd never notice by accident. A site can look perfectly up to you while it's silently failing for one reader in twenty. Those are the problems that hide, and they're exactly why watching has to be deliberate rather than a glance now and then.
You can't fix what you can't see
Here is the principle the rest of the chapter rests on: you cannot fix a problem you cannot see. If a slow page or a broken sign-up never shows up anywhere Sam looks, then for all practical purposes the team doesn't know it exists — and a problem nobody knows about is a problem nobody is fixing.
That's why visibility has to come first, before any clever response. The point of monitoring isn't to react after a disaster; it's to make the state of the running app visible at all times, so small problems surface while they're still small. The next topic is exactly how that visibility gets built — logs, metrics, and alerts.
"You build it, you run it" — who does the watching?
Back in Chapter 1, DevOps came down to one team that both builds and runs its software — "you build it, you run it." This is where that slogan turns concrete. The team that shipped the favorites button is the same team that watches it in production. Maya doesn't hand it to a stranger and walk away; her team owns it after launch, too.
That ownership is the whole reason watching gets taken seriously. When the people who wrote the code are the ones who'll see it struggle — and who'll be paged if it falls over — they build it to be watchable, and they actually look. The wall between building and running is gone precisely here, at the point where the software meets real users.
- "Deploying is the finish line." It's the opposite — going live is where the running work starts. The building half is done; the watching half has just begun.
- "If no one complains, everything must be fine." Silence isn't health. Many real problems hide — failing for a slice of users, or slowing down — long before anyone files a complaint, which is why you watch on purpose instead of waiting.
- "Monitoring is only for after something has already broken." Its main job is to catch trouble while it's still small, before it becomes an outage — not to be switched on once things are already on fire.
- "Once a release passes its tests, watching it is someone else's job." Under "you build it, you run it," the team that shipped the change is the team that watches it. There's no separate team waiting to catch what you threw over a wall.
- This reframes monitoring as core operations work — the running half of "you build it, you run it" — rather than an afterthought bolted on at the end.
- It closes the feedback loop from Chapter 1: watching the live app is what tells the team what to change next.
- "Is it up, is it fast, is it erroring?" is the question set every monitoring tool you'll ever touch is built to answer.
- It sets up the next two topics — the tools you watch with (logs, metrics, alerts) and what you do when watching turns up trouble (on-call and incidents).
Knowledge Check
Why is a deploy described as a starting point rather than a finish line?
- Once the change is live, the work of keeping it healthy for real users begins
- Passing the tests means the running work is already complete
- A deployed app stays exactly as healthy as it was at launch
- Responsibility passes entirely to a separate operations team at the moment of deploy
A reader emails that sign-up has been failing for two days, but the site looked fine to the team the whole time. What does this show?
- A working-looking site can still be quietly failing for some users
- Waiting for user complaints is a perfectly reliable way to catch problems early
- Monitoring is only needed once something has clearly broken
- If the site loads for the team, it must be working for everyone
What does "you can't fix what you can't see" explain about monitoring?
- Visibility has to come first, because an unseen problem goes unfixed
- Monitoring automatically repairs problems as soon as they happen
- You should only start watching once a disaster has occurred
- Watching the app is just a distraction from the real work of actually building it
You got correct