# How Razorpay Cut Its Metrics Bill by 62% Without Losing a Dashboard

DevFeed: [How Razorpay Cut Its Metrics Bill by 62% Without Losing a Dashboard](<https://devfeed.tech/articles/how-razorpay-cut-its-metrics-bill-by-62-without-losing-a-dashboard-24039.md>)

Original publisher: [Read original article](<https://engineering.razorpay.com/how-razorpay-cut-its-metrics-bill-by-62-without-losing-a-dashboard-2a7d5467df37?source=rss----6407ad2e59af---4>)

Author: Dhairya Mehta

Published: 2026-08-24T10:25:21Z

Content type: article

Language: en

Sources: [Razorpay Engineering - Medium](<https://devfeed.tech/sources/razorpay-engineering-medium.md>)

Topics: [Monitoring](<https://devfeed.tech/topics/monitoring.md>), [migration](<https://devfeed.tech/topics/migration.md>), [incident](<https://devfeed.tech/topics/incident.md>), [Self-hosted](<https://devfeed.tech/topics/self-hosted.md>), [telemetry](<https://devfeed.tech/topics/telemetry.md>)

Tags: [cost](<https://devfeed.tech/tags/cost.md>), [high-availability](<https://devfeed.tech/tags/high-availability.md>), [incident](<https://devfeed.tech/tags/incident.md>), [metrics](<https://devfeed.tech/tags/metrics.md>), [migration](<https://devfeed.tech/tags/migration.md>), [monitoring](<https://devfeed.tech/tags/monitoring.md>), [self-hosted](<https://devfeed.tech/tags/self-hosted.md>)

## AI overview

Razorpay reduced daily metrics ingestion from about 450 billion to about 170 billion samples, cutting its metrics bill by 62% without deleting useful dashboards or breaking alerts. The article describes an audit conducted during a planned migration from a self-hosted VictoriaMetrics cluster to a managed monitoring platform, covering scrape intervals, duplicate high-availability scrapes, and high-cardinality metrics.

## Source excerpt

Contributor: Saijal Shrivastava We cut our metrics ingestion by 62% without deleting a single useful dashboard or breaking an alert. Daily ingestion dropped from about 450 billion samples to about 170 billion. The surprising part was not one large optimization. It was three simple discoveries hiding in plain sight: Scrape intervals can multiply ingestion. High-availability scraping can silently send duplicate metrics when deduplication happens only at the storage layer. High-cardinality metrics are easy to create, expensive to keep, and hard to remove without ownership. We found these while preparing to move from a self-hosted VictoriaMetrics cluster to a managed monitoring platform. The migration started as a reliability project. The audit turned it into a cost and signal-quality project. We were not just moving monitoring data. We were moving years of accumulated assumptions about what was worth scraping. The Incident that Forced the Audit Our self-hosted VictoriaMetrics cluster had served us well for years. Then one storage node hit EBS volume throttling. Traffic shifted to the remaining storage nodes, the extra load pushed another node past its limits, and the storage layer collapsed. We saw the same pattern whenever a storage node became unavailable: traffic redistributed, the remaining nodes overloaded, and the cluster moved back toward failure. The collection, ingestion, and query components were still running, so the system looked alive from the outside. But the storage layer was down. Metrics stopped being persisted. Dashboards went blank. Alerts stopped evaluating. Recovery took hours. Teams fell back to logs and manual checks to understand production health. Figure 1: Cascading failure in the pipeline That made the reliability problem obvious. We needed a more stable monitoring architecture. We evaluated several options: self-hosted designs with disaster recovery built in, and fully managed alternatives. But when we priced the managed options, one number