Moodle

Moodle maintenance and support for sites people depend on

We keep Moodle patched, backed up, fast and monitored, and we answer your administrators when they are stuck. One team that knows your site, on a monthly plan.

  • Staging first, then production
  • Backups proven by restores
  • A team that knows your site
Get a free quote See our work
What is included
  • Security and minor updates
  • Cron and task health
  • Backups and restore drills
  • Cache and database tuning
  • Storage and log housekeeping
  • Admin help desk
Get a free quote Reply within one business day. NDA on request.
The problem

How Moodle sites quietly degrade

A Moodle site rarely fails all at once. It degrades. Cron stops for a weekend and nobody notices until forum emails and enrolment syncs are two days late. The disk fills with automated backups. A security release sits unapplied for three months because the person who used to do updates has left. Then the first day of term arrives, a thousand students log in within ten minutes, and the site falls over.

Good maintenance is unexciting, repetitive work that stops those things from happening, done by people who know what a healthy Moodle looks like. It suits organizations without a dedicated Moodle administrator, IT teams that run the server but not the application, and anyone whose site was built by a contractor who has since moved on. We build and maintain our own LMS product as well as client sites, so being the ones who get the call is familiar territory.

  • Updates are overdue

    Security releases come out regularly, and each one publishes what it fixed. A site that waits months is running with known holes that anyone can read about.

  • Backups exist, restores are untested

    There is a nightly job somewhere, but nobody has restored from it. It may cover the database and miss moodledata, or the other way round.

  • It crawls at peak times

    Monday mornings, exam windows and compliance deadlines bring timeouts. The cause could be sessions, caching, a slow report or the database, and nobody has time to find out.

  • Admins have nobody to ask

    Your course administrators hit questions about gradebook setup, enrolment oddities or a broken activity, and the only answer available is a forum search.

What we do

Inside a Moodle maintenance plan

A plan combines scheduled technical care with a help desk for the people who run the site day to day.

Security and minor updates

Moodle point releases and plugin updates applied on staging first, checked, then deployed to production in an agreed window with a changelog.

Cron and task health

Scheduled and adhoc tasks watched for failures, long runtimes and queues that stop draining, with the cause fixed instead of the symptom.

Backups and restore drills

Off-site backups of the database, moodledata and code on a retention schedule, with a periodic test restore to prove they work.

Cache and database tuning

Cache stores, session handling, PHP workers and slow database queries reviewed against real traffic and adjusted before peak periods.

Storage and log housekeeping

Growth of moodledata, course backups, the recycle bin and log tables tracked, with retention settings tuned so disks do not fill unannounced.

Admin help desk

A support channel for your administrators and lead teachers: how-to questions, configuration changes, user issues and bug investigation.

Typical projects

Who uses our Moodle support

01

A college without a Moodle specialist

IT runs the servers and we look after the application: updates, plugin checks, term rollover support and answers for the eLearning coordinator.

02

A training company with paying learners

Uptime and checkout matter commercially, so monitoring, quick response to incidents and tested restores are the priority, with performance reviewed before each intake.

03

A corporate compliance site

Completion data must be right at audit time. We keep enrolment syncs and scheduled reports healthy and investigate any record that looks wrong.

04

A site handed over by a previous vendor

We start with a health check, document what is installed, fix urgent risks and then settle into regular monthly care.

In depth

What we watch on a Moodle site and why

Cron is the heartbeat

Almost everything Moodle does in the background runs through cron: sending notifications, syncing cohort enrolments, calculating completion, cleaning up files, running automated backups, processing adhoc tasks queued by plugins. It should run every minute. When it stalls, nothing visibly breaks at first, which is why it goes unnoticed. We monitor the time since the last run, tasks that keep failing and the length of the adhoc queue, and we look at why a task fails. A report that takes forty minutes will hold up others unless tasks are given enough parallel runners.

Where performance comes from

Moodle leans heavily on its caching layer, the Moodle Universal Cache. Out of the box the application cache lives on the file system, and sessions are typically kept in the database or on disk. That is fine for a small site and a bottleneck for a busy one. Moving them to an in-memory store such as Redis, enabling PHP opcode caching and giving PHP enough workers usually achieves more than a larger server. On the database side we look for slow queries from custom reports, missing indexes in third-party plugins and log tables that have grown without a retention limit.

Backups that have been restored

