Reference · built on requestOperator by FibricIT & reliability

Error Budget

Watches error budget burn against your SLOs and, past policy, proposes a hold on the next deploy or a redeploy of the last good ref.

Request accessPricing ↗

About

An error budget only matters if something happens when it runs low. Error Budget reads your service level objectives and their history from Datadog, service levels defined in New Relic, and the unresolved issues and releases in Sentry. It reads deployments and the head of each release branch from GitHub. From these it computes burn rate over the long and short windows you set and compares it to the policy you wrote: at what burn, for how long, what happens.

When policy is crossed it proposes the response. A pending commit status on the release branch that blocks merges until cleared. A redeploy of the ref before the burn began, which covers a flag change committed to the repository. A page to the service owner. Each one waits for approval, and each one is undone the same way when the budget recovers.

This is a reference listing. It documents what Fibric would read from Error Budget and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Service level objectives from GET /api/v1/slo in Datadog, of type metric, monitor, or time_slice, with target, timeframe, and history
  • Service levels in New Relic, with the SLI's good and valid events and the error budget remaining for the period
  • Unresolved issues per project in Sentry with count, userCount, firstSeen, and lastSeen, and releases with their deploys and environments
  • Deployments, deployment statuses, and the head commit of each release branch from GitHub
  • Burn rate alerts already firing in Datadog or New Relic, so the operator does not raise a second alarm for the same burn
  • Error and latency series behind each SLO, queried as timeseries when the policy needs the raw shape

Proposed actions

  • Target capability: propose a pending commit status, named for the error budget, on the release branch head, so protected branches hold merges until cleared
  • Target capability: propose a deployment of the ref before the burn began through the GitHub Deployments API, including a flag change committed to the repository
  • Target capability: propose a comment on the pull request that shipped the change, with the SLO history and the burn windows attached
  • Target capability: propose a PagerDuty alert event to the service owner when burn exceeds the fast policy you set
  • Target capability: propose replacing the commit status with a success state once burn falls below policy for the recovery window

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Hold merges while the budget recovers

    A 30-day SLO burns past your long-window threshold after a release. Error Budget proposes a pending status on the release branch head; with branch protection on, nothing merges until the owner clears it.

    With Datadog, GitHub

  • Redeploy the ref before the burn

    Sentry shows a new issue with userCount climbing from the release tagged to the last deploy. The operator proposes a deployment of the previous ref and a comment on the pull request with the evidence.

    With Sentry, GitHub

  • Page before the fast burn empties the budget

    New Relic's fast-burn condition shows budget consumed within the hour. The operator proposes a PagerDuty alert to the service owner with the service level and the deploy attached.

    With New Relic, PagerDuty

Requirements

  • SLOs defined in Datadog or service levels in New Relic, each mapped to the GitHub repository and release branch that deploys the service
  • A Datadog application key scoped to read SLOs and query timeseries, or NerdGraph access to New Relic service levels
  • A Sentry token with event:read on the projects behind the services, and releases that carry the deploy's ref
  • GitHub commit status write access and a branch protection rule that requires the operator's status context
  • A written burn policy: long window, short window, burn threshold, and what to propose at each
Authentication
Error Budget owns no API keys. SLO reads use the Datadog, New Relic, and Sentry connectors; deploy reads and approved holds use the GitHub connector; pages use PagerDuty.

Limits

  • Burn rate is computed from the SLO's own definition. A badly defined SLI produces a badly timed hold; the operator does not judge the SLI.
  • Datadog burn rate alerts apply to metric, time slice, and metric-monitor SLOs. Other monitor-based SLOs are read from history only.
  • A hold works through a commit status on a protected branch. Repositories without that protection see the status but can still merge.
  • Flags managed in a separate flag service are out of reach. Only flag changes committed to the repository can be reverted by redeploying.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Error Budget ↗

Questions and answers

What am I approving when the budget burns?
One proposal per policy step: a hold status, a redeploy of a prior ref, a comment, or a page. Each shows the SLO, the burn over both windows, the deploy or release it is attributed to, and the exact API call. Approve, adjust, or dismiss.
What does it record?
For each policy crossing: the SLO history it read, the burn it computed, the proposal, who approved it, the status or deployment ID created, and the moment it was cleared. You can replay any hold from that record.
Does it ever block a deploy by itself?
No. A commit status is posted only after approval, and only branch protection you configured turns it into a block. It never force-pushes, closes pull requests, or changes protection rules.
Ask about Error Budget

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy