Press enter or click to view image in full size
Deployments succeed. The CI/CD pipeline greets you with a green checkmark. You celebrate. Then … a teammate reports they still see old behavior. “But the deployment succeeded!” you might think.
In this post, I want to share a quick reality check on distributed systems. Just because a deployment succeeded doesn’t mean it’s instantly available to all users. Depending on what you are deploying, the “time-to-live” can vary from milliseconds to literal days.
What Actually Happens
Here is a short overview of how this plays out in our stack (and this applies to lots of web-centric ecosystems as well):
Backend: Once the service is live, API responses update right away. As soon as the new containers are healthy, traffic hits the new code.
Web App: With the next page refresh, users see the update. Users who are currently active might still be running the old JavaScript bundle until they reload (or see a “New version available” gray toaster message).
Office Add-In: Same mechanism as web apps if you change anything but the manifest, but with a twist. Users don’t “refresh” Outlook or Excel add-ins as often as browser tabs. They might keep the side panel open for days, running stale code.
Extensions: Things get really interesting when we talk about browser extensions. We don’t control the delivery mechanism here — the browser stores do.
- Chrome: It usually takes 1–2 hours until it’s live in the store. After that, it can take up to a day for the Chrome browser to actually update the extension in the background.
- Edge: In many cases, the review process may take up to 5 business days. Then, add another day for the background update to propagate to clients.
What This Means for You
This latency creates a dangerous synchronization gap. If you ship a breaking API change thinking all your clients are updated, you’re potentially breaking the app for users somewhere between hours and a few days.
Deployment is what happens on your servers (which you control). Release is what happens on the user’s device (which you don’t).
The trap is thinking that “deployment” and “release” are the same thing. They aren’t.
If your deploy includes non-backwards-compatible changes, you need to assume:
- Some users will still be on the old client
- Some will be on the new one
- And some will flip over hours or days later
Best Practices
Because of the lag in extensions and add-ins, your backend code effectively lives in the future while your users may still live in the past. To keep things running smooth, your API changes must be strictly backwards compatible for at least as long as your slowest delivery channel takes to update.
- Keep the backend compatible with old clients until you’re confident the majority of clients have updated.
- Feature flags help you toggle behavior safely across disparate client versions.
- Communicate expected propagation timelines to QA, support, and your teammates.
- Watch real usage, not just CI success.
Conclusion
A green CI/CD badge means your code made it out the door — not that everyone is instantly using it. In our ecosystem of web apps, add-ins, and extensions, real-world rollout is staggered and unpredictable:
- Web backends are available immediately
- Web apps and add-ins update on refresh
- Browser extensions take hours to days to land in users’ hands
So, until the majority of clients are on the newest version, your backend and APIs still need to behave in a backwards-compatible way. Plan releases with this in mind — feature flags, compatibility guards, and clear communication between teams will save you time, confusion, and late-night fire drills.
In short: deploy ≠ delivered. Build as if some users will always be “stuck” on the version before the latest — because, for a while, they often are. Understanding rollout windows saves you from weird bugs and awkward chat threads at 2am.
How are your experiences?