Website Resilience for Business Owners: What June's Platform Outages Really Taught Us

I have spent a good part of the past fortnight reading other people's incident reports. June has been a rough month for the platforms we are all told never go down.

On 3 June, Shopify resolved an outage that ran for roughly two hours. According to the payments publication PYMNTS, the company posted the first status update at 9:27am Eastern, said it had identified the problem just after 10:30am, and marked it resolved by 11:31am. Checkouts, storefronts, admin access and point of sale were all affected, and Search Engine Land reported more than 3,000 problem reports on DownDetector, with most of them about stores simply not loading. Some shops resolved to a blunt "this store does not exist" page. One merchant put it well: "Having our stores resolve to that page is insane."

The same week, Microsoft Exchange Online suffered a mail flow failure that delayed or blocked email across North America, the Asia-Pacific region and Europe for the better part of two days. As BleepingComputer reported, Microsoft deployed a fix, then had to withdraw it after it caused fresh queueing in regions that had been fine.

Here is the part worth sitting with. Neither company is careless. Both are run by serious engineers with budgets most of us will never see. That is the lesson, not an exception to it. Every platform fails eventually. The only thing that varies between one business and the next is what you can actually do about it when it happens.

This is a reference piece, not a hot take. It lays out the questions worth answering about your own website before the next outage, rather than during one. And it is honest about where each option, including ours, runs into limits.

Resilience Is Not the Same as Uptime

Most conversations about reliability get stuck on a single number: the uptime percentage on a hosting sales page. That number matters less than people think.

A "99.9% uptime" guarantee sounds airtight. It still permits roughly nine hours of downtime across a year, and most guarantees only ever refund a fraction of your hosting fee, never the revenue you lost while the site was dark. I have pulled apart what those guarantees actually promise before, in our look at what a 99.9% uptime figure really means, so I will not repeat it all here. The short version: treat uptime as one data point about a provider's track record, not as a force field.

Resilience is the bigger and more useful idea. It is not the claim that your site never goes down. It is the set of things that decide how badly an outage hurts and how quickly you come back. It sits alongside raw speed and good engineering in the wider picture of how a site is built and operated, which we cover in our complete WordPress performance guide for business owners.

Strip it back and resilience comes down to five questions. Who owns your storefront? When it breaks, what can you do? If data is lost, can you get it back? Who responds when it fails at the worst hour? And where does your data actually live? The table below is the short answer. The rest of this article is the long one.

When something goes wrong	A platform you do not control	A WordPress site you own on managed hosting
Who owns the storefront	They do. You rent access to it	You do. Full export of site and data, any time
When it breaks	You refresh a status page and wait	You have staging, a rollback, and a number to call
If data is lost	Whatever their policy allows	Verified nightly backups, restored in one step
Who responds at 2am	A support queue, eventually	A named operations team in your own timezone
Where your data lives	Wherever they decide to put it	On Irish infrastructure, under EU jurisdiction

Who Actually Owns Your Storefront?

The "this store does not exist" message during the Shopify outage was a small thing technically. It was a large thing psychologically, because it reminded thousands of owners of something they rarely think about: the storefront is not really theirs. They rent access to it.

When you build your business on a closed platform, you are building on rented ground. It is comfortable ground, well kept, and on a normal day you would never notice the difference. You notice it on the abnormal day, and you notice it again the day you want to move, export everything, or do something the platform has decided you cannot.

Owning the platform is the other model. WordPress powers around 43% of the entire web, according to the web technology survey W3Techs, which is not a fashion. It is the closest thing the web has to a standard. A WordPress site is yours: you can export it, back it up off-platform, and move it to another host if you ever need to. So what does that mean on the bad day? It means an outage is an inconvenience you can act on, not a locked door you can only stand outside of.

When It Breaks, What Can You Actually Do?

This is the question that separates a frustrating morning from a helpless one.

On a fully hosted platform, when the outage is at their end, your options are thin. You can refresh a status page. You can post an apology to your customers. You can wait. That is genuinely the whole list, and it is not a criticism of any one platform, it is the nature of renting infrastructure you cannot reach.

