Who Owns the Outage? Shared Responsibility Between Your Host, Platform and Payment Gateway

Why “Who Owns the Outage?” Matters More Than You Think

Real world examples: checkout fails, but “hosting is fine”

You notice orders have dropped to zero. The homepage loads, product pages work, but customers cannot complete checkout. You contact your host and hear: “The server is up; everything looks fine from our side.”

You then ask your developer, who tests a payment and gets an error from the gateway. You raise a ticket with the gateway, who replies: “Our systems are operational, the error is coming from your site.”

Meanwhile, you are losing sales and everyone is pointing somewhere else.

This is a common pattern for online shops, especially WordPress and WooCommerce sites. Technically, no one is lying. The hosting platform, the website software and the payment gateway can all be “up” individually, while the whole checkout journey is broken.

Why outages are rarely caused by a single thing

Modern websites are chains of services. A typical purchase may involve:

• Your hosting infrastructure
• Your CMS and plugins, such as WordPress and WooCommerce
• A payment gateway and possibly fraud screening tools
• Third party APIs, from shipping rates to marketing pixels

When something goes wrong, there is often a combination of factors:

• A small code change that increases load on the database
• A spike in traffic from a promotion or bot traffic
• A slightly slower response from the payment gateway

None of these alone would “take down the site”. Together they can cause timeouts, abandoned carts and a very confused team.

Understanding who is responsible for which part of the chain helps you diagnose issues faster, set the right expectations with suppliers and avoid gaps in coverage.

What you will be able to do after reading

By the end of this article you should be able to:

• Explain the three main layers involved in most outages
• Read hosting and gateway uptime guarantees with a realistic mindset
• Map out who does what before, during and after incidents
• Identify when unmanaged setups are carrying more risk than you are comfortable with, and when managed options such as Virtual dedicated servers make sense
• Ask clearer questions of your host, your developers and your payment provider when something breaks

The Three Layers: Hosting, Application and Payments in Plain English

Layer 1: Hosting infrastructure (servers, networks, data centre)

This is the foundation. It includes:

• Physical servers and storage in a data centre
• Virtualisation and operating systems
• Networks, firewalls and internet connectivity

You can think of this as the building where your shop lives. The host is responsible for keeping the lights on, the doors unlocked and the utilities working. If the building loses power, your shop is closed even if your products and staff are ready.

Layer 2: Website and platform (WordPress, WooCommerce and plugins)

This is the software that visitors see and interact with. For a lot of businesses that means:

• WordPress as the content management system
• WooCommerce as the ecommerce layer
• A collection of plugins and themes that add features

This is your actual shop: the layout, the till, the displays, the staff training. If you rearrange the shelves and block the fire exit, the building has not failed, but customers cannot move around safely.

Most problems people describe as “the site is down” are actually application issues:

• A plugin update causing a fatal PHP error
• A theme conflict stopping the cart from updating
• Misconfigured caching showing stale or broken pages

Layer 3: Payment gateway and third party services

When a customer pays, your site often calls one or more external services:

• Payment gateways (Stripe, PayPal, Adyen and others)
• Buy now, pay later providers
• Fraud screening and risk scoring tools
• Shipping rate calculators or address validation APIs

These are more like separate companies your shop works with. They may have their own outages or rate limits that affect you even if your host and platform are healthy.

Where these layers overlap and create grey areas

The tricky part is the overlap. Examples include:

• A PHP timeout during payment that might be caused by slow database queries (platform) amplified by tight resource limits (hosting) and a slow API response (gateway)
• Abusive bot traffic hitting your checkout that the host could block at the network level, the platform could rate limit, and the gateway could flag as suspicious
• Mixed content or JavaScript errors introduced by a plugin that only appear when the gateway’s scripts load in production

Responsibility in these zones is usually shared. The host provides tools and capacity, your developers control the application behaviour, and the gateway controls how it handles and responds to requests.

What Your Hosting Provider Is Actually Responsible For

Typical responsibilities on shared hosting, VPS and VDS

Every host is different, but on most shared hosting and VPS setups your provider will typically cover:

• Power, cooling and physical security at the data centre
• Core network connectivity and routing
• Server hardware and hypervisor maintenance
• Base operating system and platform updates, within a defined scope
• Basic monitoring of server availability

On unmanaged VPS or even Virtual dedicated servers, the line often moves. You may become responsible for:

