SLA for LMS: what should it look like and what should it contain?
An SLA is a contract guaranteeing the level of services provided. An SLA is something like a safety net for LMS, as it clearly defines what guarantees you will receive from the supplier, when, and under what conditions.
Availability is not the same as "response time"
There are usually three different guarantees within an SLA, and it is good not to overlap them.
Availability is the percentage of time in a month when the service is available to users. It is calculated without planned downtime, and it is fair to specify in advance when and how often these downtimes/system maintenance will take place.
Response time means how long it takes for support to receive, acknowledge, and begin resolving an incident.
Finally, resolution time (or temporary workaround) indicates how long it should take for a critical fault to be repaired or at least stabilized.
It is also useful to name incident priorities (P1–P4) – for example:
- P1 = critical error that completely prevents the use of the system,
- P2 = error that affects key system functionalities and impacts most system users,
- P3 = error that makes it difficult for users to use the system,
- P4 = minor fault with no major impact on system operation.
How availability is calculated
System availability is usually measured monthly using the formula "100% minus unplanned downtime." This formula should be clearly defined in every SLA agreement.
It is good practice to announce planned outages or regular system maintenance windows well in advance.
If you are planning seasonal peaks in traffic on the education system, request that maintenance during these periods be carried out only in exceptional cases and by agreement.
API capacity and performance guarantees
Modern LMSs are based on integrations. Therefore, the SLA should also clearly state API limits (number of requests per minute/hour, concurrent connections), behavior when the limit is exceeded, and guarantees for asynchronous tasks (typically imports and report generation).
Note: If you pay "for API usage, number of queries, machine utilization, etc.", ask for a monthly statement of usage so that your monthly bill does not surprise you.
Data exports and reverse migration without complications
The SLA should describe what, in what form, and how quickly you can export from the LMS – users, groups, results, certificate history, course catalog, and metadata. Exports also include data schema so that they can be machine-readable elsewhere. For "what if" scenarios, have reverse migration written down: the supplier will help you transfer data to another system within a reasonable time frame and provide cooperation.
An addition is disaster recovery: how often backups are made (RPO) and how long it takes for the service to be back up and running after an outage (RTO). A really good SLA also includes information on how often system recovery from backups is tested (whether recoveries are functional in the event of an outage).
Incidents, communication, and escalation
When something happens, the quality of communication is crucial. A meaningful SLA specifies channels (portal, email, hotline), support availability (business days vs. 24/7 for P1 incidents), escalation contacts, and a deadline for sending final (summary) information about what happened, why it happened, and how to prevent it from happening again.
Small print and other bad habits
Exclusions from availability, exceptions, and force majeure. These are often areas where "ambiguities" arise. Be careful that "force majeure" does not cover everything from cloud issues to faulty integration of the LMS itself.
Repeated breaches of the availability guarantee should allow for withdrawal from the contract without penalty under the terms of the agreement.
At the same time, make sure that the supplier cannot unilaterally worsen the SLA without agreement; request changes and exceptions in writing.
How to negotiate a meaningful SLA
Start with the risks: how critical is the learning system to you? Which business processes would be stopped or slowed down by an LMS outage, and what impact would that have on your business? Set the scope and response times in the SLA accordingly. A client who uses the LMS only as an employee benefit will have different requirements than a multinational training agency.
Don't overestimate, but also don't underestimate the availability and guarantees within the contract, as these are directly reflected in the final price of the services. A good SLA transparently specifies all three areas: WHEN the service is available, HOW to report incidents, and HOW QUICKLY these issues are resolved. Add to that clearly described API limits and a reverse migration (backup recovery) plan, and you get an SLA that will keep your LMS running even on those "bad days."
