Datadog SLOs vs Nobl9: a practitioner's evaluation

A Service Level Objective (SLO) is a service reliability target expressed as a percentage over time, such as 99.9% of requests succeeding over 30 days. The error budget is the remaining 0.1% an SLO is allowed to fail before it's considered breached.

Datadog keeps that budget beside the metrics, traces, and dashboards teams already use, so an engineer can move from a burning budget to the trace that explains it without switching tools. This article explores these features in detail.

Operations teams usually face a couple of challenges when scaling their SLO programs. First, Datadog SLOs only measure the data collected directly by Datadog. For example, signals from Splunk, Prometheus, or a data warehouse must be forwarded to DataDog as a billable custom metric, which becomes expensive at scale. Second, the rolling window cap is 90 days, which limits how far back a live SLO can look. Third, they lack the advanced features that specialized SLO platforms provide.

The presence of these constraints doesn’t suggest that users must stop using DataDog SLOs. A better approach is to use them for what they do well and complement them with a specialized tool that can collect data from any monitoring tool and offer advanced SLO functionality.

This article explains Datadog's native SLO features in depth and walks through additional use cases enabled by Nobl9, a specialized SLO platform that augments third-party monitoring tools and enables entirely new ways to manage SLOs.

Summary of Datadog SLO features and the augmented functionality via a specialized tool

The table below summarizes six Datadog SLO concepts this article will explore in more detail.

Datadog SLO types and error budgets

Datadog supports three SLO types, each designed for a different signal shape.

1. Metric-based SLOs use a ratio of good events to total events, such as successful requests divided by all requests.
2. Monitor-based SLOs measure the uptime of an existing monitor, so they track the same data the monitor watches.
3. Time-slice SLOs score each short window as good or bad and define good minutes directly, so they require no separate monitor, reducing setup for new SLOs.

Error budget alerting combines a longer window (hours) with a shorter one (minutes), and budget alerts trigger when spending reaches a threshold, such as 75% of a 7-day budget. Note that burn-rate alerts for monitor-based SLOs evaluate only the overall SLO. Metric-based and time-slice SLOs instead support group-level burn alerts, so individual regions or endpoints can trigger their own alerts.

Choose the SLO type up front, as it determines the available alert granularity.

For example, a metric-based SLO could track successful checkout API calls over total checkout API calls, scoped to one service tag, with a 99.9% target over a 30-day rolling window. Datadog computes that ratio continuously. The error budget appears as a running tally of allowed failures, letting engineers see remaining allowed failures rather than just percentages.

SLO-as-code and single-pane investigation

Datadog exposes the datadog_service_level_objective Terraform resource, which places SLOs in pull requests alongside other infrastructure changes. Teams review SLO changes alongside firewall rules and autoscaling policies, using existing CI pipelines. A minimal version of that resource looks like this:

The resource block reads like any other piece of Terraform-managed infrastructure, which is what makes it easy to fold into an existing review process instead of building a separate one just for reliability targets.

Staying within Datadog pays off during incidents. When metrics, logs, APM traces, monitors, and incident management all live in one tool, an SLO breach is one click from the trace or log line that caused it, with no context switch and no second vendor in the loop. For teams fully invested in Datadog, this unified workflow is efficient, and warrants consideration when building a reliability program.

Where native Datadog SLOs hit scale limits

SLOs only measure signals the platform can access. Datadog SLOs use only data collected by Datadog, so a log-based SLI from Splunk, for example, must be forwarded to Datadog first. This typically requires forwarding the signal as a custom metric. A Prometheus histogram or a BigQuery batch job has the same requirement because data must be transferred before an SLO can be supported.

The 90-day cap on rolling windows is a second constraint, though it's narrower than it appears. That cap applies only to the live rolling evaluation window. Datadog's calendar view shows up to 12 months of historical SLO status for metric-based and time-slice SLOs, covering most quarterly and annual reporting needs. Monitor-based SLOs don't have that calendar view, so reports spanning them require assembly outside the SLO view. Neither limit is a defect. Both happen when an SLO program outgrows a single team operating within one tool, when spanning additional data sources, teams, or acquisitions with existing stacks.

A concrete version of the forwarding problem: a Prometheus histogram tracking p99 latency for a service that never sent data to Datadog needs a metrics pipeline built specifically to relay it in. This metric then competes for the same custom metric quota as other forwarded data.

A concrete version of the reporting problem: a team relying on a monitor-based SLO that doesn't provide a 12-month calendar view still needs to stitch together monthly Datadog API exports for annual SLA reporting.

Addressing these limits doesn't require leaving Datadog. Instead, add a layer above for signals, targets, and governance beyond a single tool's SLO coverage. The four cases below integrate Nobl9, a dedicated SLO platform, with existing Datadog instrumentation.

Governing SLOs across teams and agents

Version control alone doesn't solve governance when dozens of teams share thousands of SLOs. Nobl9 packs SLOs, data sources, budgeting methods, and alert policies into YAML objects aligned with the SLO lifecycle.

sloctl applies and verifies the objective in the same way kubectl applies a manifest.

Agent integration extends this capability. The Nobl9 MCP (Model Context Protocol) server exposes list, define, and update operations to coding agents, including Claude, Cursor, and Gemini CLI, so teams can manage an SLO in natural language.

Governance scales through organizational structure rather than per-object configuration. Nobl9 projects group services, SLOs, data sources, and alert methods, and role-based access control assigns organization and project roles so each team owns its SLOs without touching another team's. Labels organize SLOs across projects. Alert methods are centralized rather than embedded into each objective. The Reliability Roll-up report provides leads with a single view of SLO health across the entire environment, including Datadog-sourced SLOs.

For instance, that might mean a payments team holding write access to its own project while a platform reliability lead holds read access across every project labeled tier:critical, without either team needing a shared Datadog account role rewritten to grant it. The MCP server extends the same boundary to agents: a payments engineer's Claude session can list and update SLOs inside the payments project without ever seeing what a separate team's project contains.

Key insight: If a reliability program lives entirely inside Datadog account roles, this scaling problem may not have hit yet. Once dozens of teams share thousands of objectives, projects, labels, and RBAC turn a flat list into a portfolio someone can actually own.

Nobl9 Reliability Roll-up report showing SLO health rolled up across multiple projects and teams, including objectives sourced from Datadog

Conclusion

The right SLO governance choice depends on organizational context. Consider who owns the reliability target portfolio and where each SLO runs. Small teams fully invested in Datadog benefit from the simplicity and low overhead of native SLO management. As teams scale, dedicated platforms like Nobl9 are more valuable.

A small team running one fully Datadog-instrumented service faces no composite SLO or cross-team RBAC challenges. Adding Nobl9 prematurely means paying for unnecessary governance. But when multiple teams span projects, programs, and business units, robust SLO governance is necessary.

The choice comes down to whether SLO governance should live in a single tool or in a layered platform that spans multiple tools.