The big cloud outages of 2025-2026 and your Moodle site

Your Moodle site can go down when a company you have never paid has a bad afternoon. In the last 18 months AWS, Microsoft Azure, Cloudflare and Google Cloud each had at least one outage big enough to make the news, and none of them was an attack. They were a race condition, a bad config, a file that got too big, a cleanup script with an empty parameter, and a power cable.

You can’t stop any of that. What you can do is know which of these companies your site leans on, decide what happens on exam day if one of them fails, and keep a way into your own admin panel that does not depend on someone else’s login page.

What went down, and why?

Every row below comes from the provider’s own post-incident report. Times are UTC; we converted AWS and Google’s Pacific times.

A few things stand out.

• Half of these were global. Google’s June outage, Azure Front Door and both late-2025 Cloudflare outages hit every region at once, because what broke was a control plane or an edge network that every region shares. The other four stayed in one region or one product.
• The status page and support desk can be on the thing that broke. Google’s status dashboard was down for the first hour of the June incident.¹ During the AWS outage, AWS Support case creation failed,² and during the Azure Front Door outage customers could not open support cases in the portal or by phone.³
• Logins broke along with everything else. AWS lost IAM and STS sign-in, Azure Front Door took parts of Entra ID with it, Cloudflare Access failed authentication, and Google Workspace went down with Google Cloud.

For completeness: AWS’s own list of post-event summaries has nothing from 2026 as of today, only the October 2025 DynamoDB event.⁹9 AWS, Post-Event Summaries, checked 31 October 2026. AWS did have smaller problems in 2026, but without a summary from AWS we are leaving them out. Instructure’s Canvas outage in May 2026 was a breach, not an infrastructure failure, and we covered it in Moodle vs other LMSs.

Does any of this touch a self-hosted Moodle?

Yes, even if your server sits in a rack in the basement. A Moodle site is a PHP application, a database and a moodledata folder. Around it there is usually a list of outside services that nobody wrote down.

• DNS. If your domain’s DNS is hosted with a provider that goes down, nobody can find your server, however healthy it is.
• CDN and proxy. Many Moodle sites sit behind Cloudflare for caching, TLS or bot protection. On 18 November 2025, a site like that would have shown Cloudflare’s error page for hours while the Moodle server behind it was fine.⁴
• Hosted Redis or a managed database. If you moved the cache or sessions to a cloud Redis, or the database to RDS, Cloud SQL or Azure SQL, your site is now as available as that region. The hosting guide covers the setup.
• Object storage. tool_objectfs moves file content to S3, Azure Blob, Google Cloud Storage and others. Its settings include “Delete local objects once they are in remote object storage” and, for files in both places, “read from remote”.¹⁰10 Catalyst IT, moodle-tool_objectfs, README, checked 31 October 2026. With those on, the only copy of a course PDF is in the bucket. If the bucket’s region is down, files stop loading. The README does not describe a fallback.
• SSO. If students sign in through Entra ID, Google or a SAML identity provider, and that provider is down, nobody gets in, admins included. This is the one that bites hardest.
• Email. Password resets, forum digests, assignment notifications. If mail goes through Microsoft 365, Google Workspace or a sending service hosted on one of these clouds, it waits or bounces.
• AI providers. Moodle’s AI subsystem connects to providers like OpenAI, Azure AI, Gemini, Amazon Bedrock, Anthropic and DeepSeek, or to Ollama for local models.¹¹11 MoodleDocs, AI providers. A cloud provider outage turns those features off.
• LTI tools. Each external tool is someone else’s server on someone else’s cloud. When it is down, the activity shows an error inside your course.
• Video embeds. YouTube, Vimeo or a hosted video platform. Your page loads, the video does not.

None of these take Moodle itself down. They take down the parts students notice: getting in, opening the file, watching the video, getting the email.

What can a school actually do?

Write the dependency list

This is a one-afternoon job and the most useful one here. For each service in the list above, write down which company provides it, which region it runs in, and what students see if it fails. Then check the result against the table. If three of your rows say “AWS us-east-1”, you know something you didn’t know yesterday.

