The questions we get asked before the call.
What happens when something breaks.
Does the 30-minute target mean it’s fixed in 30 minutes?
No. Within 30 minutes an engineer has worked out the cause and how serious it is. Known issues are then fixed by runbooks you’ve approved. New issues go to your team with the evidence, because a person on your side decides what changes in production.
Who picks up the alert, a person or a bot?
A person, every time. AI investigates first, so the engineer who picks up the alert starts from a likely cause with the evidence attached. An in-house engineer acknowledges within 15 minutes and works out the cause and severity within 30, 24/7. What happens when an alert fires
Which alerts do you respond to?
Every alert from the services in your service charter, the one-page agreement we write before cover starts. It lists which services we cover and how, and what’s out of scope. Alerts reach us from CloudWatch, Azure Monitor and Google Cloud Monitoring, or from tools you already run such as Grafana, Datadog and PagerDuty.
Isn’t this just an outsourced on-call desk?
No. Alongside answering alerts, every contract includes reliability work: each quarter we agree one or two goals with you, such as fewer pages that nobody needed to act on, and report progress every month. How we differ from an MSP
Are your SREs software engineers?
Yes. Everyone on our rota writes code, because finding a cause often means reading a stack trace and what changed in the last release. The reliability work is code too: instrumentation, alert rules, reliability targets and runbooks. Anything we write for your services comes to your team to review. Who answers your alerts
Do we still need our own on-call engineer?
Yes, but only for new issues. Known issues are handled by runbooks you’ve approved. New issues need someone who knows your latest code changes, so they go to your engineer with the evidence and a likely cause already worked out.
What happens when it’s something you’ve never seen before?
It goes to your on-call engineer with the timeline from the first alarm, the likely cause with the evidence and how confident we are, what we checked and ruled out, what changed recently, and a suggested next step to accept or reject. We stay on the incident with them until it’s closed. What the handover includes
What happens if an incident runs for days?
We stay on it for as long as it’s open: watching, keeping your channel updated and keeping the timeline for the report. Engineering work to fix the underlying cause sits with your team, or with a project if you’d like us to do it, and we agree that in writing before any extra work is billed.
What do we get in writing?
A likely cause for every alert, posted in Slack and your ticket. A written report on the contributing factors for every incident. A monthly service report showing our response times against the contract, slowest case included, and how your reliability goals are going. And a quarterly review where we agree the next goals. See a sample monthly report
What we can see, what we can change.
Do you need write access to production?
Only the narrow access each approved runbook needs, and every run is logged. Everything else is read-only, scoped to telemetry and configuration, and there is no standing write access to production.
What do you need from us to get started?
One identity you create in your own cloud account from a template we give you: an IAM role on AWS, a managed identity on Azure or a service account on GCP. The template is read-only, covers telemetry and configuration, and you can read it before you run it. A Slack channel and a ticket queue for our answers to land in. And your alerts pointed our way from the tools you already use. There is nothing to install and no agents on your servers.
Do we have to write the IAM policy ourselves?
No. We give you a template with the permissions already written: a CloudFormation stack or Terraform module on AWS, and the equivalent for Azure and GCP. You read it, run it in your own account and send us the identity’s name. It’s the same way monitoring and security tools connect to a cloud account. If your security team wants a line changed, we work from their version.
How do we check what you’ve done?
In your own cloud’s audit log: CloudTrail on AWS, the Activity Log on Azure and Cloud Audit Logs on GCP. Because we work through an identity in your account, every action it takes is recorded somewhere you hold, not us. Every runbook run is also posted in Slack and your ticket.
Can we stop you from running anything?
Yes. One action in Slack or the portal pauses every runbook we can run until you turn it back on. Anything beyond a runbook already needs a person on your side to approve it.
What if we want you to fix something beyond a runbook during an incident?
You can grant us access for a set time, recorded in your own cloud account like everything else, and we agree that path before cover starts. We never hold standing write access.
How do we revoke your access?
Delete the identity you created. In your cloud console that is one action, and it removes the identity’s permissions with it: IAM › Roles › tracefox › Delete on AWS, Managed Identities › tracefox › Delete on Azure, or IAM & Admin › Service Accounts › tracefox › Delete on GCP. The runbooks and documentation we wrote for you stay with you.
What the AI does, and where it stops.
What does the AI actually do?
For every alert it checks recent releases, related alarms, your cloud provider’s health status and past incidents, then hands the engineer the likely cause with the evidence behind it. It works through the read-only identity, which covers telemetry and configuration, so it can look at your metrics, logs and settings but not change anything. Where AI stops
Can the AI change production on its own?
No. A runbook runs only for a known issue you’ve approved it for, and only after an engineer has confirmed the cause. Anything else goes to your team. The limits are set outside the AI rather than by asking it to behave: a read-only identity, answers that go only to your own Slack channel and ticket, and screening for personal and secret data before anything is posted.
How do we know the AI got it right?
An engineer checks every likely cause against the evidence before anything happens. Your monthly report shows likely-cause accuracy: how often the first likely cause we posted matched the cause our engineer confirmed when closing the alert, so every wrong AI suggestion counts against that figure.
What does the AI do with our logs?
It reads your logs, metrics, traces and alerts through the read-only identity to investigate each alert; that identity cannot read the data your services store. Your contract sets out which data it reads, where it’s processed, how long anything is kept and what’s removed before it’s stored. Every action it takes is logged in your own cloud account.
One flat fee, and what it covers.
What does the flat fee include?
24/7 cover with the 15- and 30-minute response times in your contract, AI investigation of every alert, runbooks you’ve approved, a likely cause for every alert and a written report for every incident, one or two reliability goals each quarter, a monthly report and quarterly review, and onboarding. No licence markups and no agent fees. Projects are quoted separately at a fixed fee.
What counts as a production service?
Something your users depend on that is deployed and alerted on separately, such as an API, a web app, a background worker or a database. We agree the list with you in the service charter before cover starts. If you’re not sure how many you have, a rough number is fine for the call.
What if our alerts are very noisy?
At onboarding we agree a normal alert volume for your services. If it stays well above that, we run a joint clean-up with your team instead of charging more.
When does billing start?
When cover starts. The 20-minute call and the service charter come before that and cost nothing.
Is there a minimum term, and how do we leave?
Cover is billed monthly. After the first three months, either side can end it with 30 days’ notice. Leaving is deleting the identity you created, and the runbooks and documentation we wrote for you stay with you.
Do you work with teams outside Singapore?
Yes. We’re based in Singapore and quote in Singapore dollars, and we cover production on AWS, Azure and GCP in any region. Cover runs 24/7, so your time zone doesn’t change what you get.
Who we’re for, and how cover starts.
Do you cover on-premises production?
No. We cover production on AWS, Azure and GCP only. If you’re still on-premises, a Cloud migration project moves production across, and 24/7 cover starts once it’s there.
We don’t have alerting yet. Can you still cover us?
Not yet. Cover works through your alerts. Our alerts guide covers how to set up alerting that’s worth answering; once it exists, take the readiness check or book a call. Read the alerts guide
We already have SREs. Is there any point?
If you have three or more, probably not: you can staff a rota yourselves. If one or two engineers carry the pager alongside their day job, that’s who we’re for. We take all 21 shifts a week, and they get only the new issues, with the evidence already gathered.
Do we have to replace our monitoring tools?
No. Keep Grafana, Datadog and PagerDuty, along with your cloud provider’s own monitoring.
Do we have to use the portal?
No. Likely causes, evidence and reports go to Slack and your ticket. The portal is there if you want live status, incident history and runbook approvals in one place.
How long until cover starts?
Cover starts from the alerts you already have, once you’ve created the read-only identity from our template and your alerts are reaching us. Over the first 90 days we learn your systems, list what your alerts can’t see, offer a starter pack of runbooks for your approval and agree your first reliability targets. The 90-day plan
Will you tell us if we’re not a fit?
Yes, on the call, and the list is public: production on-premises, no alerting yet, wanting a provider to hold write access and fix production, or three or more SREs already. The readiness check asks the same questions we would.