• Configuring web servers (Apache, Nginx) and databases
• Applying security patches at the OS and middleware level
• Tuning performance settings and capacity thresholds

Managed services shift some or all of those tasks back to the provider, in exchange for higher fees and typically a more opinionated setup.

What an uptime guarantee really covers (and what it does not)

Uptime guarantees are usually about the availability of the hosting platform, not your business outcomes. For example, “99.9% uptime” often means the server responds to simple checks over a month.

It usually does not cover:

• Your site being broken by code changes while the server is fully up
• A payment gateway timeout that stops orders but not page loads
• Performance issues such as a very slow but technically “up” site

Our article “Five Nines” and Other Myths: How to Realistically Evaluate Hosting Uptime Guarantees goes deeper into how to interpret these numbers.

Managed vs unmanaged: who owns patching, tuning and incident response

Unmanaged services give you control and flexibility but also responsibility. You or your team must:

• Keep the OS, web server and database patched
• Configure backups and test restores
• Tune performance as traffic grows
• Investigate alerts and incidents in real time

Managed hosting reduces that operational burden. A good provider will typically:

• Maintain the server stack and security patches
• Provide managed backups and recovery support
• Help tune the hosting platform for your application
• Lead incident response on infrastructure problems

This can be particularly valuable for smaller teams, or when downtime would cause significant reputational or financial damage.

Examples: host-owned outages vs customer-owned problems

Host-owned outage examples:

• Data centre power failure that takes your server offline
• Network routing issue that makes the server unreachable
• Storage system fault that corrupts or loses data on the host side

Customer-owned problem examples:

• A plugin update causing fatal errors on the homepage
• A poorly written query locking the database under heavy load
• Misconfigured DNS records pointing your domain to the wrong place

The article Understanding Hosting Responsibility: What Your Provider Does and Does Not Cover explores this division in more detail.

What Sits With Your Platform, Plugins and Developers

Theme and plugin changes that break sites without any server fault

Most outages users experience on WordPress are due to code changes, not hosting failures. Typical examples include:

• Installing a plugin that conflicts with WooCommerce
• Updating a theme that removes or renames critical templates
• Changing PHP versions without checking plugin compatibility

The server can be perfectly healthy while these changes cause errors, white screens or broken layouts. Responsibility here usually sits with:

• Your internal team that applies updates
• Your development or support agency
• Occasionally the plugin or theme vendor

Capacity, caching and code efficiency are not purely “hosting issues”

It is easy to blame the host when the site slows under load. In reality, performance is shared between:

• Infrastructure capacity and configuration
• Application design and database efficiency
• Front end weight, especially images and scripts

For example, a heavily customised WooCommerce store that runs complex queries on every page will struggle even on powerful hardware. Code and database optimisation are development responsibilities, although the host can assist with metrics and recommendations.

Features like the G7 Acceleration Network can help on the hosting side by caching content, filtering abusive traffic and optimising images to formats such as AVIF and WebP, often cutting image weight by more than 60 percent before it reaches visitors. That reduces load on the application, but does not replace the need for efficient code.

How managed WordPress and WooCommerce hosting can change the split

Specialised Managed WordPress hosting or WooCommerce hosting often reshapes responsibilities:

• The provider may manage updates for WordPress core and key plugins, within agreed rules
• There may be staging environments and automated testing to reduce deployment risk
• Platform level caching and performance tuning are often handled by the host

This does not remove the need for good development practices, but it can reduce the chances of a single plugin update taking the site offline without anyone noticing.

Common grey areas: cron jobs, search, reporting and background tasks

Many performance and reliability issues hide in background tasks such as:

• Order export jobs to ERPs or fulfilment systems
• Search indexing or on-site search services
• Email sending, marketing automation and webhooks

These can sit in grey areas:

• The host might provide a cron system, but not manage what runs on it
• Your developers configure the jobs and need to handle failures gracefully
• Third party APIs may be rate limited or intermittent

Clarifying who watches these jobs, and who responds when they start to queue or fail, is crucial.

Where Payment Gateways and PCI Come Into the Picture

What your gateway is responsible for when customers pay

Payment providers typically take responsibility for:

• Processing card transactions securely
• Protecting card data within their systems
• Authorising or declining payments according to card schemes
• Maintaining their own uptime and security controls

They will publish their own status pages and SLAs, which are separate from your hosting agreement.

Hosted fields, redirects and API payments: who owns which part of checkout?

Payment integrations come in different models:

