When your website goes down: How to specify hosting and operations before signing the agreement
A good maintenance agreement is about more than server space and uptime. It must describe how errors are detected, who responds, and how quickly the website and data can be restored.
Professional web hosting is often evaluated based on price, storage space and a promised uptime percentage. This says little about what actually happens when the website becomes slow, an update fails or data needs to be restored.
The most useful perspective is therefore not “Which server should we buy?”, but “What must the operating setup withstand, and how do we recover after an error?” The answer should guide the choice of operating environment, backup, caching, CDN, monitoring and maintenance.
Start with the consequences of downtime
Two websites with the same number of visitors may have completely different operational needs. A consulting firm may be able to tolerate a short outage outside working hours. For an online store in the middle of a campaign, the same outage could mean lost orders, extra work and weakened trust.
Therefore, assess the consequences before discussing technical solutions:
- What happens if the website is unavailable for 15 minutes, two hours or one working day?
- Could forms, orders or customer enquiries be lost?
- Are there periods when availability is particularly important to the business?
- Which people must be notified in the event of a serious error?
- Is there an alternative channel customers can use?
This provides a better basis for decisions than traffic volume alone. A website with moderate traffic may be business-critical if it handles applications, bookings or qualified enquiries.
Uptime must be translated into practical requirements
An uptime of 99.9 percent sounds almost perfect, but corresponds to approximately 8 hours and 46 minutes of possible downtime over the course of a year. At 99.99 percent, the corresponding time is around 53 minutes. The percentage must therefore be assessed together with the measurement period, exclusions and response time.
Ask the provider to clarify:
- What counts as downtime?
- Is the website measured externally, or only whether the server is running?
- Is planned maintenance excluded?
- Does the commitment apply to the entire solution or only the infrastructure?
- What happens if the database is working, but customers cannot submit the form?
A server can be “up” while the website displays error messages or essential functions have stopped. External monitoring of what the user actually encounters is therefore more important than a green status light at the hosting provider.
Define how quickly you need to be back online
Two terms make it easier to formulate specific requirements: RTO and RPO. RTO describes the maximum length of time the business can accept the service being unavailable. RPO describes how much data it is acceptable to lose, measured as the time since the last recovery point. These targets should be determined based on the business consequences and then used to choose the technical solution.
For a simple business website, it may, for example, be acceptable to restore the service within a few hours and the content from the previous night. For an active online store, losing several hours of order data may be unacceptable. This requires more frequent backups or continuous replication, combined with faster incident response.
Stricter targets normally mean higher costs and greater complexity. It is rarely appropriate to require near-zero downtime and zero data loss if the actual business risk does not justify the investment.
A backup only becomes valuable when it can be restored
“Daily backup” is not a complete description. A professional backup solution must specify what is copied, how often this happens, how long the copies are retained, where they are stored and who has access.
NSM recommends that a backup plan describe, among other things, which data is covered, frequency, responsibility, retention, security and recovery-time requirements. NSM also points to the need for copies that cannot be accessed through the business’s ordinary network.
For a website, the backup should normally include:
- database containing content, users, orders and settings
- uploaded images and documents
- theme, source code and customisations
- configuration for the server, DNS and associated services
- the information necessary to rebuild the environment
The copy should not be stored only on the same server as the production solution. If the server, account or provider environment is affected, both the website and the backup could otherwise become unavailable at the same time.
Ask for documentation of the recovery test
A successful backup job only shows that something was copied. It does not show that the files are complete, that the database can be read or that the solution can be put into operation within the agreed time. Regular restoration to a separate test environment is necessary to verify both the content and the time required. AWS recommends periodic restoration tests to confirm that the backup actually meets the defined RTO and RPO targets.
Caching and CDN must be configured for the solution
Caching reduces the need to generate the same content again for every request. A CDN can also store copies of static resources, such as images, stylesheets and JavaScript, closer to users. This can reduce the load on the origin server and provide faster delivery.
But caching is not a universal checkbox. Logged-in pages, shopping carts, personalised prices, form results and other individual content must be handled differently from a public article. Incorrect cache rules can serve outdated content or, in the worst case, display information to the wrong user.
The operations provider should therefore be able to explain:
- which page types and files are cached
- how logged-in users and dynamic features are excluded
- how the cache is cleared after publishing and updates
- what happens when the CDN or origin server fails
- how cache hits and errors are monitored
A CDN can reduce the load on the server, but it does not replace a stable production environment. Requests that are not cached must still be handled by the origin solution.
Monitor the user experience and the underlying system causes
Good monitoring combines external tests with visibility into the operating environment. Google distinguishes between “black-box” monitoring, which tests the service as users experience it, and “white-box” monitoring, which examines internal metrics, logs and components. The former detects the symptom. The latter helps the operations team find the cause.
For a typical business website, monitoring may include:
- whether important pages respond correctly
- whether forms, search or checkout work
- response times and increases in error rates
- server and database resource usage
- certificate and domain expirations
- errors in backups, automated jobs and integrations
Alerts must be tied to responsibility. An alert without a named recipient and an expected response time is just a message. The agreement should distinguish between critical incidents requiring an immediate response and minor deviations that can be handled the next business day.
Maintenance must be a controlled process
WordPress, plugins, themes, PHP, databases and server components change over time. Delaying all updates increases technical debt and risk. Installing everything directly in production without control can also create compatibility problems.
WordPress recommends keeping plugins up to date and having a current backup before updating. A professional maintenance process should also include risk assessment, testing of major changes, functional checks after deployment and a clear rollback plan.
Clarify who is responsible for:
- ongoing security and maintenance updates
- testing in a separate environment
- fixing errors if an update affects custom-developed functionality
- upgrading PHP, the database and the operating system
- phasing out components that are no longer maintained
Choose an operating environment based on risk and responsibility
Shared hosting may be sufficient for a simple website with limited requirements. Managed hosting is suitable when the business wants a provider to handle more of the monitoring, updates, security and troubleshooting. Dedicated or scalable cloud environments may be appropriate when the solution has high traffic, special integrations or strict requirements for availability and isolation.
What matters is not what the environment is called, but which guarantees and processes come with it. “Cloud,” “premium” and “managed” have little value if responsibility, response times and recovery are not clearly defined.
Seven questions to ask before entering into a hosting agreement
- What is monitored? Ask for both external user tests and internal system measurements.
- Who responds? Clarify responsibility, response times and the escalation path.
- How quickly should the service be restored? Set a realistic RTO based on business needs.
- How much data can be lost? Define the RPO and adjust the backup frequency accordingly.
- When was the backup last tested? Ask for the results of an actual recovery.
- How are updates carried out? Require backups, checks, testing and the option to roll back.
- What is not included? Document the boundary between hosting, application operations, troubleshooting and further development.
A good hosting agreement does not eliminate all risk. It makes the risk understandable and manageable. The business knows what is monitored, how quickly someone responds and how the website will be restored if something goes wrong. That is the practical difference between renting server space and having professional operations.
