What adoe does for your on-call team

Adoe takes the first response to every alert. It investigates, follows your SOPs, runs the right runbook with your approval, and checks that the fix worked. When it cannot, it hands the incident to a person with the evidence.

One incident, start to finish

An error spike on a checkout service after a deploy. Open each step to see what kept it safe.

Example incident.

  1. Alert received

    Grafana sends checkout_error_rate for service checkout in prod: 7.3% of requests are failing.

    What kept it safe

    Read-only. The alert arrived at your workspace's private webhook address.

  2. Related alerts grouped

    Two more alerts for checkout arrive in the same minutes. Adoe groups all three into one incident, so the team handles one thing, not three.

    What kept it safe

    Read-only. Grouping uses the service, the environment and a 15-minute window.

  3. Investigated

    Adoe finds deploy v2.48.1 shipped 8 minutes before the alert. Logs show errors only on checkout. Cart and payments are healthy. Hypothesis: the deploy, with confidence 0.95 and an impact scope of one service.

    What kept it safe

    Read-only tools only, with a two-minute limit. Impact scope means everything the problem could affect.

  4. SOP matched, checks passed

    The team's SOP checkout-post-deploy-errors covers this alert. Its conditions match: environment prod, service checkout, severity critical. It picks runbook rollback.yml.

    What kept it safe

    The SOP sets the conditions, the confidence needed, and how to verify the fix. Adoe confirms it can run that check before it proposes the runbook.

  5. Approval requested

    Adoe posts the proposed rollback in #checkout-oncall, with the evidence, the target and the impact scope.

    What kept it safe

    The workspace is in approve mode, so nothing runs until a person approves.

  6. Approved by on-call

    The on-call engineer reads the evidence and approves in Slack.

    What kept it safe

    The approval is saved on the incident, with who approved and when.

  7. Runbook ran

    Adoe runs the team's GitHub Actions workflow rollback.yml. Version v2.48.0 rolls out.

    What kept it safe

    The runbook is the team's own workflow. Each step has a time limit and every step is logged.

  8. Verified, then resolved

    Adoe reads the error rate on checkout's own series until it drops below the SOP's threshold: 0.2%. Then it resolves the incident and updates the Slack thread.

    What kept it safe

    If the error rate had not dropped in time, adoe would have escalated to a person instead of resolving.

Capabilities

Built for the work on-call actually does.

Investigation, read-only

Adoe reads recent deploys, the alert's definition in your code, the live check, metrics and logs. It states a likely cause, a confidence score and the impact scope. When no SOP matches, a diagnostic agent looks further with read-only tools across AWS, CloudTrail, Grafana, Splunk and Sensu.

Fewer, better alerts

Repeats are dropped and related alerts become one incident. Adoe ranks your noisiest checks and can propose a tuning change as a pull request, so you fix the alert, not just the incident.

SOPs that check before they act

An SOP is your procedure for one kind of alert. It checks the conditions, picks the runbook, and says how to confirm the fix. Adoe imports SOPs from GitHub and Confluence, and drafts new ones for alerts that have none. An admin approves every draft.

Your runbooks, your tools

A runbook is the steps that make the fix. Adoe runs yours through GitHub Actions, AWS Systems Manager, scripts or SSH. It also has a few built-in AWS actions, such as rebooting an instance, and they always need approval.

Approvals where your team works

Approval requests arrive in the alert's Slack thread with the evidence and the target. In the dashboard you see a preview and can do a dry run first.

Verified before resolved

After a fix, adoe checks the alert's own signal: a metric, an HTTP endpoint or a command. It resolves only when the check passes.

Escalation with the evidence

When adoe cannot verify a fix, has no SOP, or is not confident, it posts its hypothesis and evidence in the alert's Slack thread and follows up there.

Learning from every outcome

Your team marks each outcome: fixed by the SOP, fixed by hand, or a false alarm. Adoe uses this to adjust how much it trusts each SOP, and tracks whether its confidence matches what happens.

Every check, explained

Adoe syncs the checks from Sensu, Splunk and Grafana and explains each one in plain words: what it watches and why it fires. PagerDuty incidents link back to the check that raised them.

Ask from your AI assistant Beta

Read alerts, incidents and SOPs from Claude or Cursor, with read-only access.

See it on an incident from your stack

Book a technical demo. We show each step, and where adoe stops for a person.