Behind Neverinstall's Limit-Free Observability with CtrlB
Neverinstall runs desktop applications in the browser. Its cloud PC platform streams apps to any device without a local install, and enterprises use it to give their employees a full desktop without running a traditional VDI stack.
Many of those enterprises run Neverinstall inside their own cloud accounts. So a single release does not land in one production environment. It lands in every tenant, on every cloud provider those customers use, and each deployment replicates the same set of 30 to 50 microservices. During its consumer days, the platform ran across roughly 30 clusters worldwide, each running around 20 services, and produced 700 to 800 GB of logs a day.
When a cloud PC lags or drops, the person in front of it notices within seconds. Engineers have to trace that back through every service in the request path, for whichever tenant it happened in. Observability has one job in that setup: tell the team when something is breaking, including on the nights when everything breaks at once.
Neverinstall's previous tools could not promise that. Each one came with limits the team only discovered when they hit them.
This is where CtrlB came in.
The challenge: Invisible limits, and observability that broke when it was needed most
Neverinstall started on New Relic. It turned out to be expensive, and beyond the bill, queries ran much slower than the team needed. It moved to Axiom next, which was cheaper, but brought rate limits on the number of columns and requests per second, and queries still slowed down as data grew. Logs rotated out after 7 days.
The cost of those limits became clear one night during Neverinstall's product-led growth phase, when anyone in the world could sign up and try the platform.
- Free-tier abuse starts. A wave of abusive traffic hits a set of public APIs and keeps going for roughly 18 hours.
- Calls cascade. Each API calls another set of APIs, which call others. Load multiplies across the microservices.
- Observability hits a limit nobody knew about. Requests per second cross a cap in the logging tool. Logs stop landing, and no alert fires.
- Production goes down overnight. Several production systems stay down until the team comes online in the morning.
- The investigation starts with gaps. With logs missing for the window that mattered, working out how the systems broke takes far longer than it should.
Rate limits were only half of it. Neverinstall's data structure keeps changing as services add fields, and the team had no way of knowing in advance that something would break at, say, the 101st column. Every new tenant raised the same question: if observability works for a customer at 10,000 users, will it still work at 50,000?
We appreciate when things are just elastic, and as an observability platform you take care of all of those optimizations invisibly. Instead of an invisible limit, give me invisible optimization.
Lakshman Pasala · Co-founder and CEO, NeverinstallThe challenge was to find an observability layer that scaled with Neverinstall's infrastructure instead of capping it, kept logs for months instead of days, and stayed fast while doing both.
The solution: One CtrlB data lake for every tenant, live in weeks
Having already moved from New Relic to Axiom, the team knew what a migration costs: engineering time, planning, deployment windows. They expected the move to CtrlB to take just as long.
It didn't. CtrlB works with the same OpenTelemetry connectors Neverinstall already ran, so testing in UAT and staging environments went quickly, and the rollout followed the same pattern. Neverinstall's infra team set CtrlB up across environments and tenants in one to two weeks, with CtrlB's onboarding team working alongside them.
On top of that lake, Neverinstall's engineers got what they had been missing:
180 days of searchable logs
Retention went from a 7-day rotation to 180 days, on larger datasets, without queries slowing down and with a smaller total cost of ownership.
Room to grow, with no invisible limits
New fields and new tenants land without the team checking a column cap or a rate limit first. Neverinstall has not hit either on CtrlB as its deployments and customer count have grown.
One dashboard across every deployment
Telemetry from every tenant and every cloud provider lands in one place, so engineers watch the whole fleet from a central dashboard.
AI-assisted query writing
Engineers describe what they are looking for and CtrlB writes the query. Neverinstall's team uses it often.
The results: 25x longer retention, at the same query speed
The impact shows up in how far back the team can look, how fast answers come back, and how the platform holds up on its biggest days.
Log retention: from 7 days to 180
Neverinstall's developers used to pick a 7-day range in the calendar widget because that was all they had. Now they pick 180 days, and the query comes back as fast as a 7-day one used to. The team's runbooks changed with it. WAF logs are now reviewed month over month, and insights are built on months of data instead of a week.
Query latency: 30 days of logs in under a second
Lakshman runs queries over 30 days of logs a couple of times a week. CtrlB shows the execution time for each one, and most come back in under a second. None has taken more than a few seconds.
Launch day at the largest ISP in East India
A few months ago, a new Neverinstall customer went to production: the largest internet service provider in East India, with more than 5.5 lakh (550,000) internet users. After a heavy marketing push, demand in the first two weeks ran well past what anyone had planned for. Observability had no issues through the spike. The systems scaled, CtrlB kept up, and it is still holding.
Don't let migrating be the reason you don't evaluate CtrlB. This would probably be the last migration, and it is not a nine-month affair. In most cases it's a few weeks.
Lakshman Pasala · Co-founder and CEO, Neverinstall