Engineers make the calls. AI does the legwork.
Our SREs watch your AWS, Azure and GCP production around the clock through the alerts you already have. AI investigates each alert first, so our SRE who picks it up starts from the likely cause.
What happens when an alert fires.
-
01
An alarm fires
From CloudWatch, Azure Monitor or Google Cloud Monitoring, or from tools you already run such as Grafana, Datadog, PagerDuty and OpenTelemetry. There is nothing to install and no agents (extra software) on your servers.
-
02
AI investigates
It checks recent releases, related alarms, your cloud provider’s health status and past incidents, then hands our SRE the likely cause with the evidence attached.
-
03
Our SRE acknowledges
15 min · 30 minWithin 15 minutes, written into your contract. Within 30 minutes they confirm the cause and how serious it is. This is diagnosis, not a promise that it’s fixed in 30.
-
04
Approved fix, or straight to you
If it’s a known issue with a runbook (a step-by-step fix) you’ve approved, the runbook runs and the run is logged. Anything new goes to your on‑call engineer with the evidence, and you decide what happens next.
-
05
Written up where you work
Likely cause, evidence and what we did, posted in Slack and your ticket. The optional portal shows the same history with live status, reports and runbook approvals; you never have to log in to find out what happened.
AI earns its access in stages.
-
Investigates, always
Read-only, scoped to telemetry and configuration. It gathers releases, related alarms, cloud health and past incidents for every alert, and shows the evidence behind its likely cause.
-
Suggests, our SRE checks
Our SRE checks the likely cause against the evidence before anything happens. If the AI was wrong, that counts against its monthly accuracy figure.
-
Acts only through your runbooks
A runbook runs only for a known issue you’ve approved it for, after our SRE confirms the cause. Anything else goes to your on‑call engineer.
You keep control of production.
| Effect | Tracefox may | Condition |
|---|---|---|
| Allow | Read telemetry and dashboards | Through a read-only IAM role, managed identity or service account that you create in your own account from a template we give you, scoped to telemetry and configuration. |
| Allow | Run a runbook | Only one you’ve approved. When you approve it, you apply its permission to your identity from our template, scoped to that runbook. We never edit the identity, and every run is logged. |
| Deny | Keep running after you pause us | One action in Slack or the portal pauses every runbook we can run until you turn it back on. |
| Allow | Act beyond a runbook | Only through emergency access you grant for a set time, on a path agreed before cover starts, and logged in your own cloud account. |
| Deny | Change anything else | It goes to your on‑call engineer with the evidence, and you decide. |
| Deny | Hold standing write access | Write access exists only as runbook permissions you apply, or emergency access you grant for a set time. |
Revoking our access is deleting the one identity you created. Runbooks and docs stay with you.
- AWS
IAM › Roles › tracefox › Delete- Azure
Managed Identities › tracefox › Delete- GCP
IAM & Admin › Service Accounts › tracefox › Delete
New issues reach your on‑call engineer half solved.
Anything without an approved runbook needs someone who knows your latest code. The handover carries the work we’ve already done, and we stay on the incident with your engineer until it’s closed. Your monthly report counts how many alerts an approved runbook closed and how many came to your engineer.
Card payments failing since 03:41
No approved runbook- Timeline
-
- Alarm: card payment errors above 2%
- AI investigation finished
- Our SRE acknowledged
- Cause and severity 2 confirmed, handed to you
- Likely cause
-
Release 4.13 cut the timeout on calls to your payment provider from 10 seconds to 2. Every failed payment is a timeout on that call. The provider’s response times rose to about 3 seconds at 03:40, which the old limit absorbed.
Medium confidence The timing fits, but we can’t see the provider’s side.
- Ruled out
- Database and queue load, both normal. Traffic, normal for the hour. The 02:00 certificate renewal, which finished cleanly.
- What changed
- Release 4.13, yesterday at 18:05. No config or infrastructure changes since. No open incidents from your cloud provider or the payment provider.
- Next step
- Your call: set the payment timeout back to 10 seconds, or roll back 4.13. We stay on the incident and update this channel every 30 minutes until it’s closed.
Agreed before cover starts
- A one-page service charter: which services we cover and how, what’s out of scope, and how we’ll measure success
- Who on your side makes the call during an incident, and how quickly they pick up our escalations
- An emergency access path you can grant us for a set time, logged in your own cloud account, if you ever want us to act beyond a runbook
- How often we update your channel while a serious incident is open
Between incidents, we work on why alerts happen: one or two reliability goals each quarter, each with a target and a date. How reliability work runs
Reporting
You can check every promise we make.
Our response times are in your contract, and our reports show how we did against them.
What you get
- A likely cause for every alert
- A written report on the contributing factors for every incident
- A monthly service report, walked through with your team in a monthly meeting, including likely-cause accuracy (how often our first likely cause matched the cause our SRE confirmed when closing the alert)
- In that report: our slowest response times as well as typical ones, how many pages nobody needed to act on, how many incidents your users spotted before an alert did, and which follow-up actions are still open
- A quarterly review with your team, where we agree the next reliability goals