How Grafana Cloud transformed MiQ’s observability with unified logs, metrics, and traces
When MiQ, a global programmatic media partner helping brands succeed across platforms and channels, needed to modernise their observability stack, Associate Engineering Manager Ipuvi Mishra and Software Engineer Ambarish Singh knew it was time to simplify.
Their previous setup relied on more than a dozen disparate, self-hosted tools to manage logs, metrics, and traces, leading to operational silos, maintenance overhead, and long debugging cycles. The team wanted a solution that would streamline observability across their eight Kubernetes clusters, improve developer autonomy, and reduce operational burden.
Ipuvi and Ambarish recently spoke with Grafana Labs about how MiQ’s phased migration to Grafana Cloud delivered just that, cutting debugging time from nearly an hour to under 15 minutes and reducing costs by $10,000 annually while setting them up for future scalability with synthetic monitoring, AI-based insights, and application observability.
To start, can you describe what your observability setup looked like before migrating to Grafana Cloud?
Ambarish: Before the migration, our observability stack was a patchwork of different tools, each one serving a specific purpose. We used LogDNA for logs, a full open source Prometheus setup for metrics, Grafana OSS for visualization, and Jaeger with OpenTelemetry for traces. Alerts came from multiple places, including a separate on-call system called OpsGenie. On top of that, we ran everything across eight different Kubernetes (EKS) clusters, each with its own observability stack, which made maintenance a huge burden for our small team.
We had roughly 18 tools or components just to monitor our systems. The constant context switching between these tools made debugging slow, alerting noisy, and managing everything increasingly unsustainable as we scaled.
How has debugging improved since migrating to Grafana Cloud?
Ipuvi: Previously, diagnosing issues required moving between separate tools and a lot of manual steps — a process that could take hours.
With Grafana Cloud, the team has end-to-end visibility that helps us pinpoint the root cause within minutes, enabling quick fixes and minimizing stakeholder impact.
Since the migration, we’ve seen an overall 20% reduction in troubleshooting time and a 15% improvement in application monitoring and alerting, strengthening reliability for our customers.
You did a vendor evaluation before selecting Grafana Cloud. What were you looking for, and what made Grafana Cloud the right choice?
Ipuvi: We were already using self-hosted Grafana OSS for metrics visualization, so the learning curve was low; it just made sense to expand on something familiar.
Our top priority was centralized observability. We considered other vendors like Splunk, Datadog, and Logz.io, starting with a POC focused on log migration. But as we evaluated end-to-end platforms, Grafana Cloud stood out for its ease of migration, low training overhead, and strong cost-to-feature ratio. In the end, it was the clear winner.
Let’s walk through your migration. How did you break it into phases, and what were the surprises along the way?
Ambarish: We tackled the migration in five main phases: logs, traces, dashboard visualization, alerting, and finally, metrics. Logs came first, and while configuring Grafana Alloy had a slight learning curve, it ended up making the next phases much smoother. Traces were surprisingly easy to migrate since we were already using OpenTelemetry. All we had to do was update the destination for our existing collector to point to Grafana Cloud.
For visualization, we simply updated the data source in Grafana from our self-hosted Prometheus backend to Grafana Cloud. From the user perspective, the only change was the URL, everything else stayed the same, though they got a newer, more stable platform in the process.
Migrating alerting from our old SaaS tool was more manual, but Grafana Cloud’s wider integration support made it easier to recreate everything, including on-call schedules and escalations.
Metrics was the most complex step. First, we cleaned up and reduced the metrics being sent, removing unused ones, lowering cardinality, and relabeling where needed. This effort alone helped us cut down around 80% of what we were originally sending. We then configured Grafana Alloy to send only the optimized set of metrics to Grafana Cloud. Migrating dashboards and alerts using Grafana’s open source tool, Grizzly, was actually one of the easiest parts of the entire process.
How has the migration changed things for your teams today?
Ipuvi: The biggest impact has been on our Platform Engineering team’s operational overhead, which has dropped dramatically. They no longer need to worry about upgrades, HA/DR planning, or maintaining observability across eight clusters. It’s all handled by Grafana Cloud now.
For our developers, the debugging experience has improved significantly. Previously, they had to jump between three or more tools to find the root cause of an issue. Now, everything is in one place. For example, if an API request fails, the alert includes a direct link to the trace and logs. What used to take 45 minutes to an hour now takes about 10 to 15 minutes.
Were there any cost savings from decommissioning your previous tools? Can you quantify those savings?
Ambarish: By moving to Grafana Cloud, we were able to modernize our entire observability stack without increasing costs. In fact, we’re now saving thousands annually compared to our previous setup, which combined open source tools and various SaaS solutions.
To put it simply, we migrated our full observability stack to the cloud and ended up spending less than before.
Can you share how teams are working differently now with Grafana Cloud? Is there more collaboration?
Ipuvi: The collaboration has become much easier. Instead of handing off a trace ID and log timestamps and asking someone to investigate, we can now simply point them to a unified dashboard that shows everything they need—logs, traces, metrics—in one place. It’s much more self-service, which frees up the platform team and empowers developers to debug on their own.
We’ve also started creating reusable dashboard templates. If one team builds a helpful visualization, other teams can easily duplicate it and plug in their own data. That kind of sharing was possible before, but Grafana Cloud makes it far more seamless.
Another big win is around cost visibility. We now have real-time ingestion dashboards and alerting tied to budget thresholds, so teams can track their own usage and spot anomalies faster. And with help from the Grafana Labs team, we’re working on team-level cost attribution, which will let every team monitor their own observability spend, another step toward true accountability and cross-team ownership.
Looking ahead, what upcoming initiatives are you most excited about, and how do you see them aligning with your team’s or company’s goals?
Ambarish: We’re especially excited about exploring Application Observability, which is a key focus later this year. We’ve already started using Synthetic Monitoring in Grafana Cloud for functional monitoring on our newly launched product, MiQ Sigma, our AI-powered advertising technology, and the experience so far has been promising.
On the engineering side, we’ve moved from local load testing tools like JMeter to running load tests in Grafana Cloud, which is much easier to manage and scale. We’re also exploring browser checks and AI-based optimization for metrics and logs. Over time, this could help us decommission more tools like Cypress and consolidate even further into Grafana Cloud.
