Moodle Hosting SLA: A Buyer’s Guide to Uptime, Support and Remedies

A good Moodle hosting SLA tells you what must remain available, how the provider measures failure, when skilled help starts, how service is restored and what happens when commitments are missed. A headline such as “99.9% uptime” does none of that on its own.

That is the short answer. Buy the operating model behind the percentage: the complete learner journey, tightly defined exclusions, response and restoration targets, recovery commitments, evidence, escalation and meaningful remedies. An SLA is the measurement and accountability layer of a managed service; it cannot repair a weak service scope.

This guide is for UK organisations comparing managed Moodle proposals or renegotiating an existing agreement. It explains the clauses that change operational risk, the questions that expose a hollow guarantee and the trade-offs behind a higher availability target.

The Short Answer: What a Moodle Hosting SLA Should Contain

Require these nine items in writing:

• the Moodle sites, environments, functions and dependencies covered;
• a precise availability formula and an agreed monitoring source;
• the uptime target, measurement period and reporting timetable;
• limited, explicit exclusions and a controlled maintenance process;
• impact-based incident priorities and support hours;
• separate response, update, restoration and resolution targets;
• backup, recovery point and recovery time commitments;
• escalation, root-cause review and service-improvement duties; and
• remedies, chronic-failure rights, data obligations and exit support.

Swift Learn’s judgement is that measurement quality matters more than an extra decimal place. A defensible 99.9% commitment covering sign-in, course access and critical activity is more useful than 99.99% measured only at a server that cannot tell whether learners can use Moodle.

If the wider hosting scope is still unclear, use our questions for a UK Moodle hosting provider first. The SLA should attach measurable standards to an already defined service, not act as a substitute for one.

Start With the Service Boundary, Not the Percentage

Moodle availability depends on more than a web server. The learner journey can involve a load balancer, application nodes, database, file storage, cache, scheduled tasks, identity provider, email service and integrations. A page may return successfully while single sign-on fails, submissions cannot be saved or scheduled enrolments have stopped.

List the functions that must work for the service to count as available. For many organisations that includes authentication, course access, activity launch, submission, completion recording and essential administration. Add critical integrations where the hosting provider owns or manages them. State separately where an identity, payment, video or student-record supplier remains outside its control.

Also name every covered environment. Production availability may be the contractual priority, but staging, disaster recovery and administration access still need ownership and support arrangements. The provider cannot sensibly guarantee a third party’s platform, yet it should commit to diagnosis, evidence gathering, escalation and communication when that dependency affects Moodle.

This boundary should align with the responsibility split in your main agreement. Our Moodle support contract guide explains how hosting, application support, administration and development differ.

Make the Uptime Calculation Auditable

A usable SLA states the equation. A common structure is:

Every important argument sits inside the word “eligible”. Ask which hours enter the denominator, when an outage starts, when it stops, whose monitoring record prevails and which events are excluded. Require a monthly report showing the underlying incidents rather than accepting a percentage with no evidence.

For a 30-day measurement period, the arithmetic looks like this:

These figures are arithmetic, not a promise that every outage will fit neatly inside the allowance. One 40-minute interruption during mandatory training may cause more harm than several short overnight events. Define both aggregate availability and how severe or repeated incidents are governed.

Measure the Learner Experience

Monitoring should test meaningful transactions from outside the hosting environment. At minimum, ask how the provider checks the public service, login path and a representative authenticated journey. Infrastructure metrics help engineers diagnose a fault, but processor load alone does not prove availability.

Agree the polling interval, failure threshold and geographic test locations. If five consecutive checks are needed before downtime begins, a long interval can erase a material part of every incident. Equally, one failed probe should not declare a healthy service down. The method needs to be stable, proportionate and visible to both parties.

Control Exclusions and Planned Maintenance

Reasonable exclusions can include approved maintenance, customer-caused changes and failures wholly outside the provider’s control. Broad wording such as “third-party issue”, “security event” or “emergency maintenance” can remove the very risks you hired a managed provider to control.

Set notice, duration and frequency rules for planned maintenance. Require maintenance to be scheduled around known learning peaks and counted when it exceeds the approved window. Emergency work may need shorter notice, but the provider should still explain the risk, record the decision and report the resulting interruption.

Force majeure should not excuse weak resilience or poor recovery. Likewise, a denial-of-service attack should not automatically disappear from measurement if protective monitoring and response are part of the service. Negotiate exclusions by asking which party could reasonably prevent, reduce or recover from the event.

Separate Response, Restoration and Resolution

“Priority-one response within 15 minutes” means little unless response is defined. An automated acknowledgement is not skilled triage, and a response target is not a promise to restore learning.

For each incident priority, define:

• impact criteria — affected users, functions, sites and business deadlines;
• response — when a suitably skilled person begins diagnosis;
• updates — how often the provider communicates and through which channel;
• restoration — the target for returning the service or a safe workaround; and
• resolution — how permanent corrective work is owned and tracked.

Priority must reflect business impact. Complete platform loss is clearly critical, but so may be a failed assessment submission for one high-stakes cohort. Agree examples before an incident and include a route to challenge a priority decision.

