Skip to main content
Managed IT

IT Service Level Agreements Singapore: What to Demand and What's Actually Negotiable

24 January 2026·13 min read
Two colleagues reviewing a service level agreement document with a laptop dashboard and network switch on the table
TL;DR

A defensible Singapore managed IT SLA defines response time and resolution time separately for each priority level — a 1-hour response commitment means little if resolution time is left undefined. A 99.9% uptime SLA (the most commonly offered) still permits 8.76 hours of downtime per year, and providers often exclude planned maintenance or third-party failures from that number. Typical SLA credits run SGD 50–200 per response breach and SGD 100–500 per hour of uptime breach — insist on the right to terminate without penalty after 3 P1 breaches in 12 months.

Most Singapore businesses sign managed IT contracts without reading the SLA carefully. The monthly fee looks reasonable, the services list sounds comprehensive, and the provider seems responsive during the sales process. Then something breaks at 7pm on a Friday, and the business owner discovers that "24/7 support" means a ticketing system monitored from an overseas call centre, that "best effort" response means nothing is actually guaranteed, and that the SLA they signed offers no remedy when a breach occurs.

This is not an unusual story. It is one Aggasys hears regularly when businesses come to us after a bad experience with a previous provider. The problem is almost never the technical capability of the IT team. It is the contract that was never properly negotiated.

This guide explains what a good IT SLA looks like in Singapore, which clauses actually protect you, which are negotiating theatre, and what questions to ask before you sign anything.

Response Time vs Resolution Time: The Distinction That Changes Everything

The single most important distinction in any IT SLA is between response time and resolution time. These are not the same thing, and providers who conflate them — intentionally or not — are giving you a weaker guarantee than you think.

Response time is how long it takes the provider to acknowledge your ticket and assign it to an engineer. In practice, this means: how long until you get a reply that says "we've seen this and we're looking at it."

Resolution time is how long it takes to actually fix the problem.

An SLA that promises a 1-hour response time sounds fast. But if it says nothing about resolution time, a provider can acknowledge your ticket within an hour and then take five days to fix the problem without technically breaching the agreement.

Good SLAs define both — separately — for each priority level. A realistic but protective SLA for a Singapore SME might look like:

Priority Response Time Resolution Time
P1 (Critical — business down) 30 minutes 4 hours
P2 (Major — significant impact) 1 hour 8 hours
P3 (Moderate — workaround available) 4 hours 24 hours
P4 (Minor — no operational impact) 8 hours 5 business days

When reviewing an SLA, check whether resolution times are defined. If they are not, ask for them. If the provider refuses to commit to resolution times, treat that as a signal.


What "24/7 Support" Actually Means in Singapore

"24/7 support" is one of the most frequently misrepresented claims in managed IT contracts. Before signing, ask these questions:

Who answers at 2am? Is it a local Singapore engineer, an overseas call centre, or an automated ticketing system? There is a significant difference in the quality of help you receive from a senior engineer in Singapore who knows your systems versus a first-line support agent in another time zone reading from a script.

What can they actually do at 2am? Some providers offer 24/7 remote support but have no capacity for on-site response outside business hours. If your issue requires a physical presence — a failed server, a network outage, a physical security incident — remote support at 2am is not useful.

Who escalates, and when? If the first responder cannot resolve the issue, how long before it escalates to a senior engineer? Is there a defined escalation path with names and contact numbers, or does it stay in the ticket queue until business hours?

Is 24/7 included, or is it a premium tier? Some managed IT contracts in Singapore include after-hours support only for P1 critical incidents, with standard hours applying to everything else. Know what you are paying for.

A good SLA in Singapore defines 24/7 support specifically: response by a named tier of support, with defined escalation paths, and clarity on whether on-site response is included.


Uptime SLA Maths: What 99.9% Actually Means

Uptime guarantees are expressed as percentages, which sound impressive until you convert them to actual downtime allowances per year.

Uptime SLA Allowed downtime per year Allowed downtime per month
99% 87.6 hours 7.3 hours
99.5% 43.8 hours 3.6 hours
99.9% 8.76 hours 43.8 minutes
99.95% 4.38 hours 21.9 minutes
99.99% 52.6 minutes 4.4 minutes

99.9% — which is what many managed IT providers promise — sounds excellent. But it permits your systems to be down for nearly 9 hours per year without the provider breaching the agreement. For a Singapore business operating 5 days a week across 12 hours per day, that is more than half a working day.

The right uptime SLA depends on your business. A manufacturing company that cannot process orders during downtime has different tolerance than a professional services firm. Negotiate an uptime SLA that reflects your actual tolerance — not the default number in the provider's template.

Also important: check how uptime is measured. Providers sometimes exclude from their uptime calculations: planned maintenance windows, incidents caused by third-party systems, events classified as force majeure, and Internet connectivity issues outside their control. A 99.9% SLA with extensive exclusions is meaningfully worse than one with few.