Our rule of thumb: if you can’t fill in a row because nobody knows who runs it, that row is your biggest risk.

Keep a way in that does not need SSO

When the identity provider is down, you still need an admin who can log in to post a notice, extend a deadline or switch off a broken integration. Moodle has the pieces:

• A manual admin account. Keep at least one administrator on manual authentication with a strong password and two-factor, and test it each term.
• auth_saml2. Catalyst’s SAML plugin supports ?saml=off on the login page for manual accounts, so https://your.site/login/index.php?saml=off shows the normal Moodle login form even when SAML is the default.¹²12 Catalyst IT, moodle-auth_saml2, README.
• Alternate login URL. If your site uses Moodle’s Alternate login URL setting (Site administration > General > Login > Login settings), the docs warn that “an incorrect URL can lock you out of your site.”¹³13 MoodleDocs, Login settings. Moodle’s own login page accepts loginredirect=0 to skip that redirect; the code comments call it “Used to bypass alternateloginurl.”¹⁴14 Moodle, login/index.php on MOODLE_500_STABLE. So https://your.site/login/index.php?loginredirect=0 gets you the core form. If even that fails, the older docs say to remove alternateloginurl from the mdl_config table and purge caches.¹⁵15 MoodleDocs, Managing authentication (5.1).

Write the bypass URL into the runbook, not into someone’s head.

Plan exam day separately

An outage in a normal week is an annoyance. An outage during a timed exam is an appeal and a resit.

• Know which outages actually stop the exam. A quiz needs the Moodle server, the database and the login. It does not need the CDN’s bot check, the AI provider or YouTube. If a CDN sits in front of the site, decide now whether you would switch it to DNS-only during an outage, and who has the access.
• Decide the policy before the day. Who extends time limits, who reopens attempts, how students hear about it. Quiz user and group overrides already do the mechanics; the decision is what’s missing on exam morning.
• Offline attempts help with the student’s connection, not yours. The Moodle app can let a student do a quiz offline and sync later, but only if the quiz has no time limit, uses deferred feedback, has no network address restriction and no sequential navigation.¹⁶16 MoodleDocs, Moodle Mobile quiz offline attempts. Good for practice quizzes on bad home Wi-Fi. Useless when your site is down: the attempt still has to reach the site, and most exams are timed anyway.
• Keep a paper or email fallback for the high-stakes ones. It works when everything else is down.

Watch the right status pages, and know they lie at first

Subscribe to the status pages for every row in your dependency list, and point an outside uptime check at your login page and one course file, not just the home page. Then remember that the provider’s page is often slow to admit trouble: Google’s own dashboard was down for the first hour of its June 2025 outage.¹ Our rule of thumb: if your own check and a few users say it’s broken, it’s broken, whatever the status page says.

Multi-region only when it pays off

Running Moodle in two regions with database replication and failover is expensive and hard to test. And look at the table again: Google’s June outage, Azure Front Door and both late-2025 Cloudflare outages were global. A second region would not have helped with any of them. For the regional half (AWS us-east-1, Azure West US, Google London), a standby elsewhere would have.

Our rule of thumb:

• Most schools: one region, good backups you have actually restored, and the dependency list. Spend the money on the runbook and a tested restore, not a second region.
• Exam-heavy or very large sites: keep a warm standby you can restore into in a few hours, in a different region or with a different provider, and practise switching DNS to it.
• Real multi-region: only when an outage costs you more than the second region does, and when you have people who will test failover every term. Untested failover is a second outage waiting.

Also keep the server itself patched. Outages are rare; an unpatched PHP install is a standing invitation (see outdated PHP and Moodle security).

So, is the cloud too risky for Moodle?

No. A server in your own building goes down too, for duller reasons and with nobody writing a post-mortem. The risk isn’t using these providers. It’s using six of them without knowing, and finding out on exam morning.

Make the list, keep the side door into the admin panel, and set the exam-day rules early. If a custom integration of yours (an SSO bridge, an LTI tool, an AI feature) falls over when a provider does, DevLMS builds and fixes Moodle plugins, fallback path included.