Check the clock rules. A four-hour target measured only from 09:00 to 17:00 on working days can carry an incident across a weekend. If learners use Moodle outside office hours, specify the monitoring, on-call response and authority available then. You may choose narrower cover to control cost, but the residual risk should be an explicit business decision.

Treat Recovery as a Separate Commitment

Availability, backup and disaster recovery answer different questions. Uptime measures accessible service. A recovery point objective limits how much recent data could be lost. A recovery time objective sets the target for restoring a defined service after a qualifying event.

“Daily backups” is not an outcome. The agreement should state what is copied, how often, retention, separation from production, encryption, monitoring and restore testing. It should distinguish recovery of one deleted course from restoration of the full platform. Ask for the date and result of the latest representative restore exercise and how failures are corrected.

Choose objectives from learner and organisational impact, not from the provider’s default package. Tighter recovery points, rapid restoration and geographically separate capacity cost more. They are worthwhile where lost submissions, compliance records or an unavailable assessment window create material harm; they may be excessive for a small internal knowledge site with a tolerable manual fallback.

Put Security and Data Duties Beside Service Levels

An uptime figure says nothing about confidentiality or integrity. The UK National Cyber Security Centre’s Cloud Security Principles, version 2.1 reviewed on 7 June 2023 and checked for this article on 12 October 2026, advise buyers to assess evidence across areas including resilience, operational security, supply chains, identity, administration and customer audit information.

Translate that into evidence requests: vulnerability and patch processes, privileged-access controls, security logging, incident notification, sub-processor governance and change management. Moodle’s official security guidance, checked on 12 October 2026, also emphasises access control, safe handling of user input and keeping software up to date. Your service scope should state who owns each layer required to put those principles into practice.

Where the host processes personal data, the data-processing terms must match reality. The ICO’s controller-processor contract guidance, checked on 12 October 2026, lists required provisions including documented instructions, confidentiality, appropriate security, sub-processors, assistance, audits, and deletion or return at contract end. The ICO currently notes that this guidance is under review following the Data (Use and Access) Act, so your legal or data-protection lead should check the current position when contracting.

Make Remedies Encourage Better Service

Service credits can create accountability, but they rarely repay the operational cost of an outage. Read the mechanism carefully: the credit may apply only to the affected hosting fee, be capped, require a claim within days and operate as the sole remedy.

A balanced remedy schedule should be automatic where possible and increase when performance falls through meaningful bands. More importantly, require an incident report for serious failures, a corrective-action plan for recurring causes, executive escalation and a right to terminate for chronic breach without punitive exit charges.

Do not demand unlimited liability through an SLA and assume the service becomes safer. Providers price risk, and extreme terms can narrow competition without improving engineering. Focus negotiation on preventable failure, transparent evidence, rapid restoration and a credible exit if performance does not recover.

Use a Weighted Buyer Scorecard

Compare each bid against the same scenario and responsibility boundary. A practical scorecard can weight:

• 25% service coverage and dependency ownership;
• 20% availability definition, monitoring and exclusions;
• 20% incident response, restoration and communications;
• 15% backup, disaster recovery and tested evidence;
• 10% security, data protection and sub-processors; and
• 10% remedies, reporting, improvement and exit.

Adjust the weights to your risks, but score documentary evidence rather than sales assurances. Request a sample monthly report, anonymised incident review, restore-test record and escalation map. Ask who actually provides out-of-hours cover and whether the people named in the proposal have authority to make recovery decisions.

Price the service only after normalising scope. If you are deciding whether those responsibilities should remain in-house, compare managed Moodle hosting versus self-hosting, including internal on-call time, specialist cover and recovery testing rather than infrastructure charges alone.

Red Flags in a Moodle Hosting SLA

Pause the procurement if you find:

• availability measured only at a server or network edge;
• exclusions broad enough to remove provider-controlled failures;
• response targets with no restoration, update or escalation standard;
• “24/7 support” that means ticket receipt rather than skilled action;
• recovery claims with no scope, objective or restore-test evidence;
• credits that require hidden monitoring evidence or an impractical claim window;
• no route for repeated misses beyond another small credit;
• unnamed sub-processors or unclear data locations; or
• exit wording that does not deliver a usable database, files, code and documentation.

None of these automatically proves that a provider is unsuitable. Each one identifies risk that needs a written answer before signature.

The Swift Learn Verdict

The best Moodle hosting SLA is not the document with the largest uptime number. It is the one that describes a real learner service, measures it fairly, mobilises capable people, protects data, proves recovery and gives both parties a workable route when performance falls short.

Start with scope. Test the availability formula and every exclusion. Distinguish acknowledgement from restoration, and uptime from recovery. Then compare evidence, remedies and exit rights against the actual cost of disruption to your learners.

Want an Independent Moodle Hosting SLA Review?

Bring us your draft proposal, learner-critical periods, integrations and current support pain points. Swift Learn can map the responsibility boundary, test the SLA assumptions and help you define a managed service that fits your operational risk.