Back
Canonical's Websites Went Dark for Four Hours While Ubuntu's Repos Stayed Up. So Was Ubuntu Down?
On October 8, ubuntu.com was unreachable while apt kept working. Both answers to whether Ubuntu was down were true, and that gap is exactly where single check monitoring fails.
Jagdish Patil
•
What happened on October 8
Canonical posted on Ubuntu Discourse that its websites were under a sustained distributed denial of service attack, and warned that some services might be intermittently unavailable. It sent readers to status.canonical.com for updates. By the next day the team said it was still restoring affected services, though most were reachable again.
OMG! Ubuntu tracked the incident as it unfolded and put the total time offline at 4 hours and 12 minutes. SecurityWeek and Security Affairs both described it as a little over four hours. Nobody has claimed responsibility, and Canonical hasn't published a traffic figure. So we can't tell you how big the attack was, and anyone quoting a number is guessing.
This was the second major attack on Canonical this year. The earlier one reached much further. It took out Launchpad PPAs, Ubuntu SSO, mailing lists, signing keys and the Snap Store alongside the main sites.
Five properties down, six still working
Here's how the October incident split, based on reports published while it was happening.
Property | Status | What depends on it |
|---|---|---|
ubuntu.com and canonical.com | Down or intermittent | Product pages, documentation links, company info |
Ubuntu blog and developer site | Down or intermittent | Announcements and developer docs |
Security notices and API | Down or intermittent | Scripts and tools that pull vulnerability records |
APT repos and CD image server | Up | Package installs, updates, ISO downloads |
Launchpad and PPAs | Up | Source hosting, personal package archives |
Snap Store and Ubuntu SSO | Up | Snap installs, logins |
The security API row is the one to stare at if you run automation. Cybersecurity News pointed out that its outage hit administrators and tools that fetch vulnerability records hardest, even though the packages themselves kept flowing.
Someone who only opened ubuntu.com would have said Ubuntu was down. Someone who only ran apt would have said it was fine. Neither check was wrong. Both were incomplete.
Why one homepage check would have lied to you
Say you'd pointed a single monitor at ubuntu.com. It goes red within a minute or two, you assume the whole platform is on fire, and you spend twenty minutes checking mirrors that were never in trouble. Point it at the package repo instead and it stays green all afternoon while your security tooling quietly fails. One monitor gives you one slice, and the slice you picked decides the story.
The fix is dull: one monitor per thing you depend on. If you run client sites, that means the homepage, the checkout or login, and the API subdomain each get their own check. An attack, a bad deploy or a full disk can take out one and leave the others fine.
Then check what each monitor actually inspects. A status code check passes whenever the server answers 200 OK, even if the page behind it is an error message or a blank screen. Better Stack recommends keyword checks as the default for that reason. UptimeRobot's documentation adds a catch: its keyword check reads the raw HTML, so text injected by JavaScript after the page loads won't register. Whatever tool you use, find out which of those situations you're in before you trust a green dot.
Four hours is the rare kind of DDoS
Cloudflare's H1 2026 DDoS threat report counted 23.2 million network layer attacks between January and June, roughly 5,343 an hour. Most were small and short. About 96.6 percent stayed under 500 Mbps, and around 90.6 percent were over within 10 minutes. Attacks that ran past three hours made up 0.828 percent of the second quarter, going by the figures BleepingComputer pulled from the report.
Attack length and outage length aren't the same measurement, and Canonical hasn't said how long the attack itself lasted. Still, four hours of disruption puts this incident in the thin tail of what Cloudflare sees. Nine in ten attacks are done inside 10 minutes. The ones that aren't are the ones that cost you a morning.
OMG! Ubuntu also noted that this attack reached fewer services than the earlier one, and asked whether Canonical's lessons from that first incident had paid off. Canonical hasn't answered. A narrower blast radius fits the idea of hardening, but nobody outside Canonical can confirm it.
What a partial outage should look like on a status page
Atlassian's Statuspage documentation defines a partial outage as a component that's completely broken for a subset of customers, and a major outage as a component that's completely unavailable. The unit in both cases is the component, one per functional part of your service. Statuspage also doesn't monitor anything itself. It shows what you tell it, or what an integration feeds it.
Canonical's status page followed the same shape. The screenshot OMG! Ubuntu published showed a major outage listed against several of the websites, not one banner for the whole company. That's what let someone reading it mid incident tell "ubuntu.com is down" apart from "Ubuntu is down."
If you give clients a public status page, copy that. One component per property, so a failing API doesn't paint the marketing site red. And host the page somewhere that isn't under the same attack, because a status page nobody can load is just a decoration.
Set up monitors so a partial outage wakes you up
Detection is half the job. If the alert is an email, a four hour incident can sit unread in an inbox. SIOPS is built around that gap. The alarm is a native system alarm on the same channel as your morning alarm clock, so silent mode and Do Not Disturb don't swallow it.
For a setup like the Canonical split, we'd do it like this. Paste the URL for each property you care about: the homepage, the docs site, the API endpoint, the feed your tooling depends on. Give each monitor its own alarm tone. When your phone goes off, the sound tells you which property failed before you've unlocked the screen, and one tap on the lock screen acknowledges it so you can decide what to do next.
On limits, Hobby is free and covers 5 sites, with 1 alarm and a 5 minute polling interval. Serious is $3.75 a month per project when billed monthly (the yearly toggle shows a 20 percent saving). It covers 10 sites, unlimited alarms and a 60 second polling interval, which is where separate tones per property make sense. Each monitored site also gets a public status page on a siops.app subdomain that updates itself, so clients get a per property view without anyone typing updates mid incident.
You can start on the free plan at siops.app.