On a site you operate, you have moves available. If a bad plugin update took the site down, you roll back to the previous version. If you want to test a fix before it touches customers, you deploy it to a staging environment first and verify it there. If the problem is a single failed component, a managed host can fail over or restore around it without you lifting a finger. None of this makes you a developer. It makes you an operator with options, which on a Friday afternoon is worth a great deal more than a sympathetic status page.

The catch, and there is always a catch worth naming, is that options only help if they exist before the incident. Nobody sets up staging at 3pm while the checkout is down. The work is done quietly, in advance, or it is not done at all.

Backups Are the Line Between a Bad Day and a Rebuild

If there is one finding from this month's reading that every owner should sit with, it is this. The Munster Technological University and the NCSC published a study of SME cyber resilience late last year, and as the law firm Matheson summarised it, resilience among smaller firms is critically low. Roughly seven in ten have no automated backup solution. Almost nine in ten have no tested business continuity plan. These are not edge cases. This is the normal state of things.

Now picture the consequence, because the statistic does not land until you do. A site goes down hard, or gets compromised, and there is no usable backup. You are not restoring at that point. You are rebuilding. Every page, every product, every customer record, recreated from memory and old emails. For a Waterford manufacturer running a trade catalogue site with hundreds of products, that is not an afternoon. That is weeks, and the phone does not stop ringing while you do it.

Proper backups change the worst case entirely. The standard worth holding any host to is automatic nightly backups, a snapshot taken automatically before any risky change such as an update, and a restore that runs in one step rather than a support ticket. Web60 does exactly this as part of the platform: nightly backups, pre-update and pre-restore safety snapshots, and one-click restore, with manual backups on demand when you want one. So what does that buy you in plain terms? On the worst day, you lose a single day's work instead of everything. You can read the full detail in our guide to WordPress security and backups.

One honest limit, because a backup oversold is worse than no backup at all. A backup is only ever as good as its last successful run and its last tested restore. If you take forty orders after the nightly backup and the database corrupts at eleven that night, those forty orders are gone. That is the deal. The alternative, no backup at all, means losing the lot, so know the tradeoff and plan around it for anything that touches live customer data.

Who Is Awake When It Fails at 2am?

I am the person who gets the alert when something goes wrong at an unsociable hour, so I have a strong view here.

A platform outage at 2am on a bank holiday is not a hosting problem. It is a business continuity problem, and the difference between the two is whether a human responds. On a lot of cheap hosting, and on some very large platforms, the honest answer at 2am is a queue and an automated acknowledgement. The same MTU and NCSC work found that most smaller firms rely on the owner alone for their cyber response and have no tested plan. So the person who answers at 2am is you, on your phone, with no idea what to do.

That is the gap a real operations team fills. Monitoring that notices the problem before your customers do. People in your own timezone who can investigate, roll back, restore, or fail over, and who do incident response for a living rather than for the first time tonight. Web60's support and operations are handled by a real Irish team, not an outsourced queue, which means the person looking at your site understands it and is awake when you need them.

Here is the mistake that taught me to take this seriously. Early on, I trusted a nightly backup job because the dashboard showed a green tick every morning. The day we actually needed it, the restore came back missing its database. The files were there. The data was not. We changed our process that week, and a backup has not counted as done in my book since, not until a restore has been verified. A green tick is a claim. A tested restore is a fact.

Where Does Your Data Actually Live?

The last resilience question is the one owners think about least and regulators think about most. Where, physically, is your website and its backups stored, and who has access?

When your data is scattered across infrastructure in other jurisdictions, you inherit uncertainty. You cannot always say where it sits, which laws govern it, or who can reach it. For an Irish business, that turns a simple GDPR position into a complicated one. Hosting on infrastructure physically located in Ireland keeps your site and its data under Irish and EU jurisdiction, so you can answer those questions plainly. Web60 runs on enterprise-grade Irish infrastructure, on SmartHost's sovereign Irish cloud, with all data kept in Ireland. If you want the detail on the stack and where it sits, the enterprise Irish infrastructure behind every Web60 site is laid out in full.

Two caveats keep this honest. Knowing where your data lives removes a lot of uncertainty, but it does not remove every compliance obligation, so still document your processing in your privacy policy. And data location is one input to resilience, not the whole of it. A site hosted perfectly in Ireland with no backups is still one bad night from a rebuild.

