Every hosting company sells uptime, and almost every hosting company sells it with a number: 99.9%, 99.99%, occasionally five nines. The number is presented as the answer to a question, and it is worth being precise about what question it actually answers.
It answers: how often did our server respond to a request?
The question a business owner is actually asking is: how often was my website working?
Those are not the same question, and the gap between them is where most real downtime lives. A WordPress site can return a clean HTTP 200 response with a white screen where the content should be. It can serve a homepage perfectly while the checkout throws a fatal error. It can load in two seconds for a visitor in Toronto and time out for a visitor in Halifax. It can look entirely healthy while the contact form has been silently failing to send for eleven days. Under every uptime SLA in the industry, all four of those sites were up.
This article is about the difference. What actually takes WordPress sites offline — which is almost never a hardware failure — what a managed environment genuinely prevents, what it demonstrably cannot prevent no matter what the sales page says, and how to monitor your own site in a way that catches the failures the uptime number is blind to.
It is written for Canadian business owners and the people who look after their sites: the ones who have been told managed WordPress hosting is more reliable, and want to know specifically what that buys and where the limits are.
What an uptime SLA actually measures
Start with the arithmetic, because most people have never done it.
| SLA figure | Downtime allowed per month | Per year |
| 99.0% | 7 hours 18 minutes | 3 days 15 hours |
| 99.5% | 3 hours 39 minutes | 1 day 19 hours |
| 99.9% | 43 minutes | 8 hours 46 minutes |
| 99.95% | 21 minutes 54 seconds | 4 hours 23 minutes |
| 99.99% | 4 minutes 19 seconds | 52 minutes 36 seconds |
| 99.999% | 26 seconds | 5 minutes 15 seconds |
Two things jump out. First, the difference between 99.9% and 99.99% is not a rounding detail — it is the difference between nearly nine hours a year and under an hour. Second, 99.9% sounds excellent and permits a full working day of outage across a year.
Now the more important part: what the measurement covers.
Read any hosting SLA carefully and you will usually find that "uptime" means the server responds to a request from the provider's own monitoring system. That definition typically excludes:
- Scheduled maintenance windows, which are announced and therefore not counted
- Outages caused by your code, your plugins, or your theme
- Outages caused by a traffic spike exceeding your plan's resources
- DNS problems, since DNS is often not the host's system
- Anything upstream — a network issue between the visitor and the data centre
- Application-level failure, which is the big one
That last exclusion is where the definition and reality separate. A server that responds is a server that is up. A WordPress installation throwing a PHP fatal error is also responding — often with a 200 status and an empty page, sometimes with a 500. Your visitor sees a broken site. Your provider's monitor sees an answered request.
What the SLA credit is actually worth
The second thing worth reading is the remedy. When a provider breaches its uptime commitment, the standard remedy is a credit against your hosting fee, usually calculated as a proportion of the monthly charge and usually capped at that month's fee. You must normally claim it, within a window, with evidence.
So consider a shop paying $30 a month for hosting that suffers a four-hour outage on a Saturday in December. The lost revenue might be several thousand dollars. The SLA remedy is a credit of a few dollars against next month's invoice.
This is not a scandal — no hosting provider at any price could underwrite its customers' revenue, and the pricing reflects that. But it does mean the SLA is not insurance and should not be read as one. It is a statement of intent with a token penalty attached. The actual protection against downtime is architectural and operational, not contractual, which is what the rest of this article is about.
What actually takes WordPress sites down
Here is the part the vendor pages skip. In practice, hardware failure is a small minority of WordPress outages. The common causes are software, configuration, and administration — and they are remarkably consistent.
| Cause | What it looks like | Whose fault |
| Plugin or theme update conflict | White screen, or a fatal error naming a file | Yours, usually |
| PHP fatal error from incompatible code | "There has been a critical error on this website" | Yours |
| Memory exhaustion | "Allowed memory size of X bytes exhausted" | Shared — code and plan |
| PHP version upgrade breaking old code | Site dies on a date you did not choose | Host's schedule, your code |
| Database connection failure | "Error establishing a database connection" | Usually the host or a traffic spike |
| Crashed or corrupted database table | Partial failure — some pages work, others do not | Server-level, often disk or an unclean shutdown |
| PHP worker exhaustion under load | Timeouts, 503s, or a spinner that never resolves | Plan capacity versus real concurrency |
| Disk quota full | Uploads fail, then the database refuses writes | Usually backups, logs, or a bloated database |
| Expired TLS certificate | Full-page browser security warning | Renewal process |
| Expired domain registration | Site and email both vanish | Registrar admin |
| DNS misconfiguration | Works for some visitors, not others | Whoever last edited the zone |
| Compromise leading to suspension | Host takes the site offline to protect the network | Security posture |
| Bot floods and brute-force traffic | Resource exhaustion under low human traffic | Hostile third party |
| Third-party API failure | One feature breaks, the page may still load | External vendor |
Four of these deserve a closer look because they cause a disproportionate share of real outages and are widely misunderstood.
Memory exhaustion
WordPress runs with a PHP memory limit, and WordPress itself applies its own limit on top of the server's. When a page request needs more memory than it is allowed — a large import, an image operation, a poorly written plugin looping over too many rows — the request dies. Sometimes that produces an explicit error, sometimes a blank page.
The cause is often invisible and cumulative. A WordPress installation that has been running for six years typically carries a bloated options table full of data that loads on every single page request, along with thousands of expired transients that were never cleaned up. Every one of those is memory spent before your content is even assembled. The site did not change on the day it broke; it had been getting closer to the ceiling for years. We cover the database side of this in more detail in our piece on slow database queries.
Resource exhaustion under concurrency
Uncached requests are served by PHP processes, and every hosting plan allows a finite number of them at once. When more uncached requests arrive than there are processes to serve them, requests queue; when the queue grows faster than it drains, they time out.
The important and counter-intuitive part is that this can happen at traffic volumes that look trivial. A site whose pages are mostly cached can handle very large numbers of visitors. The same site, when visitors are logged in, using a cart, submitting forms, or running searches — all of which bypass the cache — can saturate on a fraction of that traffic. This is why a site that has been fine for two years falls over during its first successful campaign, and why "we don't get much traffic" is not the reassurance it sounds like. Where this is the recurring pattern, the answer is capacity — a dedicated resource allocation via VPS hosting or a managed plan with a defined worker count — rather than another caching plugin.
The two administrative outages
These deserve special mention because they are the most preventable and the most humiliating.
Certificate expiry. A TLS certificate that lapses does not degrade gracefully. Every visitor gets a full-page browser warning telling them the site may be dangerous. The site is technically up; nobody will reach it. Automated renewal solves this, but automated renewal fails silently more often than people expect — a DNS change, a redirect, or a validation path breaking will quietly stop renewals while the existing certificate is still valid, and you find out ninety days later. SSL certificates need monitoring, not just automation.
Domain expiry. The site and the business email disappear simultaneously, which means the expiry notices went to an address that no longer works. Recovery may involve redemption fees and days of delay. No hosting plan at any price protects against this. The only protection is auto-renewal on a card that is current, with the registrar contact set to an address on a different domain.
What managed WordPress hosting actually does about this
Now the useful question. Given that list, what does a managed environment genuinely change?
The honest framing is not that managed hosting eliminates downtime. It is that it converts a category of outages from "you find out when a customer emails you" into either "it did not happen" or "it was reverted in four minutes." That is a real and substantial difference, and it comes from a specific set of capabilities rather than from a marketing adjective.
A staging environment. A copy of the live site where updates and changes are applied and checked before they touch production. This single capability addresses the largest cause on the list. Unmanaged hosting rarely provides it, and the practical consequence is that most small business sites are updated directly on production, which means every update is a live experiment.
Restorable backups with a tested restore path. Every host claims backups. The questions that matter are how far back they go, whether you can restore the database alone without the files, how long a restore takes, and whether anyone has ever actually performed one. A backup that has never been restored is a hypothesis. On a managed plan, a rollback should be an operation you can trigger yourself in minutes, not a support ticket with a queue.
PHP version management. PHP releases reach end of life on a published schedule, after which they stop receiving security fixes. Hosts must eventually move customers forward, and that migration is a classic source of sudden breakage for sites running old plugins. A managed environment should give you advance notice, a way to test the new version on staging, and the ability to revert. An unmanaged one may simply change it.
Server-level caching and an object cache. Relevant to uptime rather than just speed, because caching is what stops ordinary traffic from consuming PHP processes. A properly cached site survives a traffic spike that would take an uncached one down. The speed benefits are covered separately in our guide to Core Web Vitals and hosting; the availability benefit is the one that matters here.
Traffic filtering and login protection. A web application firewall, rate limiting, and blocking of the well-known WordPress attack surfaces — repeated login attempts, XML-RPC amplification, and the automated scanners that hammer every WordPress site on the internet continuously. Much of what looks like a traffic spike on a small site is not human traffic at all, and filtering it at the server level rather than inside PHP is the difference between absorbing it and being flattened by it.
Malware scanning and remediation. Compromise causes downtime in two ways: the attacker's code breaks the site, or your host takes the site offline to protect its network and other customers. Managed plans typically include scanning and, importantly, a remediation path — because finding malware and being able to remove it cleanly are different services.
Resource isolation. On an oversold shared server, another customer's bad day becomes your bad day. Isolation between accounts is one of the least-discussed and most consequential differences between hosting tiers.
Monitoring that someone actually watches. The value is not the monitor; it is that a human or an automated process responds at 3am on a Sunday. This is most of what you are paying for on a managed plan, and it is the hardest thing to evaluate before you need it.
That is the genuine list. If a managed WordPress hosting plan does not provide staging, self-service rollback, PHP version control and server-level caching, it is a shared plan with a different label.
The uncomfortable part: automatic updates cut both ways
Here is something the sixteen vendor pages on this topic do not say.
Automatic updates are themselves a leading cause of WordPress downtime.
WordPress has applied automatic background updates for minor core releases by default for over a decade, and since version 5.5 it has offered opt-in automatic updates for plugins and themes. The security argument for all of this is sound — unpatched plugins are the most common route into a WordPress site, and a site nobody updates will eventually be compromised.
But an update is a code change, and code changes break things. A plugin update that changes a hook, a theme update that alters a template, two plugins that each work alone and conflict together — these are not exotic scenarios, they are Tuesday. And when the update applies automatically at 2am, the site breaks at 2am and stays broken until someone notices.
So the correct position is not "enable everything" or "disable everything." It is:
- Security releases should apply quickly. The risk of delay is higher than the risk of breakage.
- Feature updates for plugins should be staged first, particularly for anything touching commerce, forms, or the theme.
- The rollback capability is the actual feature. A host that auto-updates and can revert in two minutes has reduced your risk. A host that auto-updates with no staging and no rollback has increased it, and has done so while describing the change as a reliability feature.
When you evaluate a plan, ask what happens when an automatic update breaks the site, and specifically who notices, how fast, and what they do. The answer to that question tells you more about the plan's real reliability than any percentage on the pricing page.
What managed hosting cannot prevent
Honest limits, because an article that claims managed hosting solves downtime is a sales page.
Your domain expiring. Covered above. No hosting plan touches this.
Your own changes. If you install a plugin on production and it conflicts, the environment gives you a fast way back, not immunity.
A third-party dependency failing. Payment gateways, booking platforms, mapping services, font services, chat widgets, review feeds — when one of those goes down, part of your site goes with it, and no hosting arrangement changes that. Worth knowing which of your features have an external dependency, because that list is usually longer than people assume.
Your DNS provider. If DNS is hosted elsewhere and that service has an outage, your site is unreachable regardless of how healthy the server is.
A sufficiently large attack. Filtering and rate limiting handle ordinary hostile traffic. A genuinely large volumetric attack exceeds what any standard plan absorbs, and mitigation at that scale is a separate service.
Registrar or account problems. A billing failure, an expired card, an unverified contact address, a transfer dispute — these take sites offline through the front door and no amount of server engineering intervenes.
Human error in the admin. Someone deletes a page, changes the site URL, activates maintenance mode and forgets, or edits the theme file directly. Managed hosting gives you a backup to restore from. It does not give you an undo button for judgement.
Uptime and SEO, briefly
This gets over-dramatised, so the short version.
A brief outage does not hurt your rankings. Googlebot requests a page, receives an error, and comes back later. A few minutes of downtime is not a search problem.
Sustained or repeated failure is different. When a site returns server errors persistently, Googlebot reduces its crawl rate to avoid making the problem worse, which delays discovery of new content and can eventually affect how pages are treated. For planned outages there is a correct technical answer: return HTTP 503 with a Retry-After header rather than a 500 or a 200 with an error page, which tells Google explicitly that the condition is temporary.
The wider relationship between server behaviour and search rankings is covered properly in our hosting and SEO pillar; there is no value in repeating it here.
Monitoring: how to actually know your site is working
This is the section that turns the article into something usable, because it addresses the failure the uptime number is structurally blind to.
A status-code check is not enough. Most free monitors request your homepage and record whether it returned 200. That catches a dead server. It misses a fatal error rendering an empty page with a 200, a checkout that throws an error two steps in, a cached page served correctly while everything uncached fails, and every silent failure below.
Assert on content, not on status. Configure your monitor to look for a specific string that only appears when the page rendered properly — a phrase from your footer, a product price, the label on your primary button. If the string is absent, treat it as an outage regardless of the status code. This one change catches the majority of failures that status-only monitoring misses.
Monitor the transaction, not the homepage. Your homepage is the most cached and most resilient page on the site. The pages that matter — checkout, booking, quote request, login, member area — are the least cached and the most fragile. Monitor those.
Check from more than one location. A route problem or a regional DNS issue produces exactly the pattern where the site is fine from where you sit and unreachable elsewhere. For a Canadian business, monitor from at least one Canadian location.
Watch error rate, not just availability. A site serving 4% of requests as errors is not "down" by any SLA definition and is badly broken in practice. Server error logs and application logs tell you this; uptime monitors do not.
Monitor the things that fail silently. These are the ones nobody catches until a customer complains weeks later.
| What to monitor | How | Why it matters |
| Page renders correctly | Content-string assertion, not status code | Catches fatal errors returning 200 |
| Transactional path | Synthetic check on checkout or booking, not homepage | The pages that earn money are the least cached |
| Certificate expiry | Automated check with 30-day warning | Automated renewal fails silently |
| Domain expiry | Calendar reminder plus registrar auto-renew | The most preventable total outage |
| Scheduled tasks | Confirm cron ran in the expected window | Reminders, backups and publishing stop silently |
| Outbound email | Send a test to an external address weekly | Forms fail with no visible symptom |
| Backup success | Verify the file exists and its size is sane | "Backups enabled" is not "backups working" |
| Restore | Perform a real restore to staging, twice a year | An untested backup is an assumption |
| Disk usage | Threshold alert at 80% | A full disk stops database writes |
| Error rate | Server and application logs | Partial failure is invisible to uptime tools |
The restore test is the one people skip and the one that matters most. A business that has never restored a backup does not know whether it has backups; it knows it has files.
The Canadian dimension
Three things that are specific to operating here.
A compromise is not only a downtime event. If a site holding customer information is breached, Canadian businesses have obligations under PIPEDA — reporting to the Office of the Privacy Commissioner where there is a real risk of significant harm, notifying affected individuals, and maintaining records of breaches. That means an outage caused by a compromise starts a legal process alongside the technical one, and your ability to determine what was actually accessed depends entirely on whether your host retains usable access logs and whether your backups are old enough to establish a clean baseline. Ask about log retention before you need it. Our guide to PIPEDA and Canadian data residency covers the wider position.
Where the servers are affects the recovery, not just the performance. Keeping your site in Canadian data centres keeps the data under Canadian jurisdiction, which simplifies both the legal questions above and the answer you give a client who asks. Choosing Canadian WordPress hosting is not a compliance measure by itself — compliance is about practices — but it removes a category of complications from an already difficult week. This is the practical argument for web hosting in Canada rather than the cheapest offshore plan available: not that the servers are inherently better, but that an incident becomes a technical problem rather than a technical problem plus a jurisdictional one. Providers operating Canadian facilities — 4GoodHosting among them, with data centres in Vancouver and Toronto — keep that part of the question closed.
Support hours and the time zone question. If your site fails at 7am Eastern on a Monday and your provider's support is staffed to a different clock, the response time in the SLA and the response time you experience may differ considerably. Ask when support is actually staffed in your local time, whether there is genuine out-of-hours coverage or only a ticket queue, and what happens on Canadian statutory holidays — which do not align with American ones, and which is exactly when a long-weekend outage runs longest. Businesses outside the major centres feel this most acutely, which is part of the argument in our piece on managed hosting for Saskatoon businesses.
Managed, unmanaged, or something else
| Shared, unmanaged | Managed WordPress | Self-managed VPS | |
| Staging environment | Rarely | Standard | If you build it |
| Rollback speed | Manual restore, often a ticket | Minutes, self-service | However fast you are |
| Updates | Entirely yours | Handled or assisted | Entirely yours |
| PHP version control | Host decides | Notice and testing | Yours |
| Caching | Plugin only | Server-level | Yours to configure |
| Traffic filtering | Basic or none | Included | Yours to install |
| Resource isolation | Limited | Defined allocation | Full |
| Who is awake at 3am | Nobody | The provider | You |
| Cost | Lowest | Middle | Low fee, high time cost |
| Best for | Low-stakes sites | Business sites without in-house technical staff | Teams with real operational capacity |
The honest summary: unmanaged shared hosting is not unreliable, it is unattended. Nothing is watching, nothing is staged, and nothing reverts. For a site where a day of downtime is an inconvenience, that is a reasonable trade. For a site where a day of downtime is a week of revenue, it is not, and the gap is not closed by paying more for the same unattended product.
A self-managed VPS can be more reliable than a managed plan — if somebody competent is actually managing it. The failure mode is a VPS set up well by a contractor in 2021 and touched by nobody since, now running an end-of-life PHP version with no backups. That is not a more reliable architecture; it is an unmaintained one with better specifications. When comparing web hosting in Canada across these tiers, the question to ask about each is not what it can do but what it assumes you will do.
A runbook to have in place before you need it
Write this down somewhere that is not on the website.
- Who to contact, with the actual support channel and account number, at the host and the registrar.
- Where DNS is managed, and who has access. This is frequently the missing piece during an incident.
- Registrar login and renewal status, with the contact address on a different domain.
- Where backups live, how far back they go, and the exact steps to restore.
- The last restore test date. If it is blank, that is your next task.
- A staging environment that exists, not one that could be created.
- Monitoring alerts routed to a person, with a phone number, not to an unwatched inbox.
- A maintenance page that returns 503 with Retry-After, ready to deploy.
- A plugin inventory noting what each does and whether anything would break if it were deactivated.
- The external dependency list — every third party your site calls at runtime.
Most of that takes an afternoon. All of it is worthless to assemble during an outage, which is the only time anyone ever tries.
Common mistakes
Buying on the SLA number. It measures server response, excludes most real causes, and pays out in hosting credit. Ask about staging, rollback speed, and out-of-hours coverage instead.
Treating monitoring as a checkbox. A status-code check on the homepage will report excellent uptime for a site that has been broken for a week.
Enabling every automatic update without a rollback path. This increases risk and feels like reducing it.
Assuming backups work. Test a restore. Twice a year. To staging.
Updating on production. If there is no staging environment, every update is a live experiment on customers.
Ignoring the administrative outages. Certificate and domain expiry take down more sites than hardware does, and neither is a hosting problem.
Blaming the host first. Check the error log before opening a ticket. The message usually names the file, and the file usually names the plugin.
Frequently asked questions
What does 99.9% uptime actually mean?
It permits about 43 minutes of downtime per month, or roughly 8 hours 46 minutes per year. It also normally measures only whether the server responded to the provider's monitoring request, and typically excludes scheduled maintenance, outages caused by your own code or plugins, DNS problems, and application-level failures where the server responds but the page is broken.
Does managed WordPress hosting guarantee my site stays online?
No, and any provider implying otherwise is overselling. What it changes is the response: staging prevents a category of update-related outages, self-service rollback shortens the ones that happen, server-level caching and traffic filtering absorb load that would otherwise exhaust resources, and monitored support means somebody notices at 3am. It does not prevent an expired domain, a third-party API failure, or a change you make yourself.
Why does my WordPress site keep going down?
The most common causes, in rough order: plugin or theme update conflicts, PHP fatal errors from incompatible code, memory exhaustion, uncached traffic exhausting the available PHP processes, database connection problems, and a full disk. Hardware failure is rare. Start with the server error log — the message almost always names the file, and the file usually names the plugin.
What does "error establishing a database connection" mean?
WordPress could not reach its database. The usual causes are the database server being down, the connection limit being exhausted by a traffic spike, incorrect credentials after a migration, or a corrupted table. It is one of the few WordPress errors that genuinely points at the hosting layer rather than at your code.
Are automatic updates good or bad for uptime?
Both. Unpatched plugins are the most common route into a WordPress site, so security updates should apply quickly. But an update is a code change and code changes break things, and an automatic update that fires at 2am breaks the site at 2am. The resolution is to apply security releases promptly, stage feature updates for anything touching commerce or the theme, and treat fast rollback as the capability that actually matters.
Does downtime hurt my Google rankings?
Brief outages, no — Googlebot retries. Sustained or repeated server errors do cause Google to reduce its crawl rate, which delays discovery of new content. For planned maintenance, return HTTP 503 with a Retry-After header rather than a 500 or an error page with a 200 status, which tells Google the condition is temporary.
How should I monitor my site properly?
Check for a specific piece of content on the page rather than just the HTTP status code, monitor a transactional page rather than the homepage, check from more than one geographic location, and separately monitor certificate expiry, domain expiry, scheduled tasks, outbound email and backup success. Most of what breaks silently is invisible to a standard uptime monitor.
Is a VPS more reliable than managed WordPress hosting?
It can be, if somebody competent is genuinely managing it. An unattended VPS running an end-of-life PHP version with untested backups is not a more reliable architecture — it is an unmaintained one with better specifications. The question is not which tier is better but whether your business has the operational capacity the tier assumes.
Does hosting in Canada affect uptime?
Not directly — reliability is a function of engineering and operations, not geography. What Canadian hosting affects is the recovery: data stays under Canadian jurisdiction, which simplifies the PIPEDA position if the outage was caused by a compromise, and support hours are more likely to overlap your working day, which shortens the time from failure to response.
What should I ask a host before signing up?
Four questions that reveal more than any percentage: Is there a staging environment and can I roll back myself? How far back do backups go and can I restore the database alone? How do you handle PHP version upgrades? When is support actually staffed in my time zone, including statutory holidays?
Key takeaways
- An uptime SLA measures whether the server responded, not whether your site worked. A WordPress fatal error returning a 200 status counts as uptime under almost every provider's definition.
- 9% permits about 43 minutes of downtime a month; 99.99% permits about four. The SLA remedy is a credit against your hosting fee, not against your lost revenue.
- Hardware failure is a minority cause. Most WordPress outages come from update conflicts, fatal errors, memory exhaustion, resource exhaustion under uncached traffic, and database problems.
- The two most preventable total outages — an expired TLS certificate and an expired domain — are not hosting problems and no plan protects against them.
- What managed hosting genuinely provides: a staging environment, fast self-service rollback, PHP version management, server-level caching, traffic filtering, malware remediation, resource isolation, and somebody awake at 3am.
- Automatic updates are themselves a leading cause of downtime. The rollback capability is the real feature, not the update.
- Brief downtime does not affect rankings; sustained server errors reduce Googlebot's crawl rate. Use HTTP 503 with Retry-After for planned maintenance.
- Status-code monitoring misses most real failures. Assert on page content, monitor a transactional page rather than the homepage, and check from more than one location.
- Certificate expiry, domain expiry, scheduled tasks, outbound email and backup success all fail silently and all need their own monitoring.
- Restore a backup to staging twice a year. An untested backup is an assumption, not a safeguard.
- In Canada, an outage caused by a compromise may also trigger PIPEDA reporting obligations, which makes your host's log retention a legal question as well as a technical one.
Conclusion
The reliability conversation in hosting has been organised around a number that does not measure the thing anyone cares about. That is not a conspiracy — server response is easy to measure and application health is not — but it has produced a market where businesses compare decimal places on a pricing page and then get taken offline by a plugin update, a full disk, or a certificate nobody was watching.
The better question is not "what is your uptime figure" but "what happens when something breaks." Is there a copy of the site where changes get tested first? Can the last change be reverted in minutes, by me, without a support queue? Has anyone restored a backup from it? Is somebody paying attention outside my working hours? Does the monitoring look at the page, or just at the status code?
Those answers are specific, checkable, and far more predictive of how much downtime you will actually experience than any percentage. A provider with good answers and a 99.9% commitment will serve you better than one with weak answers and a bolder number, because the first one is describing how outages get shortened and the second is describing how they get counted.
And a meaningful share of the work is yours regardless of who hosts you. Nobody else will renew your domain, test your restore, or notice that your contact form stopped sending three weeks ago.
The fastest way to find out where you actually stand is to answer four questions about your current setup: do you have a staging environment, can you roll back a bad update yourself, when did you last restore a backup, and does your monitoring check page content or just the status code. Most sites fail at least two of those, and the fixes are not expensive.
4GoodHosting runs Canadian infrastructure from data centres in Vancouver and Toronto, which keeps your site and your data under Canadian jurisdiction — a practical advantage when an incident turns into a privacy question as well as a technical one. If you want to talk through where your current environment is exposed, or you are weighing managed WordPress hosting against staying where you are, bring the answers to those four questions and the conversation will be a short one. Our wider Canadian web hosting range covers the tiers either side of it.
If you do decide to move, our guide to switching hosts without losing rankings covers the migration sequence.
