What Is an SLA, and Why Every Software Owner Should Care

An SLA (Service Level Agreement) is a written commitment between a service provider and a customer about measurable service quality: what percentage of the time the system is available, how quickly incidents are acknowledged, how quickly they are resolved, and what the provider owes if it misses. For a business that owns a website or custom software, an SLA turns "someone looks after it" into "someone is accountable for it".

A familiar scene

Monday morning, the sales system will not log in. Staff call the person who built it; the line is busy. They message on Zalo; seen, no reply. Around noon comes "I'll take a look tonight". The store writes orders by hand for the rest of the day.

The problem is not that there was an incident. Every piece of software breaks sometimes. The problem is that nobody committed to a resolution time. Without a commitment, every incident is an open-ended wait, and the business has no basis to escalate or plan around it.

That is exactly the gap an SLA exists to close.

The numbers inside an SLA

An SLA for a business website or application usually has 5 components. Understanding these 5 is enough to read and compare any provider's SLA.

1. Availability (uptime)

The share of time the system works normally, measured per month. The numbers all sound "close to 100%" but differ enormously in hours:

• 99% uptime allows up to 7.3 hours of downtime a month.
• 99.5% allows up to 3.6 hours.
• 99.9% allows up to 43 minutes.
• 99.99% allows up to 4.3 minutes.

For a small business online store, 99.9% is a sensible target that can be achieved at ordinary cost. Going higher needs far more expensive redundant infrastructure and is rarely necessary.

2. Response time

The time from when a customer reports an incident to when a real person confirms it has been received and work has started. Psychologically this is the most important number: knowing someone is on it is very different from silence. Common levels: 15 minutes to 2 hours during business hours, depending on severity.

3. Resolution time

The maximum time to bring the system back to working order, counted from acknowledgement. Usually tiered by severity:

• Critical (system fully down, data loss): 4 to 8 hours.
• High (a core function broken, e.g. checkout): 1 business day.
• Medium (display bugs, secondary functions): 2 to 3 business days.
• Low (improvements, questions): per agreed schedule.

Note that "resolved" may mean a temporary workaround that gets you running, with the root fix later. A good SLA states both milestones.

4. Support hours

Whether the commitment applies 24/7 or only during office hours. Many SLAs say "response within 1 hour" but count office hours only, meaning a Friday night incident can wait until Monday morning. Businesses that sell in the evening or at weekends must ask about this explicitly.

5. Consequences for missing

The clause that separates a real SLA from a promise. Usually a proportional credit on the monthly fee, or the right to terminate without penalty. Without this clause, the numbers above are goals, not commitments.

How to read a provider's SLA

When you receive a maintenance quote, look for the 5 items above and ask:

1. How is uptime measured, is "scheduled maintenance" excluded, and how much notice does scheduled maintenance require?
2. Which channels count toward response time? Only tickets in the portal, or phone and Zalo too? A channel that does not count is a channel where reporting changes nothing.
3. Who decides severity? If only the provider decides, every incident can be filed as "medium".
4. Is there a monthly report showing whether the SLA was met? An SLA that is not measured cannot be checked.
5. What happens if they miss?

A provider that answers all 5 clearly has actually operated systems before. One that hedges has usually only done the "build" part, not the "keep" part.

How Moniro's SLA works

At Moniro the SLA does not live in a PDF sent once and forgotten. It is built into the service portal customers use every day:

• Every request becomes a ticket in the portal, with an ID, a priority chosen by the customer, and acknowledgement and resolution timestamps shown immediately.
• First response time is counted from ticket creation, whatever the hour; critical incidents have a direct phone channel.
• The monthly report automatically lists ticket counts, actual response and resolution times against commitments, and uptime per asset.
• If a commitment is missed, the monthly fee is credited per the contract; the customer does not have to ask.

This is part of website maintenance and custom software maintenance; fixed monthly fees, commitments published on the page.

A sensible SLA template for small businesses

If you are drafting requirements to send to providers for quotes, here is a balanced reference between cost and safety for a small or medium business website or application:

• Uptime: 99.9% per month, excluding scheduled maintenance announced 48 hours ahead, capped at 2 hours per month.
• First response: 30 minutes for critical incidents (24/7), 2 hours for high and medium (business hours).
• Resolution: critical 8 hours, high 1 business day, medium 3 business days; state both "workaround" and "root fix" milestones.
• Channels counted: tickets in the service portal; phone for critical incidents.
• Reporting: monthly, with measured data.
• Missed commitments: 10% credit on the monthly fee per missed commitment, capped at 50%.

This is not so strict that the operations team has to inflate prices, but strict enough for the business to plan with confidence.

Common misunderstandings about SLAs

"A higher SLA is better." Not necessarily. A 99.99% SLA at three times the fee is rarely needed for a company brochure site. Choose the level that matches the real damage of downtime.

"With an SLA the system never goes down." An SLA does not prevent incidents; it commits to how they are handled. What prevents incidents is monitoring, updates and backups done routinely, in other words daily maintenance work.

"A trusted freelancer can commit to an SLA too." One person cannot be on call 24/7 and has no backup when busy. A real SLA needs a team and a process, which is why individual promises tend not to hold.

"Once the SLA is signed, we're done." An SLA only has value when it is measured and reported. Ask for the first monthly report and read it.