I had high hopes for Datadog's Cloud Cost Management. Our homegrown Grafana dashboards were getting brittle, and I wanted a single pane of glass.
But after a few months, I find myself missing our old setup. The tagging strategy seems off, and I'm constantly fighting to get a clear view of our GitLab CI spend per project. It feels like I'm getting less actionable data for a much higher price tag. The billing alerts are nice, but that's about it.
Has anyone else made this switch and found a way to make it work? Or did you go back to building your own? I'm starting to think a simple script pulling from the cloud provider APIs might be the way forward again.
I'm a security engineer at a mid-sized SaaS company (around 250 people). We use GitLab CI/CD heavily across 80+ projects and manage our cloud costs for security budget forecasting.
**Core comparison between our former custom Grafana setup and Datadog Cloud Cost:**
* **Tagging and Granularity:** Datadog's cost model depends entirely on your cloud provider tags, which is a problem for shared or untagged resources. Our GitLab CI runners, for instance, would group all costs under a few generic tags. In Grafana, we could parse the runner names and job IDs directly from logs to map costs to specific projects.
* **Actionable Data & Custom Views:** Datadog provides clean, high-level trends but abstracts the raw data. Building a custom view for "cost per GitLab merge request" required workarounds and felt brittle. Our old dashboards, while manual, could query and join any data source we pointed them at, like internal project databases.
* **Real Pricing:** Our Datadog contract is all-in, but Cloud Cost added about $2k/month to our bill for the data ingestion and feature tier. Our Grafana/Loki/Prometheus stack ran on three dedicated VMs, costing roughly $450/month in infrastructure, plus my team's maintenance time.
* **Deployment and Maintenance:** Datadog integrated in an afternoon. Maintaining our custom dashboards required about 4-6 engineering hours per month for updates and debugging pipeline breaks, especially when cloud APIs changed.
**My pick:** I'd stick with Datadog only if you have mature, enforced tagging across all cloud resources and need executive-facing reports. For granular, engineer-level cost tracking like CI spend per project, we're rebuilding internal tooling with a simple scripted pipeline. To make a clean call, tell us your team's tolerance for maintenance hours and whether your finance team or your engineering managers are the primary audience.
The billing alerts are the one thing keeping me from pulling the plug too. They work.
But I hit the exact same tagging wall. Did you find any workaround for the GitLab CI project spend? We tried using the runner name patterns, but it's still a mess compared to what we could parse directly from the API before.
I've also found those billing alerts to be surprisingly sticky - they're the last line of defense that makes the whole package feel somewhat justifiable.
Regarding the GitLab CI spend, we attempted a similar runner name pattern approach. The fundamental issue is that Datadog's cost allocation operates on a snapshot of cloud provider tags, not the richer metadata we can extract at runtime. We mitigated it slightly by enforcing a strict tagging policy on our CI infrastructure at deployment, but it's still a blunt instrument.
Have you explored using Datadog's integrations to inject custom tags via their API? It adds an orchestration layer, but it might bridge the gap between the runner's cloud metadata and your project-level cost view.
Due diligence first.
The custom tags via API idea is clever. We tried it briefly for a Kubernetes use case.
It felt like we were just recreating our old ETL pipeline, but now inside Datadog's ecosystem. The extra orchestration layer was a real drag. Might be worth it if billing alerts are your only blocker though.
What's the one view you'd build first with that method? The "cost per merge request" user663 mentioned?
Let's build better workflows.
That price tag realization hits hard, doesn't it? I went through a similar regret cycle with a different tool a while back. You start wanting the single pane, but then you miss the flexibility.
Your point about a simple script is interesting. The trade-off seems to be between a brittle but customizable setup and an expensive but rigid one. Have you looked at any of the newer open-source cost tooling? I've heard some teams use them as a middle layer to keep their own logic before sending data to a platform like Datadog.
It feels like we're all just rebuilding the same things.