Priority Tiers: What Should Qualify as P1

Most managed IT SLAs define priority levels, but the definitions vary enormously between providers. Make sure your contract defines each priority level explicitly — and that the definitions reflect your business reality.

P1 — Critical: Complete business outage. No users can work. Core systems are down. Revenue impact is immediate. Examples: server room is offline, VPN is down for all remote workers, ERP system is inaccessible, ransomware detected and spreading.

P2 — Major: Significant impact affecting multiple users or a critical function. Business can partially operate but with serious disruption. Examples: email is down for 50% of users, file server is slow to the point of unusability, a key application is inaccessible to a department.

P3 — Moderate: Limited impact with a workaround available. Business can operate normally using an alternative method. Examples: one user's laptop cannot print, a specific application feature is not working, a non-critical system is performing slowly.

P4 — Minor: Cosmetic or informational issues with no operational impact. Examples: a software version needs updating, a new user account needs to be provisioned, a password reset is requested.

The risk for businesses is misclassification. Some providers classify almost everything as P3 or P4 to avoid triggering fast SLA response commitments. Insist on clear, specific, unambiguous definitions — and insist that the business, not the provider, makes the final classification call for P1 incidents.


Escalation Procedures: The Clause Most Businesses Forget to Negotiate

When an incident is not being resolved fast enough, who do you call? What happens if you call that person and still get no traction?

A good SLA defines an escalation matrix:

  • Level 1: First-line support engineer. Handles initial response and basic troubleshooting.
  • Level 2: Senior engineer or team lead. Handles complex issues the first-line cannot resolve.
  • Level 3: Principal engineer or management. Handles major incidents, coordinates external vendors.
  • Business escalation: Your named account manager, reachable by mobile during a P1 incident.

The escalation matrix should include names, mobile numbers, and defined timeframes. "You can escalate to your account manager" is useless if you do not have a direct mobile number and a defined trigger point for when to escalate.

Also insist on a Major Incident Management procedure: during a P1 event, how often does the provider communicate updates to you? Industry standard is every 30 minutes during active investigation. If your current provider goes quiet during a crisis, that is a process failure.


Penalty Clauses: Do They Actually Mean Anything?

Most SLAs include financial remedies for breaches — typically credit against future invoices if uptime falls below the guaranteed level or if response/resolution targets are missed. The question is whether these penalties are worth anything in practice.

Typical SLA credit structures in Singapore managed IT contracts:

  • Response time breach: SGD 50–200 per incident, or 1–5% of monthly fee
  • Uptime breach per hour below SLA: SGD 100–500, or a percentage credit based on downtime duration
  • Resolution time breach: Often not separately penalised — another reason to insist resolution times are explicitly defined

The honest assessment: SLA credits rarely compensate for the actual business cost of an outage. A P1 outage that costs your business SGD 20,000 in lost revenue and staff idle time is not made whole by a SGD 500 credit on next month's invoice.

SLA credits serve a different purpose: they create accountability. A provider who faces a financial consequence for repeated SLA breaches has an incentive to avoid them. Without penalty clauses, there is no contractual mechanism to drive performance.

Insist that your contract includes penalty clauses. Then insist on the right to terminate without penalty if SLA breaches exceed a threshold — typically three P1 breaches in any rolling 12-month period.


Red Flag Clauses: What Not to Sign

These are the clauses that benefit the provider at your expense. If you see them in a proposed contract, push back.

"Best effort" language. Any SLA that uses the phrase "best effort" instead of defined timeframes is not an SLA — it is a suggestion. "We will use best efforts to respond within 4 hours" means they can take 48 hours and argue they tried their best.

