A store does not need to disappear completely to be “down.”
The homepage can load while checkout returns an error. Search can stop working while product pages remain available. A payment integration can fail for one market or payment method. An API can become slow enough that customers abandon the process before it technically times out.
For an eCommerce business, availability is therefore not only a question of whether the server responds. The more useful question is whether customers can still complete the actions that generate revenue.
That changes how we think about both downtime cost and website maintenance.
Proactive maintenance does not promise that nothing will ever break. Its value is more practical: reduce avoidable failures, detect problems sooner, limit how much of the site they affect, and shorten the time needed to recover.
Downtime is not always a blank screen
A full outage is easy to recognise. Nobody can reach the site.
Partial failures are harder because monitoring may still report that the website is online.
For an eCommerce store, incidents can include:
- Product pages returning server errors
- Search or filtering failing
- Cart requests timing out
- Checkout refusing to load
- A payment method failing
- Stock or pricing APIs becoming unavailable
- Login or account functionality breaking
- Pages becoming unusually slow under load
- Admin or order-processing systems becoming inaccessible
A simple homepage uptime check will not necessarily detect all of those problems.
This is why we prefer to monitor critical user journeys, not only the domain itself.
For an online store, that usually means at least product pages, search or category navigation, cart, checkout, and the services those steps depend on.
Where the cost of an incident actually comes from
The easiest downtime calculation is:
average hourly revenue × hours offline
That is useful as a rough starting point, but it has two weaknesses.
First, revenue is rarely distributed evenly throughout the day. An outage during a campaign launch can affect much more business than the same outage early in the morning.
Second, many incidents affect only part of the purchase journey.
If checkout is unavailable, almost all new purchases may be at risk. If one secondary filter stops working, the financial effect is likely to be much smaller.
A better estimate starts with what the incident actually affected.
1. Sales that could not be completed
Look at the normal order value or revenue generated by the affected part of the site during the same type of period.
For example, if checkout is unavailable during a period that normally produces €500 in hourly sales, that gives you a starting estimate of revenue at risk.
But revenue and financial loss are not necessarily the same number.
If you want a closer estimate of actual business cost, use contribution margin rather than revenue where that data is available. Revenue includes product costs and other expenses the business may not incur on an order that never happens.
2. Paid traffic sent into the incident
If Google Ads, Meta Ads, affiliates, or another paid channel continues sending visitors while the affected purchase path is broken, some acquisition spend may generate visits that cannot convert normally.
This is especially relevant when the failure happens after the landing page.
An ad platform may continue seeing a valid destination because the product page loads, while the customer discovers later that the cart or checkout does not work.
Compare paid sessions and spend during the incident with the part of the funnel that was unavailable. Do not automatically classify all advertising spend during an incident as wasted.
3. Support and customer recovery
Incidents can create work outside the development team.
That may include:
- Customer support conversations
- Manual order checks
- Payment investigations
- Refund processing
- Customer compensation
- Communicating status internally or publicly
These are incremental costs created by the incident and can be included when estimating its impact.
4. Engineering and incident-response time
An outage often pulls people away from planned work.
Developers may need to investigate logs, roll back a release, contact an infrastructure provider, restore data, test payments, or verify that the system is stable again.
The cost is not only the hours spent repairing the incident. It is also the planned work those hours displaced.
5. Effects that are real but harder to price
Some consequences should be tracked without pretending we know their exact euro value.
A first-time customer who encounters a failed checkout may decide not to return. A returning customer may contact support instead of placing an order. A campaign may generate fewer completed purchases because the store was unstable during part of its run.
Those effects can matter, but we would not insert an arbitrary “customer trust cost” into an ROI calculation unless the business has data to support it.
The same principle applies throughout the analysis: measure what you can and label the rest as risk rather than invented revenue loss.
A more useful downtime cost calculation
For a practical incident review, we use a model closer to this:
Estimated incident cost = lost contribution margin + acquisition spend affected + incremental support/compensation + incident and recovery labour + direct recovery costs
If contribution margin is unavailable, at-risk revenue can be used as a simpler commercial estimate, as long as it is labelled as revenue rather than net loss.
| Input | What to use |
|---|---|
| Sales affected | Normal revenue or contribution margin for the affected journey during a comparable period |
| Percentage affected | Estimate based on which pages, payment methods, markets, devices, or services actually failed |
| Paid acquisition affected | Spend that continued sending customers into the affected journey during the incident |
| Support and compensation | Additional support time, refunds, credits, discounts, or other recovery measures caused by the incident |
| Incident labour | Engineering, operations, management, and other staff time needed to investigate and recover |
| Direct recovery cost | Emergency vendor fees, temporary infrastructure, external specialists, or other incident-specific expenses |
An illustrative example
Suppose an eCommerce store normally generates €500 per hour during a campaign.
Checkout is unavailable for one hour. Paid campaigns spend €120 during that period. The incident requires €150 worth of engineering and operations time, and the business spends another €30 handling affected customers.
Using revenue as the simplified sales measure:
Estimated commercial exposure = €500 + €120 + €150 + €30 = €800
That does not mean the business definitely lost exactly €800. Some customers may return later, and gross revenue is not the same as profit.
It gives the team a consistent way to compare the cost of incidents with the cost of preventing and responding to them.
What downtime actually means for SEO
Short outages do not automatically destroy search rankings.
Google expects temporary server problems to happen.
When Googlebot receives server errors such as HTTP 5xx responses, Google reduces crawling temporarily. Already indexed URLs are initially preserved. If server errors continue, crawling can decrease further and persistently unavailable URLs can eventually drop from the index.
The duration and frequency therefore matter.
A short maintenance window handled correctly is very different from a site that repeatedly times out or remains unavailable for days.
If a planned outage is necessary, returning the correct HTTP response also matters. A temporary 503 Service Unavailable response tells crawlers that the interruption is temporary.
For an eCommerce business that relies heavily on organic traffic, this gives maintenance another job: keep server failures from becoming persistent enough to interfere with crawling and indexing.
Maintenance ROI starts with fewer and shorter incidents
Proactive maintenance is sometimes sold as a promise that the website will never fail.
That is not realistic.
Software changes. External APIs fail. Infrastructure has limits. Payment providers experience incidents. Human mistakes happen.
A more useful maintenance programme improves four things:
- Prevention: reduce failures that can be avoided
- Detection: find a problem before customers or support tickets do
- Recovery: restore the affected service quickly
- Containment: prevent one problem from taking down unrelated parts of the system
Those outcomes can be measured.
Measure incident frequency
Track how often customer-impacting incidents occur and what caused them.
If the same type of failure appears repeatedly, fixing the underlying cause is more valuable than repeatedly restoring service.
Measure detection time
How long does a problem exist before somebody knows about it?
If checkout fails at 02:00 but nobody notices until the first support ticket at 08:00, the response process has a monitoring problem as well as a technical problem.
Measure recovery time
Once an incident is known, how long does it take to restore normal service?
Documented recovery steps, access to logs, known escalation contacts, tested backups, and rollback procedures can all affect that number.
Measure the affected journey
“The website had an incident” is too broad for a useful report.
Record what actually stopped working:
- Was the entire storefront affected?
- Only checkout?
- One payment method?
- One market?
- Only logged-in users?
- Admin operations but not customers?
This makes future cost estimates and prioritisation much more accurate.
Backups only help if recovery has been tested
“We have backups” is not the same as “we can recover.”
A useful backup strategy needs answers to two separate questions:
How much data can we afford to lose?
This is usually expressed as a Recovery Point Objective (RPO). If orders are backed up every 24 hours, a failure just before the next backup could theoretically expose almost a full day of changes.
How long can recovery take?
This is the Recovery Time Objective (RTO).
The correct values depend on the business. A high-volume store processing orders continuously may need very different recovery requirements from a small content website.
Most importantly, restoration should be tested.
A backup that exists but cannot be restored, takes much longer than expected, or is missing a critical database is not the recovery plan you thought you had.
99.9% uptime sounds good. What does it actually mean?
Uptime percentages are useful, but the difference between them becomes easier to understand when converted into time.
In a 30-day month:
| Availability | Maximum downtime to remain within that target |
|---|---|
| 99% | About 7 hours 12 minutes |
| 99.9% | About 43 minutes |
| 99.99% | About 4 minutes 19 seconds |
That does not mean every eCommerce business should automatically demand 99.99% availability.
Higher availability usually requires more redundancy, monitoring, infrastructure, operational work, and cost.
The target should match the business impact of failure.
We would rather define a realistic service objective around important customer journeys than advertise a meaningless uptime percentage while checkout failures go unnoticed.
What proactive maintenance should actually include
A maintenance agreement is only useful if the deliverables are clear.
For an eCommerce site, we would expect the scope to address areas such as:
Monitoring and alerting
- Storefront availability
- Important product or category pages
- Cart and checkout availability
- Critical APIs and integrations
- Server resource utilisation where applicable
- Error rates and application logs
- Performance degradation
- Alerts that reach someone who is responsible for responding
Backups and recovery
- Defined backup frequency and retention
- Database and file coverage
- Documented RPO and RTO where appropriate
- Periodic restore testing
- Clear recovery responsibilities
Safe releases and updates
- Staging or another appropriate pre-production environment
- Testing before important changes reach production
- Rollback procedures
- Change history
- Post-release checks on important customer journeys
Security maintenance
- Supported software versions
- Security patches
- Vulnerability monitoring where appropriate
- Access and permission reviews
- Removal of unused accounts, integrations, and dependencies
Incident response
- Severity definitions
- Who receives alerts
- Who owns the response
- Escalation contacts
- Communication responsibilities
- Recovery procedures
- Post-incident review for meaningful failures
A maintenance plan does not need every item above in every project. A small store and a high-volume international eCommerce platform have different risk profiles.
The important part is knowing what is covered rather than buying a vague promise to “keep everything updated.”
A maintenance report should show what changed
One problem with preventive work is that success can be invisible.
If an update is tested before release and a checkout regression never reaches production, there is no dramatic outage to point at afterwards.
Reporting therefore matters.
Instead of saying “maintenance completed,” a useful report can show:
| Area | What to report |
|---|---|
| Availability | Customer-impacting incidents, affected services, duration, and recurring causes |
| Detection | Which incidents monitoring detected and how quickly |
| Recovery | Recovery time, rollback or restore actions, and whether documented procedures worked |
| Backups | Backup status and results of restore tests |
| Updates | Changes tested and released, including issues caught before production |
| Security | Relevant patches, vulnerabilities, access changes, and unresolved risks |
| Performance | Meaningful changes in response time, error rates, or critical page performance |
| Next actions | Specific risks that need development, infrastructure, or business decisions |
That makes maintenance much easier to evaluate than a list of tasks completed every month.
How this applies to ReadyCMS stores
For stores built with ReadyCMS, we apply the same principle: monitor the parts of the system customers and teams actually depend on rather than treating the application as one binary “up/down” service.
A maintenance setup around a ReadyCMS implementation can therefore include checks for:
- Storefront availability
- Important category and product pages
- Cart and checkout flows
- API availability
- Third-party payment, courier, feed, and other integrations relevant to the project
- Performance after releases
- Backup and recovery procedures
- Production changes across environments
The exact setup should reflect the implementation. A store with several markets, payment providers, integrations, and custom frontend services needs different monitoring from a smaller store with a simpler architecture.
That is also why maintenance starts with understanding the system rather than applying the same checklist to every website.
Make the quiet months count
The easiest month to question a maintenance budget is one where nothing went wrong.
But “nothing went wrong” is not enough to prove that maintenance worked, just as one outage does not prove that maintenance failed.
The useful evidence is in the operating data:
- Are recurring incidents disappearing?
- Are problems detected earlier?
- Is recovery getting faster?
- Have restore procedures been tested?
- Are risky changes being caught before production?
- Do important customer journeys remain available when traffic rises?
That is the ROI case for proactive maintenance.
Not fear of the next outage. A system that is easier to monitor, safer to change, and faster to recover when something eventually does fail.
Not sure how prepared your current setup is?
Creative Brackets can review monitoring, backups, recovery procedures, infrastructure, performance, and the critical customer journeys behind your eCommerce site.
Request a maintenance and uptime audit.
FAQ
1. How should I calculate server downtime cost?
Start with the revenue or contribution margin normally generated by the part of the store that was affected. Add paid acquisition spend that continued sending traffic into the failed journey, incident-response labour, support or compensation costs, and any direct recovery expenses. For a partial outage, do not assume 100% of store revenue was lost.
2. What uptime target should an eCommerce site have?
There is no universal target that fits every store. A 99.9% monthly availability target allows about 43 minutes of downtime in a 30-day month, while 99.99% allows roughly four minutes. Higher availability generally requires additional redundancy and operational investment, so the target should reflect how much downtime the business can tolerate and which services are critical.
3. Will a short outage damage SEO?
Not necessarily. Google can handle temporary server failures. Server errors cause Googlebot to reduce crawling, and short interruptions are different from persistent availability problems. If server errors continue, affected URLs can eventually be removed from the index. Planned temporary downtime should therefore use appropriate HTTP responses such as 503 where applicable.
4. Is proactive maintenance worth it if the site rarely goes offline?
Total outages are only one thing maintenance addresses. Monitoring can detect checkout failures, API errors, performance degradation, broken releases, backup problems, and security issues before they become larger incidents. Whether the investment is justified depends on the commercial impact of those risks and the cost of operating the maintenance programme.
5. Is having backups enough?
No. Backups need to cover the data required for recovery, and restoration should be tested periodically. A business should also know how much data it can tolerate losing and how quickly important services need to be restored.
6. What should a maintenance report contain?
At minimum, it should explain customer-impacting incidents, monitoring findings, backup and restore status, significant updates, unresolved risks, performance changes, and the next actions that require attention. The report should show changes in system health rather than simply list tasks that were completed.
7. How quickly should support respond to an outage?
The response target should be defined by incident severity and business impact. A checkout outage during peak trading should have a different escalation path from a minor admin-interface issue. Clear severity definitions, ownership, escalation contacts, and response expectations are more useful than a vague promise of “fast support.”
