StatusCake

What Causes Website Downtime?

man-on-bike

We’ve all experienced websites which are unreliable, and appear to be offline when we need to access them. Perhaps you have had a similar experience with your own website, and know-how damaging downtime can be to your bottom line and to your brand image.

Whether a website is ‘down’ for an extended period of time, or for a matter of minutes, it can be extremely frustrating for anyone who is trying to access the site in that period. With improvements in cyber-security, computer hardware, and hosting coverage, website downtime is arguably less common than it was 5-10 years ago. However, this means that users are accustomed to having the information they require at their fingertips at all times. An experience with a website that is unable to meet these high standards is likely to result in a lasting negative impression that may be hard to shift.

In this article, we take a closer look at some of the causes of website downtime.

What is Website Downtime?

In its simplest form, website downtime occurs when a website is completely inaccessible to end-users. However, it is more often the case that only certain sections or elements of a website are inaccessible at any given time. For example, an e-commerce website where users are unable to complete a checkout would also be considered to be experiencing some form of downtime. In fact, it is often the case that the latter example can be even more frustrating to the end-user than a website that is completely inaccessible.

What Causes Website Downtime?

IT System Malfunctions

Each year the IT systems we use in the business world become faster, more adaptable, and more reliable. Despite this, the infallible IT system has yet to be created, and any single piece of IT hardware or software is subject to malfunction. When one of the components in an IT system fails, it can result in any number of issues for the IT infrastructure of an organisation, one of which is the status of the company website. Many such errors are relatively commonplace and will have no impact on website uptime at all. However, for companies who host their own website, any malfunction in the server hardware is likely to result in a period of downtime for the website.

Hosting Provider Errors

Downtime can be caused by a company’s internal servers malfunctioning, but most companies choose to host their website with a third-party provider, rather than internally. Generally speaking, this should minimise the risk of your website going offline, but only if you entrust your website into the hands of a reliable web hosting provider.

Cheaper web hosting providers are likely to offer an affordable hosting plan, but this will often come at the cost of reliability. Companies that offer cheaper web hosting may be using outdated server software, obsolete IT infrastructure, or non-virtualised servers.

Alternatively, your website could go offline because you have chosen a cheaper hosting plan, and you’ve experienced an unexpected spike in traffic. Even worse, perhaps you’ve forgotten to renew your web hosting plan altogether!

As you can see, web hosting is crucial to ensuring the constant uptime of your website. For more info, check out our article on How to Choose a Web Hosting Provider.

DDoS (Distributed Denial of Service)

While such instances are relatively rare, a DDoS attack (distributed denial-of-service) can take your website offline very quickly.

The purpose of a DDoS attack is to ‘deny service’ by overloading a server with abnormally high levels of traffic. This occurs by ‘jamming’ traffic to a server, resulting in a disruption of service for anyone else trying to access the website hosted on the server under attack.

A DDoS attack can pose a significant disruption to the normal functionality of a website and can result in an extended period of website slowdown and/or complete outage in the most severe cases.

Planned Downtime

Finally, one of the most common causes of websites being made inaccessible to the end-user is actually ‘planned downtime‘. Planned downtime occurs when an IT team undertakes an internal system update, such as upgrading hardware or software, integrating new equipment, or uninstalling redundant IT assets with the aim of improving the overall functionality of the company’s IT infrastructure. As planned downtime is accounted for in advance, potential website visitors should be forewarned if at all possible that they can expect to find the website offline in a certain time period. This will help to set expectations, and to minimise any potential customer or client dissatisfaction in the event that they attempt to access the website during the period of planned downtime.

A dedicated website uptime monitoring service can help you to proactively address any period of downtime by alerting you the moment your website goes offline. StatusCake provides a suite of performance monitoring tools that are easy to set-up and use, and provide you with invaluable insights into how your website performance is impacting your customers’ experiences. Our free plan includes a range of free tools, including page speed monitoring, while our paid plans include SSL Monitoring, Server Monitoring, Domain Monitoring, and Virus Scanning.

Share this

More from StatusCake

Buy vs Build in the Age of AI (Part 1)

5 min read AI Has Made Building Monitoring Easy. It Hasn’t Made Owning It Any Easier. A few months ago, I spoke to an engineering manager who proudly told me they had rebuilt their monitoring stack over a long weekend. They’d used AI to scaffold synthetic checks. They’d generated alert logic with dynamic thresholds. They’d then wired everything

Alerting Is a Socio-Technical System

3 min read In the previous posts, we’ve looked at how alert noise emerges from design decisions, why notification lists fail to create accountability, and why alerts only work when they’re designed around a clear outcome. Taken together, these ideas point to a broader conclusion. That alerting is not just a technical system, it’s a socio-technical one. Alerting

Designing Alerts for Action

3 min read In the first two posts of this series, we explored how alert noise emerges from design decisions, and why notification lists fail to create accountability when responsibility is unclear. There’s a deeper issue underneath both of those problems. Many alerting systems are designed without being clear about the outcome they’re meant to produce. When teams

A Notification List Is Not a Team

3 min read In the previous post, we looked at how alert noise is rarely accidental. It’s usually the result of sensible decisions layered over time, until responsibility becomes diffuse and response slows. One of the most persistent assumptions behind this pattern is simple. If enough people are notified, someone will take responsibility. After more than fourteen years

Alert Noise Isn’t an Accident — It’s a Design Decision

3 min read In a previous post, The Incident Checklist: Reducing Cognitive Load When It Matters Most, we explored how incidents stop being purely technical problems and become human ones. These are moments where decision-making under pressure and cognitive load matter more than perfect root cause analysis. When systems don’t support people clearly in those moments, teams compensate.

The Incident Checklist: Reducing Cognitive Load When It Matters Most

4 min read In the previous post, we looked at what happens after detection; when incidents stop being purely technical problems and become human ones, with cognitive load as the real constraint. This post assumes that context. The question here is simpler and more practical. What actually helps teams think clearly and act well once things are already

Want to know how much website downtime costs, and the impact it can have on your business?

Find out everything you need to know in our new uptime monitoring whitepaper 2021

*By providing your email address, you agree to our privacy policy and to receive marketing communications from StatusCake.