Skip to content
SteadyNines

AI that acts before SLOs break.

SteadyNines watches the error budget burn rate of every SLO and stops the burn while there’s still budget left. Rollbacks, scaling and code fixes, approved by your engineers from Teams, their phone or VS Code.

Book a pilot Watch the 3-minute loop

What is SteadyNines?

SteadyNines is a pre-breach SLO management platform. Most SLO tools tell you when an SLO has already broken. SteadyNines acts on burn rate, the speed at which an error budget is being spent, so the problem is stopped while budget is still left. It connects what operations sees with what engineering changed, then fixes the cause in code.

  • 43 minAll the failure a 99.9% SLO allows in 30 days
  • 14.4×A burn rate that spends it in about two days
  • BeforeWhen SteadyNines acts

By the time you’re paged, the budget is gone.

Today’s toolsWhat they doWhen they start
SLO and observability toolsMeasure the burn and alert someoneAfter the threshold
AI SRE toolsInvestigate the incidentAfter the page
Coding agentsFix what a person says is brokenAfter someone notices
SteadyNinesStops the burn and fixes the causeWhile budget is left

One loop, from first burn to final fix.

See how it works

  1. Detect.

    SteadyNines tracks burn rate on every SLO over short and long windows and opens a situation the moment it crosses your threshold.

    card-auth-api · availability 99.9%Situation opened
    Burn rate14.4×
    Budget left71%
    Alerts fired0

  2. Trace.

    The Context Graph links the burn to the deploy, config change, dependency or ticket behind it, with evidence.

    Context Graph · traceCause found
    1. SLOcard-auth 99.9% / 30 d
    2. Servicecard-auth-api
    3. Dependencyissuer-gateway · retries ×6 · errors 0.9%
    4. Deploy#4821 · issuer retries · 02:11
    5. Commit7c2e91a

  3. Stop.

    The AI SRE proposes the safest fix (roll back, scale, restart, fail over, patch) and sends it to on-call for one-tap approval.

    Microsoft Teams · #cards-oncallAI SRE
    Burning 14.4×card-auth-api · availability 99.9% / 30 d
    Budget left71%
    Gone in~2 days
    Since02:14
    Proposed action

    Roll back card-auth-api to #4820

    Expected burn after: < 1×.

  4. Fix.

    The AI Engineer drafts the code fix in VS Code, with the trail from SLO to commit attached.

  5. Learn.

    The situation and its outcome are stored. Next time, SteadyNines starts from what worked.

    Learning Engine · situation record #0193
    1. First time · 04 MarAsk42 min to stop
    2. Second time · 11 AprAsk6 min to stop
    3. Third time · 19 MayRun and report40 s to stop

One SLO, burning to steady, in three minutes.

Burn rate crosses the line. The AI SRE asks in Teams. An engineer taps approve. The fix lands in VS Code with the trail attached. The SLO recovers. No slides.

steadynines — card-auth-api03:00
Play · 03:00
  1. 00:00Burn rate crosses the line
  2. 00:40The AI SRE asks in Teams
  3. 01:20An engineer taps approve
  4. 02:00The fix lands in VS Code
  5. 02:40The SLO recovers
Read the transcript +

At 02:14 the availability SLO for card-auth-api starts burning at 14.4 times its sustainable rate. At that pace the 30-day error budget is gone in about two days. No alert has fired yet; the SLO is still met.

SteadyNines opens a situation. At 02:15 the Context Graph ranks the likely cause: deploy #4821, which changed how retries to the card issuer work, went out minutes before the burn started.

At 02:16 the AI SRE proposes rolling back to deploy #4820 and asks the on-call engineer in Microsoft Teams, with the evidence and the expected effect: burn under 1× after the rollback.

At 02:18 the engineer taps approve. The rollback runs. At 02:19 the burn is under 1× and the incident record is written with the timeline. 71% of the budget is still left.

At 02:40 the AI Engineer drafts the fix in VS Code with the SLO, the deploy, the commit, a patch and tests. The developer reviews it in the morning and merges it at 09:12 like any pull request.

The situation is stored. The next time the same pattern starts, SteadyNines starts from what worked.

Six parts, one loop.

You decide how far it goes on its own.

The head of operations sets an autonomy level for each type of situation. New situations start at Propose or Ask. Once your team has approved the same fix enough times, you can let SteadyNines run it and report back. Autonomy is earned.

Autonomy Controls
SteadyNines · Autonomy level
Ask · what on-call sees

“Ready to roll back deploy #4821. Approve?”

Nobody changes their tools.

Microsoft Teams, Mobile, VS Code, OpenTelemetry, Azure DevOps, AWS

All integrations

Built for estates that can’t go down

SteadyNines control plane

SteadyNines cloud on AWS, or fully on-premises.

  • Context Graph
  • Learning Engine
  • AI SRE and AI Engineer
  • Audit trail, exportable
Your network boundary
Runs every actionSteadyNines executorNo inbound access needed. Rollbacks, scaling and restarts happen here.
Your systemsKubernetes, VMs, databases, pipelines
OptionalOn-prem models, no external calls
PeopleSSO via SAML or OIDC. Role-based approvals in Teams, mobile or VS Code.
Where actions runInside your estate, through the SteadyNines executor
Language modelsClaude via AWS Bedrock, OpenAI, Azure OpenAI, or on-prem models
AccessSingle sign-on and approval rights by role
AuditEvery proposal, approval and action recorded
Visit the trust centre

Steady is a decision,not luck.

We spent 17, 14 and 10 years building AIOps products for major managed service providers. The enterprises we worked with kept asking for the same thing: not a better alert, but a way to keep their SLOs met. SteadyNines is what we built with them.

Meet the founders

Questions

What is SteadyNines?

A pre-breach SLO management platform that acts on error budget burn rate to stop SLO breaches before they happen, across operations and code.

What is error budget burn rate?

How fast an SLO spends its error budget compared with the pace that would spend it exactly over the window. At 1 the budget lasts the window; at 10 it’s gone ten times faster.

How is it different from Nobl9 or Datadog SLOs?

Those tools measure SLOs and alert. SteadyNines also acts: it stops the burn and fixes the cause.

How is it different from AI SRE tools?

They usually start once an incident is paged. SteadyNines starts on burn rate, before breach, and carries the work through to the code fix.

Does it act without approval?

Only for situation types you’ve allowed. Everything starts at Propose or Ask.

Can it run on-premises?

Yes. The executor runs inside your estate, and on-prem models are supported.

Who is it for?

SRE, platform and operations teams at enterprises, global capability centres and managed service providers.

How is it priced?

Annual subscription based on the estate under management. See pricing →

Keep your nines steady.

Start with one SLO. See the loop work in your estate in two weeks.

Book a pilot