Skip to content
NOFire.ai

Autonomous on-call

Agents take every page first and resolve the alert. Engineers get paged only when needed.

Investigations list: 178 in the last 30 days with an activity chart, and today's alerts from PagerDuty and Grafana, most resolved with nobody paged

Every page reaches an agent first

PagerDuty and Grafana alerts reach the on-call agent before a person is paged.

On-call agent thread in #payments-oncall: the PagerDuty alert CheckoutHigh5xx on checkout-api in prod-eu, the first steps the agent ran and the service context

Root cause with the supporting evidence

Each finding links to the evidence behind the finding, and rejected hypotheses stay listed.

See the production context graph
What we found for INV-41207: the pool limit change in v4.18.2 starved checkout-api of orders-db connections, 85% confidence, with how the incident happened and the evidence chain

Known fixes run within your policy

Each step starts from the right production context and your runbook. Policy decides: allowed, needs approval or denied.

On-call agent thread: the likely cause, PR #2841 cutting DB_POOL_MAX and row locks held by pid 48211, then actions under policy: a restart and a scale allowed and run, and ending pid 48211 waiting for approval by the Payments on-call

Resolved, with a person only where policy asks

The on-call engineer approves in Slack and reads a summary instead of a page.

Thread in#payments-oncall
NOFire AI APP 17:30

on-call agent asks to run an action

Terminate blocked transactionorders-db in prod-eu · pid 48211 · locks held 9 mincheckout-api · Critical · owner PaymentsPolicy payments-primary: needs approval by the Payments on-call
Approved by Maya Chen at 17:33. pid 48211 ended at 17:33. The locks on orders-db are free.
Maya Chen 17:45

@NOFire AI is checkout healthy again?

NOFire AI APP 17:45

Yes. The 503 rate is 0.1% at 17:45, back at the 7-day baseline, after the rollback to v4.18.1 at 17:41. CheckoutHigh5xx resolved at the source at 17:45.

When an alert becomes an incident

Declare from Slack and work from one investigation the whole team shares.

See incident response

What an AI SRE needs in production

NeedBuild in-houseWith NOFire AI
ContextEach responder rebuilds context from dashboards and chatServices, owners, dependencies and recent changes from the production context graph
EvidenceA summary someone re-checks by handEach finding links to the evidence behind the finding
ActionsScripts with broad credentialsPolicy per agent, service and environment: allowed, needs approval or denied. Every action is recorded.
Cost of ownershipA team to build integrations, retrieval, review and an audit trailIncluded in the platform

Frequently asked questions

What is an AI SRE?

An AI SRE is the first responder for an alert. NOFire AI reads the production context graph, investigates with evidence on every finding and runs the steps your policy allows.

How does NOFire AI find the root cause?

NOFire AI forms hypotheses from the alert and the production context graph, then tests each one against metrics, logs, deploys and config changes. Rejected hypotheses stay listed with the evidence against them.

Does NOFire AI change production?

Investigations only read. Each next step starts from the service context and your runbook. Your policy decides: allowed, needs approval or denied. Approvals happen in Slack, and every action is recorded.

Where do our logs, metrics and traces go?

Logs, metrics and traces stay in your tools. NOFire AI queries them when an investigation needs them and stores the findings with a copy of each query result, credentials removed.

Which plans run actions?

Both plans. Pay as you go and Enterprise include policy, approvals in Slack and the record of every action.

Put AI agents to work on production, safely.