• Redirect / hosted payment page: your site sends customers to the gateway’s page to pay. The gateway owns the payment page uptime and security, you own everything before and after the redirect.
• Hosted fields / drop-in card forms: card fields are hosted by the gateway inside your page. You own the page and JavaScript around them, the gateway owns the secure fields and tokenisation.
• Direct API payments: your server calls the gateway’s API behind the scenes. You own the integration code, error handling and retry logic, the gateway owns the API behaviour and availability.

This split matters during incidents. If API calls are timing out, both your developers and the gateway need to investigate their parts of the path.

PCI DSS, “PCI conscious” hosting and shared responsibility for card data

The PCI DSS standard sets requirements for handling cardholder data. Even if you never store full card numbers, you still have obligations as a merchant.

PCI conscious hosting supports this by:

• Providing a hardened environment for your application
• Supporting network segmentation, logging and access control
• Offering documentation to help with your own PCI validation

Responsibility remains shared:

• The gateway secures its systems and card data flows
• The host secures the infrastructure and agreed services
• You secure your application, user access and operational processes

Our article Hosting for Card Payments: What ‘PCI Conscious’ Really Means and How Responsibilities Are Shared covers this in depth.

Outages that look like hosting or plugin faults but are gateway problems

Payment issues are often misdiagnosed as hosting problems. Common patterns include:

• Customers seeing generic checkout errors when the gateway has an API incident
• Intermittent payment failures due to rate limiting on the gateway side
• Declines increasing sharply because of a gateway configuration change

In these cases the host may see servers and databases working normally. Alerting that includes gateway status checks can help you pinpoint the real cause faster.

Reading SLAs, Uptime Guarantees and Support Contracts Without Wishful Thinking

Key SLA terms that define who owns which outage

When you read SLAs, focus on:

• Scope of service: exactly what systems or layers are covered
• Definitions of downtime: which failures count towards uptime calculations
• Exclusions: planned maintenance, external network issues, customer-caused incidents
• Response and resolution times: how quickly the provider will engage and under which priority levels

Compare this across your host, your platform provider (if you use a SaaS) and your gateway. Gaps between them are where responsibility confusion tends to appear.

How credits work and why they do not fix lost sales

Most SLAs offer service credits as compensation for qualifying downtime. These usually:

• Reduce future bills rather than refunding past revenue
• Apply only when downtime exceeds a threshold and you log a ticket correctly
• Are capped at a percentage of your monthly fee

They are useful as a sign of accountability, but they rarely cover the cost of a major incident on a busy trading day. This is one reason why prevention and clear responsibility mapping are so important.

Questions to ask your host, platform and gateway before you sign

Useful questions include:

• What exactly does your uptime guarantee measure?
• What is excluded from your SLA?
• How do you notify customers of incidents and maintenance?
• What monitoring do you run, and what do you expect us to monitor?
• How do you handle security incidents and data breaches?

A Simple Responsibility Map: Who Does What Before, During and After an Incident

Prevent: design, monitoring and capacity planning responsibilities

Prevention tasks should be shared explicitly:

• Host: infrastructure resilience, base monitoring, capacity options and advice
• Developers / platform team: efficient code, safe deployment processes, application logging
• Payment gateway: robust APIs, clear status communications, failover within their region
• Your business: planning for seasonal peaks, agreeing maintenance windows, budgeting for appropriate capacity

Detect: who should be watching what (and with which tools)

Detection should not rely on customers telling you there is a problem. You might use:

• External uptime checks that load key pages and run test transactions
• Application logs and metrics to catch errors and slowdowns
• Gateway status pages and webhooks for payment incidents

Clarify:

• What your host monitors and how you are alerted
• What your own tools monitor, including checkout flows
• Who receives alerts out of hours and how decisions are escalated

Respond: first steps when “the site is down”

When an incident happens, a simple triage checklist helps avoid finger pointing:

1. Check public status pages for your host and gateway.
2. Confirm whether the problem affects all users or only some regions or devices.
3. Test a very simple page (for example, a plain HTML health page) to separate hosting from application issues.
4. Check recent changes: deployments, plugin updates, configuration edits.
5. Raise tickets with clear evidence (timestamps, error messages, affected paths).

Your host should take the lead on infrastructure side investigation, while your developers own code rollbacks and configuration changes. Gateway issues need to be reported with example transaction IDs and error codes where possible.

Recover: backups, failover and business continuity