Blanket force majeure. Force majeure clauses (excusing performance due to events outside the provider's control) are standard and reasonable for genuine disasters. They become problematic when written broadly enough to cover everyday events: Internet outages, third-party software failures, or staffing issues. If the clause is broad enough that a provider could invoke it for almost any incident, renegotiate it.

Unilateral amendment rights. Some contracts allow the provider to amend SLA terms with as little as 7–14 days' notice. That means the SLA you negotiated can be changed to their preferred defaults at any time. Insist that SLA amendments require mutual written agreement.

Exclusion of third-party systems. Many SLAs exclude any incident touching third-party software, cloud platforms, or infrastructure the provider did not deploy. In practice, almost every modern IT environment involves third-party systems. If the exclusion is too broad, the SLA covers almost nothing. Push for the provider to be responsible for end-to-end incident management — including coordinating with third parties on your behalf — even if the underlying issue is a vendor problem.

No data portability clause. If you terminate the contract, what happens to your data and configurations? Some managed IT providers do not clearly define data return procedures. Insist on a clause that specifies data return timelines, formats, and costs upon termination.


What We Typically See When Reviewing Client Contracts

When Aggasys reviews managed IT contracts brought to us by prospective clients considering a switch, the most common gaps we find are:

No resolution time commitments. Response times are defined, resolution times are not. The provider can technically meet every SLA target while leaving incidents open for days.

Unclear 24/7 scope. The contract says 24/7 but the schedule of services buried in an appendix limits after-hours response to P1 critical incidents only, with a narrow definition of P1 that most incidents do not qualify for.

No on-site SLA. The contract commits to remote support response times but says nothing about on-site response. Businesses discover this gap when they have an issue that cannot be resolved remotely.

Auto-renewal with long notice periods. Contracts that auto-renew annually with 60–90 days written notice to terminate. Businesses miss the notice window and are locked in for another year with a provider they want to leave.

No tested DR clause. The contract says the provider will maintain backups, but there is no commitment to test restores or provide evidence of test results. The provider might be running backups that have never been validated.


The SLA Conversation to Have Before You Sign

Before signing any managed IT contract in Singapore, ask these questions directly:

  1. What are your specific response and resolution time commitments for each priority level?
  2. Who specifically answers P1 calls at 2am on a Saturday? What is their direct mobile number?
  3. Is on-site response included in the SLA, and what is the committed on-site response time for a P1 in Singapore?
  4. What penalty applies if you miss an SLA target, and how do I claim it?
  5. Under what circumstances can you amend this SLA without my agreement?
  6. What third-party systems are excluded from SLA coverage?
  7. How do I escalate if I am not satisfied with how an incident is being handled?
  8. What is your data return procedure if I choose to terminate?

A provider who answers these questions directly and in writing is one you can work with. A provider who deflects, speaks in generalities, or says "we'll sort that out if it comes up" is one whose SLA will not protect you when it matters.


Frequently Asked Questions

What is the difference between response time and resolution time in an IT SLA?

Response time is how long the provider takes to acknowledge your ticket and assign it to an engineer — essentially, how long until you get a reply confirming they are looking at it. Resolution time is how long it takes to actually fix the problem. An SLA that only defines response time can technically be met while your issue sits unresolved for days, so always check that both are defined separately for each priority level.

What does 99.9% uptime actually mean in allowed downtime?

A 99.9% uptime SLA permits about 43.8 minutes of downtime per month, or roughly 8.76 hours per year. That sounds strict, but for a business operating 5 days a week across 12 hours a day, 8.76 hours a year is more than half a working day of potential outage without the provider technically breaching the agreement. Always check how uptime is measured, since providers sometimes exclude planned maintenance, third-party system failures, and force majeure events from the calculation — which makes the real guarantee weaker than the headline number suggests.

What remedies or credits should apply if the provider breaches the SLA?

Typical Singapore managed IT contracts apply credits such as SGD 50–200 per incident for a response time breach, or SGD 100–500 per hour (or a percentage credit) for an uptime breach below the guaranteed level. Resolution time breaches are often left unpenalised, which is another reason to insist resolution times are explicitly defined in the contract. Credits rarely cover the actual business cost of an outage, but they create accountability — so also insist on the right to terminate without penalty if breaches exceed a threshold, typically three P1 breaches in a rolling 12-month period.

How can I tell if "24/7 support" is genuine or just a marketing claim?

Ask who actually answers at 2am — a local Singapore engineer, an overseas call centre, or an automated ticketing system — and what they can actually do at that hour, since remote-only support is not useful if your issue needs a physical presence. Also check whether 24/7 coverage applies to all tickets or only P1 critical incidents, and whether there is a defined escalation path with named contacts and mobile numbers rather than a vague promise to "escalate to your account manager."

Which SLA clauses are typically negotiable before signing?

Response and resolution time commitments per priority level, the scope and hours of "24/7" coverage, on-site response inclusion, escalation procedures with named contacts, and penalty credit amounts are all commonly negotiable. So are red-flag terms like "best effort" language, broad force majeure clauses, unilateral amendment rights, blanket exclusion of third-party systems, and the data return procedure on termination — a provider unwilling to negotiate these is signalling how the relationship will go after you sign.


Book a Free SLA Review with Aggasys

Before you sign your next managed IT contract, or if you want us to review a contract you are currently on, Aggasys offers a free SLA review for Singapore businesses. We will identify the gaps, explain what each clause means in practice, and tell you which terms you should push back on before committing.

Book your free SLA review: aggasys.com/contact or call (+65) 6250 0045.

Explore this service
Managed IT Services →
Related guides
IT Basics
What Is a Firewall? A Plain-English Guide for Singapore Business Owners
8 min read
IT Basics
What Is a Managed Service Provider (MSP)? A Guide for Singapore Business Owners
9 min read
Managed IT
12 Questions to Ask an IT Managed Service Provider in Singapore (2026)
10 min read
← Back to all resources