The Honest Exception

Now the part where I argue against my own grain, because a one-sided case is not a useful one.

If you sell a handful of products to a global audience, and you genuinely never want to think about a server, a setting, or an update, a fully hosted platform is a real answer. It takes the infrastructure question off your plate entirely. On a normal Tuesday that is excellent value, and for some owners it is the right trade made for the right reasons. You are renting certainty, and most of the time the rent is fair.

The trade only shows its price on the abnormal Tuesday. When that platform is down, there is nothing for you to do but wait, and you do not own the storefront you have spent years building. For a lot of local firms, especially anyone selling something they want to keep control of, that trade is worth re-examining. For some, it is exactly right. Resilience is not about picking the platform with the best marketing. It is about choosing the trade with your eyes open.

How to Pressure-Test Your Own Resilience in Five Steps

You do not need to be technical to run this check. You need an afternoon and a willingness to find out the awkward answers now rather than later.

Verify your last restore. Do not confirm a backup exists. Restore it somewhere safe and watch your data actually come back, including the database, not just the files.

Identify who you call. Write down exactly who responds when the site is down at the worst possible hour, and how quickly. If the answer is "me, alone," that is the gap.

Confirm where your data lives. Know the country your site and its backups are physically stored in, and who is able to access them.

Clone before you change. Test every update on a staging environment first, where your hosting offers one, so a bad plugin breaks a copy and never your production site.

Own your platform. Keep the ability to export your whole site and move it elsewhere, so no single provider can ever hold your business to ransom.

If assembling all of that yourself sounds like a second job, that is rather the point of managed hosting. A platform such as Web60 folds the nightly backups, one-click restore, staging, monitoring and an Irish operations team into the one €60 a year, so resilience is the default state rather than a project you keep meaning to start.

Conclusion

Outages are not a sign that something is broken with the web. They are a normal property of it. The biggest, best-funded platforms in the world went dark this month, and they will again, and so will everyone else eventually.

What that means for you is quieter and more useful than any headline. Resilience is not a product you buy once. It is a short list of decisions, mostly made in advance and mostly boring: own enough of your site to have options, keep backups you have actually tested, know where your data lives, and make sure a real person answers when it matters. The platforms cannot make those decisions for you, and the next outage will not wait for you to make them.

So take the afternoon. Run the five-step check on your own site, find the awkward answers, and fix the one that worries you most. That is a far better use of this month's outages than another apology posted to a status page.

Frequently Asked Questions

What does website resilience actually mean?

Resilience is not the promise that your site never goes down, because no platform can honestly make that promise. It is the set of things that decide how badly an outage hurts and how fast you recover: whether you own and can export your site, whether you have verified backups and a quick restore, whether changes are tested on a staging copy first, and whether a real operations team responds when something breaks.

Does a 99.9% uptime guarantee mean my website will not go down?

No. A 99.9% annual guarantee still allows for roughly nine hours of downtime a year, and most guarantees only refund a slice of your hosting fee, never the sales you lost. Treat an uptime figure as one data point about a provider's track record, not as a promise that your site is immune.

If I am on a hosted platform like Shopify, am I safe from outages?

No platform is immune. On 3 June 2026 Shopify resolved a roughly two hour outage that affected checkouts, storefronts, admin and point of sale, and Microsoft Exchange Online had a multi-day mail flow failure the same week. The real difference with a fully hosted platform is that when it goes down you can do very little except wait, because you do not control the infrastructure underneath it.

How often should my business website be backed up?

At minimum, automatic nightly backups, plus a snapshot taken automatically before any risky change such as a plugin update. The frequency matters less than two other things: that the backups restore in one step, and that you have actually tested a restore. A backup you have never tested is a hope, not a safety net.

Where should an Irish business host its website for data protection?

Hosting on infrastructure physically located in Ireland keeps your site and its data under Irish and EU jurisdiction, which simplifies your GDPR position and means you know exactly where your data lives and who can reach it. It does not remove every obligation, so still document your processing in your privacy policy, but it removes much of the uncertainty that comes with data scattered across other jurisdictions.

Sources