Book a call

About Tracefox

The people who answer your alerts, and how we work.

We do one thing: keep your cloud production running, around the clock. Before you trust us with it, you should know who is on the rota, how many customers they cover at once and how we make the numbers work.

Book a 20-minute call How the rota works
Placeholder: founder portrait, 4:5

Founder

Ken Tan

Founder, [title]. Still on the rota.

[Two or three sentences in the founder’s own words: where they ran production before, roughly how many years on call, the worst night that shaped how Tracefox works, and why they started a company that only does reliability.]

[LinkedIn profile link]

[Add a text transcript below the video]

The rota

Everyone who might answer your alert at 3am.

All in-house, all software engineers. Nobody here works from a script and passes your alert along.

  • Placeholder: photo, 1:1

    [Engineer name]

    [Role, e.g. Senior SRE]

    [Previous work, e.g. ran payments infrastructure on AWS for N years]

  • Placeholder: photo, 1:1

    [Engineer name]

    [Role]

    [Previous work]

  • Placeholder: photo, 1:1

    [Engineer name]

    [Role]

    [Previous work]

  • Placeholder: photo, 1:1

    [Engineer name]

    [Role]

    [Previous work]

How the rota works

The questions we tell you to ask any provider, answered for us.

Engineers on the rota
[N]
Most customers per engineer on shift
[N]
Night shifts per engineer, per month
[N]
Shift length
8 h

  • How we cover 21 shifts at this price

    AI investigates every alert before an engineer picks it up, so the engineer starts from a likely cause rather than a blank screen. That is what lets one engineer cover several customers and still meet the 15-minute window. [Add one sentence on how the rota is shared across customers.]

  • What happens when it gets busy

    [Explain who the backup is, when they are paged, and what happens if two customers have a serious incident at the same time.]

  • How you can check it

    Your monthly report shows our response times against the contract, slowest case included, and how many customers the engineer on shift was covering. If we miss a commitment, the report says so.

Why we only do reliability.

If you run production in the cloud, you’ve probably been pitched by a managed service provider. The offer is generous: hosting, helpdesk, patching, backups, security, migrations, cost reviews, and 24/7 support as well. One supplier, one contract, everything covered.

The trouble is what happens to the 24/7 part. On a menu that long, keeping production running is one line among many, handled by people who are also doing everything else. The alert at 2am gets logged, sorted and passed along. The ticket is closed, and the same alert comes back next month. Nobody did anything wrong, but nothing became more reliable either.

We don’t think that’s a people problem. It’s what happens when a provider promises everything: attention is spread across the whole menu, and the results end up good enough everywhere and excellent nowhere. Reliability is too hard, and matters too much at 2am, to be one line on a menu.

So we built Tracefox to do one thing. We don’t run helpdesks, patch laptops or manage licences. Our engineers spend all 21 shifts a week on production: answering alerts, finding causes and working on why they happen. Doing one thing lets us go deep on it, and lets us put it in numbers you can check.

The usual menu

  • Hosting
  • Cloud resale
  • Helpdesk
  • Patching
  • Licences
  • Backups
  • Security
  • Migrations
  • Cost reviews
  • 24/7 support

Production support is one item, sharing people with everything else.

Tracefox

One thing, all 21 shifts a week.

  • 15 minutes to acknowledge and 30 to work out the cause, in your contract
  • One or two reliability goals every quarter, each with a target and a date
  • A monthly report that shows how we did, slowest response included

How we think about SRE.

Doing one thing lets us hold firm views on it. Keeping production running is an engineering problem, and four ideas shape how we do it.

  • Reliable enough is a business call

    100% is the wrong target: it slows every release and costs more than your users would notice. Your business decides how reliable each service needs to be, measured by what users feel, such as checkouts that succeed.

  • The pager is a means, not the job

    Answering alerts keeps you running, but it doesn’t make you more reliable. So every contract pairs 24/7 cover with one or two reliability goals a quarter, each with a target and a date.

  • There’s rarely one root cause

    Incidents usually need several things to line up: a release, a full quota, a burst of retries. Our incident reports name the contributing factors, so the follow-up covers more than the last thing that broke.

  • Ownership is written down

    Unclear ownership makes incidents longer. Before cover starts we agree a one-page service charter: which services we cover, how, and what’s out of scope.

