Groundtruth
Download the Case Study.webp)
The right alert hits the right engineer. Every time. Here's how Groundtruth does it with IMR.
A 3:00 AM alert tests two things.
1. How quickly your team can respond
2. Whether the right person received the alert in the first place
For Josh Gies, Manager of the DevOps team at Groundtruth, the second question was the more important one — and the harder one to get right.
Groundtruth is a location-based marketing and ad-tech platform that uses real-world consumer behavior to drive business results, specifically in-store visits. The engineering organization runs 70 to 80 production engineers handling development and deployments. Roughly 50 to 60 of them participate in the on-call rotation at any given time.
That’s a lot of engineers. And a lot of alerts.
And without the right infrastructure, there's a lot of potential to wake the wrong person at the wrong hour.
The shift-left culture shift
Getting to “straight to the source” required more than a tooling decision; it required a cultural one.
Groundtruth made a deliberate move to a decentralized, shift-left model: developers who build the systems also own and fix them. DevOps — Josh’s five-person team — functions as the hub, providing infrastructure, IAM roles and policies, and troubleshooting support. The engineering teams are the spokes, expected to be self-sufficient.
Under this model, alerts bypass DevOps entirely and route directly to the responsible team. As Groundtruth has grown, that ownership model has evolved too — moving from team-based to project-based accountability as the atomic unit. When a project changes hands between teams, the alert keys in Xurrent IMR move with it.
Groundtruth needed something that could accommodate a more fluid ownership model, one where accountability lives at the project level and the tooling enforces it automatically. Xurrent IMR's alert routing logic made that possible without requiring DevOps to manually curate every change.
Putting it to the test: the Aerospike migration
The real proof of Xurrent IMR’s alert-filtering came during a database migration from Aerospike to AWS ElastiCache.
During the transition, the Groundtruth team ran dual writes to both systems and kept the new ElastiCache alerts set to informational-only while engineers monitored and tuned thresholds. They adjusted alert logic — “if this triggers X times over Y period, then alert” — to prevent false pages during normal load spikes. Once validated, the new alerts were promoted to live paging. The Aerospike alerts were held at informational-only for about a week, then deleted entirely.
No one got woken up unnecessarily.
The migration was clean.
Follow-the-sun: 24/7 coverage without the burnout
One of the most effective things Groundtruth has built with Xurrent IMR is its global on-call rotation.
The engineering team is split roughly 50/50 between North America and India, an 11.5-hour time difference that could easily be a liability. At Groundtruth, it’s an asset.
The rotation structure is equally disciplined: each team has a primary on-call engineer for the week, who becomes the secondary the following week. Alerts fire from Grafana (using Prometheus for system metrics) and AWS CloudWatch, routing through Xurrent IMR to the right engineer in real time.
For critical alerts — like an outage on the external-facing web app that serves 300,000 to 350,000 queries per second — Xurrent IMR immediately pages the primary engineer and pushes a notification to a dedicated #outages Slack channel for broader awareness. If the primary doesn’t acknowledge within 10 minutes, the secondary gets the page. Ten minutes after that, it escalates to Josh.
MTTA for critical incidents: 5 to 10 minutes.
“We really save those outage alerts for things that are actually revenue-impacting or reputation-impacting,” Josh noted.
Not every alert is a fire.
Groundtruth gives individual engineering teams full autonomy to define what constitutes a critical page versus a business-hours-only informational alert. An analytics report that needs to reach external customers by 9:00 AM EST doesn’t trigger a 3:00 AM page — teams configure their own thresholds.
“With teams being responsible, if there is alert noise for a particular team, that’s self-inflicted … It’s kind of been up to them to decide the level of noise that they want. Some teams want a ton of information, but they don’t actually need to be paged out.”
From Slack to resolution: the incident lifecycle inside Groundtruth
Once an alert fires and the right engineer is paged, the incident lifecycle at Groundtruth runs almost entirely inside Slack.
Xurrent IMR's Slack integration means engineers acknowledge alerts, update incident status, add notes, and coordinate resolution without ever switching surfaces. The IMR web UI is where the infrastructure gets configured — alert rules, routing logic, escalation policies, integrations. But from the moment an incident is declared to the moment it's resolved, the engineer's world is Slack.
This matters for a team like Groundtruth's. With 50 to 60 engineers across two continents on rotation at any given time, the last thing you want is a tool that requires context switching mid-incident. Triage happens in the channel. Findings get posted in the thread. Resolution is confirmed in the same place the alert landed. The postmortem has a full record of everything that happened — because it happened in one place.
Why Xurrent IMR replaced VictorOps
Groundtruth wasn’t in crisis when they made the switch. VictorOps was working. The problem was simpler: they were paying for far more than they were using.
PagerDuty was also evaluated. The team found it too narrowly focused on paging and would have required too much manual curation to build the routing logic Groundtruth needed.
“There are lots of different alert and paging solutions out there, but some of them only do the paging. What stood out for us about Xurrent IMR is that it seemed like a robust enough solution to be a viable replacement.”
Today, Xurrent IMR is turnkey for the DevOps team.
What's next, and what Josh would tell another team
Groundtruth's on-call infrastructure is largely where Josh wants it to be. The next frontier is pushing engineering teams further toward service-level performance metrics rather than individual instance metrics. Less noise by design, not by suppression. The alerting model gets smarter as the system gets better described.
As for what he'd tell another engineering team thinking about the switch: stop paying for a feature list you'll never touch. Stop routing alerts through people who have no business receiving them at 2am. Stop treating on-call burnout as an unavoidable cost of running production systems.
The fix isn't more tooling. It's better-structured tooling. Tooling that fits how your team actually works, whether that's a conventional rotation or a fully decentralized shift-left model where every team owns what they ship.
A tool that removes friction and accelerates resolution is a tool your team will actually use. And a team that actually uses its incident management tooling, consistently, across time zones and ownership models and 3am database migrations, is a team that builds reliability into its culture. Not just its stack.
That's what Groundtruth built.
And it starts with making sure the right person's phone rings. Not the wrong one.
