Summary
An observability platform took on a new customer for the season: a fantasy sports platform whose match-day traffic ran well past anything the platform had handled before. Procedure handled the product's frontend: closing the one capability missing on day one (Aerospike support in APM) and running match-day operations through the season. At peak, the platform has sustained 980 million telemetry data points per minute against a committed 99.9% SLA, with zero escalated incidents.
About the Client
The client is an observability platform that provides real-time monitoring, metrics ingestion, and alerting for teams running large distributed systems. The platform collects logs, metrics, and traces through standard pipelines and surfaces system health for engineering teams under heavy load.
For this engagement, the platform was onboarding one of its more demanding customers yet: a fantasy sports platform coming on for a single high-stakes season of live cricket, where match windows drive sharp, short-lived spikes in traffic, and downtime is not an option.
The Problem
A new customer at this scale is mostly an onboarding problem. The platform already existed and had been hardened through earlier enterprise customers, so the job was fitting it to one more stack rather than building from scratch. The gap analysis was short, with one capability standing out: the customer ran Aerospike, a high-throughput NoSQL database that the platform's APM did not discover out of the box.
The bigger test was scale. Match-day traffic during live cricket is spiky and large: at peak the customer pushed telemetry toward 980 million data points per minute, in short windows that opened and closed with each match. Every match meant scaling the stack up ahead of kickoff and winding it back down afterward, on tight timing and against a 99.9% SLA. Support on the account was kept deliberately lean.
The Onboarding
Onboarding followed the platform's standard timeline. Because the platform had matured across previous enterprise engagements, most requested features were already in place, so the team could focus on the few that were not.
The headline gap was database discovery in APM for Aerospike, which is not in common use across the platform's customer base and so was never part of the automated discovery path. The team added support through a partly manual integration, scoped to the customer's setup, so that the customer's database layer showed up in APM alongside everything else.
The Scope
Procedure owned the frontend product work, in close collaboration with the platform's backend team.
- Aerospike support in APM database discovery
- Dashboards page improvements, surfacing pinned and recently visited dashboards
- Bug fixes across traces, dashboards, and logs, with ticket closure and pre-match deploys
- Rotational on-call and match-day operations for every match of the season
The Challenge
Two things made this harder than a routine onboarding: scale and headcount.
On scale: at peak, the platform ingested 980 million telemetry data points per minute. Scale-up and scale-down stayed manual, driven through Terraform configs that adjusted storage, pods, and ClickHouse resources ahead of each match and wound them back down afterward. Ingestion targets arrived from the customer a day ahead of each match.
On headcount: Procedure ran the account lean, covering product changes, deploys, and on-call across the season. On-call ran on a rotation. Deploys went out ahead of the match start, never during a live match.
One thing is worth saying plainly. From the outside, the customer's domain looks exotic: real-money fantasy gaming, live cricket, huge concurrent spikes. To an observability platform, it is the same problem it always is. Metrics, logs, and traces. The domain shifts. The primitives do not.
Our Approach
Onboarding first: we confirmed what was already supported and closed the Aerospike gap before the season ramped up.
Dashboards next: we improved the dashboards page so engineers could reach the right view faster during a match, instead of scrolling through the full list.
Stability throughout: for the first two weeks, the work was a steady mix of new features, bug fixes, and ticket closure, with deploys timed to land before each match.
Operations during matches: we monitored health, triaged on a rotational on-call, and held the line on no in-match deploys.
What We Built
| Deliverable | What We Did | Why It Mattered |
| Aerospike support in APM | Added Aerospike to the APM's database discovery, scoped to the customer's setup. | The customer's Aerospike layer now shows up in APM alongside everything else, closing the one real gap at onboarding. |
| Dashboards page improvements | Surfaced pinned and recently visited dashboards on the dashboards page. | Engineers reached the right dashboard faster during live match windows, with no scrolling through the full list. |
| Bug fixes and stability | Fixed bugs across traces, dashboards, and logs, closed tickets, and timed deploys to land before each match. | Telemetry stayed accurate and usable through high-traffic windows. |
| Match-day operations | Ran on-call for every match on a rotation, triaging alerts and monitoring system health. | Issues have been caught and handled without escalation. |
Results
| Result | Detail |
| 980M Data Points/Min | Peak telemetry ingestion sustained during live matches |
| 99.9% SLA | SLA committed to match-day operations |
| 0 Escalated Incidents | No incident escalated |
| 10-20 Services | Services and endpoints monitored for the customer |
| All Matches Covered | Every match supported end-to-end |
| 30-60 Min Resolution | Working window for resolving routine issues during match days |
Why Procedure
We scale with the customer. Onboarding a customer whose peak ran to 980 million data points per minute means raising the ceiling before the first match, while keeping an existing customer alive is mostly steady-state work. The team built for the higher ceiling up front.
We support what your stack actually runs. Aerospike was not on the platform's automated discovery path, so the team built discovery for it instead of telling the customer it could not be monitored. Meeting a customer where their stack already is, is most of what onboarding at scale means.
We run lean and still ship. Procedure covered product changes, deploys, and on-call across a season of live cricket, with zero escalated incidents. Small teams work when the people on them have the context and judgment to make match-time calls.
