A software support SLA (service level agreement) is a written agreement that defines what support covers for a system, how quickly issues are handled, and who is responsible for each part. It turns “please look after this system” into rules that both the business and the support team can check.
What an SLA covers
A useful SLA is more than a response-time promise. It usually describes:
- Supported scope: which applications, environments, integrations and devices are included, and what is excluded.
- Response and fix times: response time is how soon someone acknowledges and starts on an issue; fix (or resolution) time is how long it takes to restore service or provide a workaround. They are different targets and should be written separately for each severity level.
- Service hours: when issues can be reported and when the team is expected to act, including how public holidays are handled.
- Release windows: when planned changes may go to production, how they are announced, and how emergency fixes differ from routine releases.
- Reporting: what is reported back, such as incidents handled, open items and recurring problems.
Responsibility boundaries in custom systems
Custom systems are where unclear ownership causes most delays. Write down the answers to three questions before an incident happens:
- Who owns the code? Confirm who holds the source repository, the cloud accounts, the domain and the licences, and who may grant access.
- Who changes production? Decide who can approve a change, who deploys it, and how it is rolled back if something goes wrong.
- Who follows up third-party API outages? The provider of a payment, messaging or mapping service owns its own service. The support team can detect the failure, tell users, apply an agreed workaround and raise a ticket with the vendor, but it usually cannot promise when the vendor will fix it. The SLA should say so plainly.
Handover checklist before taking over a legacy system
Before a support team accepts responsibility for an inherited system, review at least the following:
- Source code, build steps and a working way to deploy to a test environment
- Hosting, domains, certificates and who pays for them
- Admin accounts, secrets and access lists, including former staff and vendors
- Databases, backups and whether a restore has ever been tested
- Third-party services, API keys and renewal dates
- Existing documentation, known defects and any past incident notes
- Expected busy periods and the workflows that matter most to the business
Gaps found at this stage are easier to fix than gaps found during an outage. Some may need a stabilisation phase before the SLA targets can be realistic.
How an SLA works with monitoring and automated testing
An SLA is only as good as the signals behind it. Monitoring of availability, errors, backups and integration failures helps the team notice problems before users report them, and can be linked to severity rules so the right alert starts the right response. Automated testing of key user journeys helps check that a fix or release has not broken something else, which makes release windows safer and shorter. Neither replaces a support process, but both make response and fix targets easier to meet and to measure.
technine.io describes its approach on the Managed Support & SLA page, including how a system is reviewed, scoped, stabilised and then supported.
Frequently asked questions
Does an SLA mean 24x7 support?
No. Service hours are part of the agreement and can be business hours only, extended hours, or round-the-clock cover for selected critical services. Choose the level that matches the business impact of an outage and what you are prepared to pay for, and confirm how out-of-hours reports are handled.
How are urgent and normal issues separated?
Through severity levels with clear definitions. For example, a system that is down or blocking payments or access would be urgent, while a cosmetic defect or a report formatting change would be normal. Each level has its own response and fix target, and the SLA should say who decides the level and how it can be changed.
Is response time the same as fix time?
No. A fast response means the issue has been acknowledged and work has started. A fix may take longer, particularly when the cause sits with a third party, so the two should be agreed separately.