Website reliability lab

Four choices that decide whether a fictional shop’s website stays up and can be recovered. Then, if you like, diagnose outages step by step.

Time: About 4 minutes an outage
Related service: Web Infrastructure

Fictional data, run in your browser. It doesn’t connect to, scan or change any real system, and nothing you choose is sent to exQ.

This simulation needs JavaScript to respond to your choices. Its starting example and explanations are shown below.

Illustrative simulation

Step 1 of 4

Try it in a minute

A fictional online shop. Four choices decide whether its website stays up, stays secure and can be recovered.

Who controls the shop’s domain name (its web address)?

Want more? The full simulation has more settings, more scenarios and the reasoning behind every result.

Explore in more depth

Illustrative simulation

A fictional site, www.shop.example. Nothing here contacts a real domain.

The site uses a CDN

Some visitors reach the old website

Since this morning, some visitors see last year’s website, and others get a security warning.

Visitors in different places report different things; the office sees the right site.

The request path

Supporting services

Components change as your checks find them fine, suspect or at fault. Select any component to see what it does.

Run checks

Each check reads one part of the path. Choose the ones that narrow it down fastest.

Possible causes

The domain’s registration has lapsedPossible
A DNS record points to the wrong placePossible
A certificate problemPossible
The CDN is serving stale copiesPossible
The hosting is downPossible
The application or its database is failingPossible

A cause is only marked confirmed when your checks establish it.

Your reliability checklist

Ten things that keep a website and its email running. The ones this outage touched come first.

Reliability checklist

After “some visitors reach the old website”

Illustrative

This outage

Cause not yet established.

Checklist

DNS inventory and change controlRelevant to this outage
Every record is documented, and changes are made by named people and recorded.
Access controlRelevant to this outage
Registrar, DNS, hosting and CDN accounts belong to the company, use MFA and are reviewed.
Monitoring and alertingRelevant to this outage
Alerts reach someone who can act, out of hours if the business needs it.
Documentation and handoverRelevant to this outage
Who hosts what, who has access and how to change it is written down where the business can find it.
Domain ownership and renewal
The domain is registered to the company, on auto-renew, with notices going to a shared address someone reads.
Certificate renewal and monitoring
Certificates renew automatically, and expiry is monitored from outside with alerts weeks ahead.
Hosting and application health
Monitoring tests key journeys, such as checkout, from outside, not just the home page.
Backup and recovery
The site and its database are backed up away from the hosting, and a restore elsewhere has been tested.
CDN and caching
Caching rules match how often content changes, and publishing purges what changed.
Email configuration
Email records (MX, SPF, DKIM, DMARC) are documented and changed separately from the website’s.

Remember

Domain registration, DNS, hosting, the application and email are separate things, often with separate suppliers and logins. Knowing who holds each one is half of fixing any outage.

What the reliability lab shows

A website depends on a chain of separate services, often from separate suppliers. Most outages are one link in that chain.

Five things that are easy to confuse
Domain registration is your right to the name. DNS says where the name points. Hosting runs the site. The application is the site’s software, with its database behind it. Email is a separate service that shares only the domain and its DNS.
Follow the request
Diagnosis goes faster when you follow the path a request takes: does the name resolve, to the right place, with a valid certificate, through the CDN, to hosting that responds, running an application that can reach its data? Each check rules part of the path in or out.
A likely cause isn’t a confirmed one
A security warning can come from an expired certificate or from DNS sending visitors to the wrong server. Confirming the cause before changing things avoids fixing the wrong link, and the simulation only marks a cause confirmed once the evidence establishes it.
Caching hides changes and outages alike
A CDN keeps copies of pages close to visitors, which makes a site fast and resilient, but also means a change can take hours to reach everyone unless the right pages are purged. DNS answers are cached too, for as long as each record’s TTL.
Most outages are administrative
An unrenewed domain, notices going to a former employee, a record changed by a previous supplier, a certificate whose renewal quietly failed: none is technically hard, and all are prevented by ownership, documentation and monitoring.
Monitor the journey, not just the home page
A home page that loads says little about checkout. Monitoring from outside should test the journeys that earn money, the certificate’s expiry and what the domain resolves to, and alert someone who can act.

Improve your website infrastructure with exQ.

The Lab shows the principles. Your environment, requirements and priorities decide the answer, so tell us about them. We reply to every enquiry within one business day.

Let’s talk Book a free consultation