SRE in the age of AI agents.

AI helps teams ship faster, and more change reaching production means more incidents. AI helps us investigate too, but it earns access to production in stages.

AI levelWhat that meansAt Tracefox
ManualPeople investigate and act; automation only watches.We start above this. AI investigates every alert.
AssistedAI investigates and suggests a cause. A person decides and acts.Every alert. AI hands our SRE the likely cause with its evidence, and they confirm it.
ApprovedAI proposes an exact action. A person approves it before it runs.Known issues only: a runbook you’ve approved runs after our SRE confirms the cause. New issues go to your engineer.
BoundedAI acts on its own within narrow, pre-set limits.Not offered today.
FullAI plans, acts and closes incidents end to end.Not offered. Not every system should get there.

The limits sit outside the AI: a read-only identity, one action in Slack that pauses every runbook, and likely-cause accuracy in your monthly report, so you can see how often it was right. How AI fits into each alert

Green dashboards don’t mean working software.

Monitoring checks for the failures someone predicted. Incidents tend to be the ones nobody did.

  • Healthy servers, stuck users

    A search that returns nothing still counts as a success, and a button that won’t submit never reaches your servers. We look for gaps across whole user journeys, such as sign-up to checkout.

  • Averages hide your biggest customer

    An error rate averaged across everyone can look fine while one important customer can’t log in.

  • Some failures never reach your servers

    Expired certificates, DNS faults and errors hidden by retries can leave every server graph green while users can’t get through.

  • AI is only as good as its data

    Our AI investigates using your metrics, logs and traces, so it can only find what that data shows. Better data means a more precise likely cause for our SRE to check.

You keep your tools, and cover starts from the monitoring you have. In the first 90 days we list what it can’t see and add a heartbeat, so a broken alert pipeline doesn’t look like a quiet night. Closing the important gaps can become one of your reliability goals. Why monitoring isn’t enough

Our SREs are software engineers.

Going deep on reliability means working in code, so everyone on our rota writes it. Anything we write for your services reaches your team for review.

  • Reading the cause, not just the graph

    A dashboard tells you CPU is high. Finding out why at 2am often means reading the stack trace and what changed in the last release, so your engineer hears which change is the likely cause.

  • Seeing what your alerts can’t

    Closing the gaps in what your alerts can see usually means instrumentation: code in your services that reports the metrics, logs and traces an alert needs.

  • Alerts and targets as code

    Alert rules, reliability targets and dashboards usually live in Terraform or config files in a repository. Cleaning up noisy alerts is a code change, reviewed like any other.

  • Runbooks built like software

    A runbook that touches production has to be safe to run twice, limited in what it can change and easy to undo. We build and test runbooks the way you’d build production code.

Three things we hold ourselves to.

  • Own the outcome

    We measure ourselves on whether production gets more reliable, not on how many tickets we close.

  • Straight dealing

    A flat monthly fee with a published starting price, no licence markups or agent fees, and an open list of who we’re not for.

  • People make the calls

    AI finds the cause and automation handles routine work, but a person decides what happens to your production.

What we leave off the menu.

  • Cover on-premises production. We work on AWS, Azure and GCP only.
  • Run a helpdesk, patch laptops, manage licences or support your website. Projects exist only to bring systems into 24/7 cover.
  • Compete on the lowest hourly rate.

When an MSP is the better choice

The company

Registered as
Tracefox Consulting Pte. Ltd.
Office
73 Ubi Road 1 #08-54
Singapore 408733
Clouds
AWS · Azure · GCP
Cover
24/7, all 21 shifts a week

Meet us on a 20-minute call.

Book a 20-minute call You will speak to an engineer from the rota, not a salesperson.
Not ready to talk? Take the two-minute readiness check
Book a 20-minute call