Summary
One of India's leading e-commerce companies, with over 30 million monthly unique visitors, was moving off an established but expensive monitoring tool onto a newer observability platform. The move made commercial sense, but it exposed an urgent gap: the new platform did not yet support one monitoring workflow the team ran every day.
With a major sale event approaching and code freeze 10–15 days out, Procedure joined the apps team of the new platform to ship the core APM pipeline, add service-level and adaptive alerting, and fix log-heavy workflows under real production pressure. During the sale window, the platform handled roughly 300–400 million telemetry data points per minute across 50+ monitored services.
What started as a migration-specific ask became a reusable foundation. Once stabilized, the work rolled out to other platform customers.
About the Client
The client is an observability platform that helps engineering teams monitor distributed systems through metrics, logs, traces, dashboards, and alerts.
A large commerce company chose to migrate to the platform ahead of its busiest sales window. Its previous tool had been in place long enough for the team to build its daily workflows around it. Cost drove the switch, but timing created the pressure: those workflows had to keep working before peak traffic hit, and the team had a 10–15-day window before code freeze to get there.
The Problem
The migration uncovered a clear capability gap.
On their old tool, the team had built its monitoring around a specific application performance monitoring workflow. The new platform covered most of what they needed, but not the APM flow yet. With a major online sale approaching, closing that one gap moved to the top of the priority list.
Beyond APM, the engineering team needed an alerting system that worked at the service level. Generic dashboards were not enough. They needed to know which services were degrading, where abnormal behavior was starting, and whether alert thresholds could adjust to changing traffic patterns during the sale.
At the same time, developers using the platform reported real performance issues: slow log queries, repeated network calls, and resource contention under heavy usage. The migration scope had expanded. The platform needed to be production-ready for a live commerce event, not just feature-complete on paper.
Scope of Work
Procedure contributed a frontend-focused engineering expert to the delivery team. Backend architecture stayed with the platform team.
Work covered three areas:
APM and frontend delivery: Working with the apps team, Procedure helped to build the frontend architecture and implementation of the APM pipeline, connecting newly created backend metrics to the product experience as each metric became available.
Alerting workflows: The team added service-level alerting and adaptive alerting so the commerce team's engineers could track service health during unpredictable sale traffic, without relying on fixed thresholds.
Performance fixes: Work covered log query improvements, network call reduction, repeated-value fetching, and resource contention that surfaced under heavy platform usage.
The commerce company had 50+ services monitored through the platform. Telemetry volume during the sale window ran at 300–400 million data points per minute on regular high-traffic days, with higher spikes at peak. That volume was enough to surface real platform bottlenecks under live conditions.
The Challenge
The timeline was the constraint, not the complexity.
The commerce company had started the migration roughly a month before the sale. With code freeze days out, the platform team had to close critical gaps fast. APM was the critical path because it directly affected how the engineering team monitored application health during the event.
Three frontend engineers and two backend engineers worked in parallel. Backend engineers created and exposed new metrics. Frontend engineers connected them to the product as soon as each metric was ready. Waiting for full backend completion before starting frontend work was not an option given the window.
Not every requested feature made the cut. The team scoped to what was required for sale readiness and deferred anything that introduced too much release risk.
Real-user monitoring (RUM) was discussed and deferred. It would have extended visibility into end-user performance, but required SDK-side changes alongside UI work. Adding that scope so late introduced more risk than the timeline could absorb.
Our Approach
Alongside the platform's apps team, Procedure kept the critical delivery path moving without overloading the release window. Two calls shaped the work.
The first was sequencing. Frontend did not wait for the finished backend. Each metric was wired into the product the moment it was deployed, so the APM, alerting, and performance work moved in parallel instead of queuing behind full handoffs.
The second was restraint. The performance effort went where the commerce team was feeling it most, log-heavy workflows, rather than chasing every report. Work that carried real release risk so close to the freeze was deferred. The goal was a platform that held up live, not a longer feature list that shipped late.
What We Built
| Deliverable | What We Did | Why It Mattered |
| APM pipeline | Built the core application performance monitoring flow ahead of the freeze. | Closed the biggest capability gap in the migration from the legacy monitoring tool. |
| Metric-to-UI connection | Connected newly created backend metrics to the frontend as each became available. | Let frontend and backend teams move in parallel without waiting for full handoffs. |
| Service-level alerting | Added alerting workflows around monitored services. | Gave the engineering team a clearer read on which services were holding up under load. |
| Adaptive alerting | Added alerting behavior for changing traffic conditions. | Let the platform respond to traffic spikes instead of static cutoffs. |
| Log workflow improvements | Fixed log-heavy workflows through network, query, and data-fetching changes. | Made the platform usable during active debugging under high load. |
| Performance stabilization | Fixed resource contention issues, platform-side crash incidents, and metric storage behavior. | Reduced friction during the commerce team's highest-pressure operating window. |
Results
| Result | Detail |
| APM shipped before code freeze | The biggest gap from the legacy tool was closed before the window opened. |
| 10–15 day sprint | Critical APM, alerting, and performance work was delivered under a compressed timeline. |
| 300–400M data points per minute | The platform handled high-volume commerce telemetry throughout the sale window. |
| 50+ services monitored | Full coverage was held across every monitored endpoint during the event. |
| Log workflows improved | Log-heavy usage performed better through query, network, and data-fetching fixes. |
| Reusable platform features | The APM and alerting work rolled out to additional customers after stabilization. |
Why Procedure
We work inside the client's delivery rhythm.
Procedure's engineer joined the apps team mid-sprint, contributing to frontend architecture and implementation while backend metrics were still being written. Rather than waiting for complete handoffs, the team connected each metric to the product as it became available. The platform closed its most urgent migration gap before code freeze.
We build for the constraints real migrations create.
Moving a large engineering team off a mature observability tool is a workflow problem, not just a feature gap problem. Those workflows had to hold up before the sale window opened. With the apps team, we prioritized what would directly affect engineers during high-traffic operations and set aside the additions that could wait.
We turn urgent delivery into durable platform work.
The initial push came from one commerce customer's migration timeline. But the output did not stop there. Procedure helped build frontend flows, connect new telemetry metrics, and stabilize performance improvements that later became standard platform features. The sale shipped on time. The platform came out of it stronger than before.
