How Tracefox differs from a cloud MSP.
A managed service provider usually runs your IT: hosting, helpdesk, patching, licences and projects, with production support as one line on the menu. We only keep cloud production reliable, 24/7, with the response times in your contract.
What you buy, and who answers at 2am.
The MSP column describes what’s typical, not any one provider. Ask yours for their answers in writing.
| Topic | A traditional cloud MSP | Tracefox |
|---|---|---|
| What you buy | A menu: hosting or cloud resale, helpdesk, patching, backups, security, migrations and cost reviews. Production support is one item on it. | One service: 24/7 cover for production on AWS, Azure and GCP, plus reliability work every quarter. Projects exist only to bring systems into that cover. |
| Who answers at 2am | A service desk. A first-line engineer logs the ticket, sorts it by priority and escalates to a second or third line, often shared across many customers. | An in-house SRE, every time. AI has already checked recent releases, related alarms, cloud health and past incidents, so they start from the likely cause. |
| What they can do with code | Varies. First-line staff usually work from scripts and escalate anything unscripted. Ask whether the person who picks up your alert can read the code behind it. | Our SREs are software engineers. They read the stack trace and the last release to find the cause, and write the instrumentation, alert rules and runbooks behind the reliability work, for your team to review. |
| Response times | Set per priority level and negotiated per contract. Ask whether the figure is a target or a commitment, and whether it applies at night. | 15 minutes to acknowledge and 30 to confirm cause and severity, 24/7/365, in every contract. There is no fix-time promise. |
| Access to your cloud | Usually administrative. Many MSPs manage the account itself, and some resell it, so it sits under their organisation. | One read-only identity you create in your own account from our template, scoped to telemetry and configuration. Revoking it is deleting one role. |
| Who changes production | Their engineers, under their change process. More gets fixed without you, and more changes happen that you didn’t see. | Known issues: runbooks you’ve approved, logged in your own audit trail. New issues: your on-call engineer, with the timeline, likely cause and evidence already gathered. |
| Monitoring tools | Often their own monitoring stack, with agents on your servers and licences resold on top. | Yours: CloudWatch, Azure Monitor, Google Cloud Monitoring, Grafana, Datadog or PagerDuty. Nothing to install, no agents and no licence markups. |
| Work on why alerts happen | A closed ticket is a finished job. Fixing the cause is usually a change request or a separate project. | Included. One or two reliability goals each quarter, each with a target and a date, with progress in your monthly report. |
| What you get in writing | Usually ticket updates and a monthly ticket summary. Ask for a sample report. | A likely cause for every alert and a report on the contributing factors for every incident. A monthly report with our response times against the contract, slowest case included, and how often our first likely cause was right. See a sample report |
| Where AI sits | Varies. Many MSPs now sell AI operations. Ask what it can change on its own and who checks it. | AI investigates through the read-only identity and suggests; an engineer decides. |
| Price | A custom quote, often a share of cloud spend or a fee per resource, with licences on top. | A flat monthly fee, from S$1,500 for up to 5 production services. Priced against the at least eight on-call engineers it takes to cover nights in-house. |
| Leaving | Often an annual term. Ask what happens to your monitoring, and to the cloud account if they resold it. | Billed monthly. After three months, 30 days’ notice either side. The runbooks and documentation we wrote stay with you. |
| The catch | Production reliability competes for attention with everything else on the menu. | Cloud only. We hold no standing write access, so new issues come back to your team with the evidence, not fixed. |
When an MSP fits better
Choose an MSP if any of these apply.
- You want one supplier to fix everything, new problems included, without paging your engineers. An MSP with write access will fix more without you.
- You need helpdesk, patching, licence management or end-user IT, none of which we do.
- Production runs on-premises. Our way in is a Cloud migration project, and until then an MSP covers what we can’t.
- You want hosting, the cloud account and support on one bill. We bill for cover and projects, and your cloud bill stays yours.
Ask any provider, including us
Put the answers in the contract.
- Who picks up the alert at 3am, and how many customers are they covering at once?
- Is the response time a target or a commitment, and does it apply on public holidays?
- What access do you hold, in whose account, and how do we revoke it?
- What can your automation change without a person deciding, and where is that logged?
- What do we get in writing after an incident, and every month?
- What work happens on the causes of alerts, and is it in the fee?
- How long is the notice period, and what do we keep when we leave?
Our answers are in the table above and on Security and access.
See the difference on a 20-minute call.
Book a 20-minute call
Bring your MSP’s proposal, and we’ll go through it line by line.
Not ready to talk? Take the two-minute readiness check