There was a time when we thought uptime was simple. If dashboards were green, APIs were healthy, and latency looked good, we believed the system was doing its job. If something slipped, uptime was considered impacted — end of story.
As Meesho grew, that definition started to feel incomplete. We began to see situations where parts of the system behaved differently, yet the overall experience for customers and sellers remained stable. And in other cases, everything looked fine on the surface, but users still faced friction.
That’s when we stepped back and asked a different question: what does uptime really mean to the people using the platform?
A customer doesn’t think in terms of APIs or infrastructure signals. They care about whether they can browse products, place an order, and move on with their day. A seller isn’t tracking system metrics — they care about whether their workflows continue smoothly. From their point of view, uptime is less about system internals and more about consistency and reliability in the journey.
This shift in perspective changed how we thought about uptime at Meesho. We started viewing it not as a backend health indicator, but as a measure of experience and trust. It pushed us to rethink how we detect issues, design fallbacks, and distribute ownership across teams.
In this post, we share how that evolution shaped a more business-first and experience-centric approach to uptime — and how it influenced the way we build and operate systems at scale.
Our Early Approach to Uptime
In our early days, we measured uptime the way most companies do — tracking API error rates and latency across a set of critical endpoints. It gave us a decent view of system health when the scale was smaller. But as Meesho grew, so did the cracks in this approach.
We started running into a common problem: not all outages are created equal. A spike in error rates didn’t always mean users were affected — especially when fallback systems kicked in seamlessly. But our old metrics couldn’t tell the difference. Teams were frequently alerted about incidents that didn’t affect customers, which prompted investigations into issues with little user impact. This highlighted the need for a more experience-focused way to assess reliability. That’s when we knew — uptime couldn’t just be a technical metric anymore. It had to reflect the real world: customer experience, business continuity, and trust. We needed to shift from measuring system blips to measuring what truly matters. And that’s where the next chapter began.
Building Resilience: Smarter Fallbacks, Better Outcomes
Instead of just aiming for zero errors, we asked a different question: How do users still succeed when things break behind the scenes?
- Serving cached product feeds from a CDN
- Client-side error handling for a smoother experience
- Low-cost, disaster recovery setups that could kick in instantly
There was a time when we had an incident where a backend dependency misconfiguration impacted availability — something that, on paper, would’ve triggered a major outage alert. But here’s what actually happened: nothing. Users kept browsing, placing orders, and engaging with the app as usual. Why? Because our fallback system quietly took over, serving cached feeds from our CDN without missing a beat.
No signs of business impact. No user complaints. No incident response scramble. Yet under our old metrics, this incident would've flagged a full-blown outage and been counted as a hit to Meesho's uptime. But here's what those metrics missed: the hard work our team had invested in building robust fallbacks meant no business alerts were triggered. The user experience remained intact. In reality, Meesho's uptime was never compromised — the system worked exactly as designed. This moment reinforced a critical learning for us: real uptime isn't about whether a service fails, but whether the experience breaks. And in this case, it didn't. This moment reinforced a critical learning for us — real uptime isn’t about whether a service fails, but whether the experience breaks. And in this case, it didn’t.
A New Way to Measure Uptime: Business-Centric Metrics
We realised that traditional SLAs — things like API error rates or latency — only told part of the story. What really matters is simple: can users place their orders without issues? Can sellers fulfill orders without delays? So, we redefined uptime around real outcomes.
Now, if we see a sudden dip in order in a short time window, completion that counts as downtime. If the experience is slightly impacted but users can still complete their journeys, we treat it as a degradation rather than a full outage.
This shift changed everything. It brought engineers closer to the real-world impact of their work. It encouraged smarter investments in fallback systems and graceful error handling. And most importantly, it made uptime a shared responsibility across teams — not just something for backend or infra to worry about. During high-stakes moments like sale events, we even applied stricter rules because the stakes — and expectations — were higher.
RCA, Ownership, and Continuous Improvement
We embedded Root Cause Analysis (RCA) deeply into how we worked:
- Weekly RCA reviews across services
- Every team owned uptime for their flows
- Insights fed directly into our tech roadmaps
Incident RCAs played a big role in improving uptime. By closely examining what went wrong and why, teams were able to address root causes instead of simply reacting to alerts. In one case, an incident highlighted issues with configuration changes, which led us to move to a reviewed, code-based configuration process. Another RCA exposed gaps in our rollout signals and rollback speed, prompting us to build an in-house rollout system. Together, these learnings helped teams take stronger ownership and steadily improve system reliability.
Expanding the Scope: Supply-Side Uptime
We soon realised uptime isn’t just about buyers — sellers are equally critical to the marketplace. That’s why we introduced Supply Uptime to track seller-side reliability: order processing, return handling, and timely payouts.
It wasn’t easy — seller actions, varying work hours, and dependencies like logistics partners made things more complex. But investing here was key to ensuring trust and smooth operations across the entire ecosystem.
Decentralised Ownership: The Future of Uptime
As we scaled, we realized that uptime couldn’t just be the responsibility of a central team. We needed to spread ownership across teams, so each squad could take full accountability for the uptime of their specific areas.
By decentralizing ownership, we empowered teams like Search, Checkout, and Payments to define and own their uptime metrics. This led to a more proactive approach, better visibility, and quicker issue resolution. Teams became more aligned with business goals, which drove engineering excellence and greater accountability. This shift not only improved uptime but also fostered a culture of responsibility across the organization.
Final Thoughts: What We Learned
Over time, we learned that uptime is about more than avoiding failures — it’s about designing systems that handle change and uncertainty gracefully. At scale, different parts of a system may behave in unexpected ways, and what matters most is how reliably the core experience holds together for customers and sellers.
This shift pushed us to focus less on isolated system signals and more on real outcomes. Investments in fallbacks, clearer ownership, and thoughtful system design helped teams respond better and build resilience into everyday workflows.
Today, uptime at Meesho is shaped by shared ownership, practical learnings, and an experience-first mindset. It’s no longer just a number on a dashboard, but a reflection of how consistently the platform supports the journeys people rely on.
Ultimately, remember this: It’s not just about hitting five nines (99.999% uptime). It’s about building trust with your users and sellers.