Recovery is about getting back to a stable state, and planning for rare but serious events.

• Backups: who runs them, how often, where they are stored, and who has tested restores recently
• Redundancy: multiple servers, availability zones or data centres where appropriate
• Failover plans: whether you can switch to a reduced feature mode or alternative gateway during major incidents

Our article Backups vs Redundancy: What Actually Protects Your Website explains the difference in more detail.

High availability setups can reduce downtime but bring extra complexity and cost. High Availability Explained for Small and Mid Sized Businesses is a helpful next read if you are considering this.

Common Misunderstandings About Outages and Shared Responsibility

“It must be the host” and other default assumptions

When something goes wrong, it is natural to focus on the hosting first. In practice:

• Many “down” incidents are caused by application errors or DNS misconfigurations
• Payment failures are often gateway side or integration related
• Performance issues are frequently shared between hosting and application design

Starting with a simple layered mindset helps. Ask: “Is the server reachable? Is the application working? Are third party services responding?”

Backups vs redundancy vs high availability

These terms are often used interchangeably, but they describe different things:

• Backups: copies of data you can restore later. Good for recovery from corruption or deletion, not for instant failover.
• Redundancy: multiple instances of something, for example two web servers behind a load balancer.
• High availability: a combination of redundancy, monitoring and automated failover aimed at minimising downtime.

Responsibility for each part is shared between host and customer. The host provides the building blocks, you decide how to use them in your architecture and how much you are willing to invest.

Why multi vendor setups are safer only if roles are clear

Using different providers for hosting, DNS, CDN, email and payments can reduce the impact of any one supplier’s outage. It can also make incidents harder to manage if roles are unclear.

To keep multi vendor setups effective:

• Document who owns which part of your stack
• Ensure every provider knows who to contact in your team for incidents
• Keep a simple diagram and responsibility table that non-technical staff can understand

Practical Steps: How to Clarify Responsibilities in Your Own Stack

Create a simple RACI style table for your website and checkout

A RACI matrix (Responsible, Accountable, Consulted, Informed) does not need to be complex. For each key area, list:

• Infrastructure availability
• Application code and configuration
• DNS and domain management
• Checkout flow and payment integration
• Backups and recovery tests
• Monitoring and alerting

Then assign roles across:

• Your business
• Your hosting provider
• Your development agency or in house developers
• Your payment gateway

What to document with your host, your developers and your gateway

At a minimum, agree and record:

• Primary and backup contact routes for incidents
• Who can make urgent changes (DNS, firewall rules, rollbacks)
• Standard operating procedures for common issues, such as plugin rollbacks or switching gateways temporarily
• Log and metric locations, and who can interpret them

When it is time to move from basic shared hosting to managed or enterprise setups

Signs that you may have outgrown basic shared hosting include:

• Regular performance issues during marketing campaigns or seasonal peaks
• Growing internal time spent on patching, tuning and incident management
• Increased reliance on card payments and third party APIs, with higher financial or reputational risk

At that point, moving to managed environments or Virtual dedicated servers can reduce operational risk and give you more predictable performance and support. The aim is not to add complexity for its own sake, but to align your hosting architecture with the scale and importance of your online business.

Checklist: Questions To Ask So You Know Who Owns the Next Outage

Hosting and infrastructure questions

• What does your uptime guarantee actually measure, and how is downtime defined?
• Which parts of the stack do you monitor, and how do you alert us?
• Who is responsible for OS and middleware patching on our servers?
• How are backups handled, and who is responsible for testing restores?
• What options exist for redundancy or high availability if our risk profile changes?

Platform and development questions

• Who approves and applies plugin, theme and core updates?
• How do we test changes before they go live?
• Where are logs and performance metrics stored, and who reviews them?
• Who owns resolving code level performance issues and database tuning?
• How quickly can we roll back a deployment if it causes problems?

Payment gateway and PCI questions

• What integration model are we using (redirect, hosted fields, direct API), and what does that mean for our responsibilities?
• Where can we see your status and incident history?
• How do you notify us of issues that may affect our checkout?
• What support do you provide for PCI DSS compliance, and what remains our responsibility?
• Do you support failover or multiple processing routes if one region or endpoint has problems?

If you would like help mapping responsibilities across your own stack, or want to explore managed hosting and virtual dedicated servers to reduce operational risk, you are welcome to talk to G7Cloud about the options that fit your business rather than the other way round.