Moodle's automated course backups are useful for recovering one course a teacher deleted. They are not a disaster recovery plan. A real backup is a consistent copy of the database and moodledata, stored away from the server, with enough history to go back before a problem started. We run a test restore on a schedule, because that is the only evidence a backup works, and we record how long it took so you know your real recovery time.

Storage creeps

Disk usage in Moodle grows in ways that surprise people. Course backups are stored as files, often many generations per course. Deleted items wait in the recycle bin. Identical uploads are stored once, but files removed from courses are only purged later by a cleanup task. Logs grow daily unless a retention period is set. We chart growth monthly and adjust retention with you, so the conversation about more storage happens before the disk is full.

Getting ready for the start of term

Peak load is predictable: term start, exam weeks, a compliance deadline. Before each one we review capacity, clear the task backlog, check certificate expiry on the domain and the identity provider, confirm enrolment feeds ran, and freeze non-urgent changes. For sites with large exam cohorts we generate test users and courses with Moodle's own developer tools and run a load test. Bigger jobs that come out of maintenance, such as a Moodle upgrade or a broader performance optimization project, are quoted separately so the monthly plan stays predictable.

Process

Moodle onboarding and the monthly rhythm

  1. 1

    Health check

    We audit versions, plugins, cron, backups, caching, storage and security settings, and give you a prioritized list of findings.

  2. 2

    Fix the urgent risks

    Urgent risks are fixed first: missing backups, stalled tasks, overdue security releases. A staging copy is created if none exists.

  3. 3

    Set scope and windows

    We set the monthly scope, update windows, support channel and who can raise requests, sized to your site and calendar.

  4. 4

    Scheduled care each month

    Updates, checks, restore drills and housekeeping run on schedule, help desk requests are handled as they arrive, and you receive a short report.

  5. 5

    Seasonal readiness

    Ahead of term starts and deadlines we review capacity and freeze risky changes, then stay alert through the busy days.

Deliverables

What your Moodle gets each month

  • A Moodle site kept on current security releases
  • Backups proven by scheduled restore tests
  • A monthly report in plain language
  • Developers who already know your site
  • A help desk for administrators and course staff
FAQ

Moodle support plan questions

What is included in a Moodle maintenance plan?
Security and minor version updates for Moodle and plugins, monitoring of uptime, cron and scheduled tasks, backups with test restores, performance and storage reviews, and a help desk for your administrators. The exact scope and hours are agreed after a health check, since a small training site and a university need different things.
Do you offer support around the clock?
Not by default. Plans cover agreed support hours on your preferred channel, and what counts as urgent and how quickly we respond is written into the agreement. If your learners are spread across time zones or you run high-stakes exams, extended cover can be added. We would sooner agree realistic response times than promise something vague.
Can you maintain a Moodle site you did not build?
Yes. We begin with a health check that tells us what is installed, what has been customized and where the risks are. If we find edits to core files we flag them, because they affect how safely updates can be applied, and we agree how to deal with them before the plan starts.
Are major version upgrades part of the monthly plan?
No, they are scoped separately. Minor releases and security fixes are included, while a move to a new major release involves plugin audits, theme checks and rehearsals, so it is quoted as its own project. Being on a plan makes that project smaller, because the site is already documented and has a staging copy.
We host Moodle with our own IT team. Can you still help?
Yes. A common split is that your IT team owns the servers, network and backup infrastructure, and we own the Moodle application layer. We agree access, change windows and who is called for what, and we work through your ticketing or chat channel if you prefer.
What do we need to give you to get started?
Administrator access to Moodle, access to the server or hosting panel and the code repository if one exists, plus a contact who can approve changes. An NDA can be signed first. If you would prefer to add a person to your own team, you can hire a Moodle developer instead of taking a plan.
Related

Moodle Upgrade

Maintenance & Support

Performance Optimization

Moodle Developer

Moodle Migration

From the blog

All articles
Start a project

Want a second pair of eyes on your Moodle?

Ask for a health check. We reply within one business day, look at versions, cron, backups and performance, and tell you what we would fix first, with a free quote for a plan.

  • Free consultation and quote
  • NDA on request
  • You own the source code
  • Reply within one business day
Prefer to talk first? Book a call WhatsApp wwc@worldwincoder.com
Add budget and timeline optional, helps us quote faster

This form is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.