Web hosting and maintenance: availability, security, costs and operating contract

A site may be delivered on a Friday and begin to degrade on Monday. Certificates, dependencies, content, backups, forms and third-party services evolve without waiting for the next redesign project.

1. The useful answer: hosting is not exploiting

Theweb hosting provides the resources that make the service accessible: calculation, storage, network, database, distribution, certificates and sometimes managed services. The maintenance maintains the service in an acceptable state: updates, supervision, backup, correction, assistance, capacity, security and controlled evolution.

So paying for a server doesn't mean someone is monitoring forms, restoring data, testing extensions, renewing domains, or responding to a vulnerability. A healthy contract transforms these verbs into responsibilities, deadlines, proofs and limits.

The objective is not the absolute absence of incidents. It is an operation capable of preventing predictable failures, detecting others, restoring service and learning without making each incident heroic.

2. Key figures: each promise of availability has a cost

Eurostat measures the purchase of services, not their quality. Google provides mathematical conversion of targets, not the availability of a particular provider. HTTP Archive is watching millions of pages, not your stack. Their purpose is to make promises testable.

3. The operating contract: twelve clauses that really change the service

3.1. Scope of assets

The contract must inventory domains, DNS, certificates, hosting, databases, storage, CDN, CMS, repositories, environments, accounts, forms, analytics tools, integrations and third-party services. For each: legal owner, administrator, billing, region, criticality and exit procedure.

The most costly incidents often arise outside the main server: domain renewed on an expired card, API key belonging to a former employee, form sent to a deleted mailbox or abandoned plugin.

Proof: asset register revised quarterly and exportable by the client.

3.2. Shared responsibilities

A cloud provider secures part of the infrastructure. The customer and his service provider remain responsible for configurations, identities, application, data, content and uses depending on the service purchased.

Write a RACI without “everyone” boxes. Who approves administrator access? Who applies a critical patch? Who confirms the restoration? Who contacts users? An unnamed responsibility turns into a discussion during the incident.

Proof: signed matrix, main and replacement contacts, tested crisis scenario.

3.3. SLO, SLA and error budget

The SLA is a contractual commitment; the SLO is an operational target; the indicator measures experience. They are not interchangeable. A provider may meet its overall SLA while a critical journey fails due to an integration.

Define availability based on real actions: searchable page, respondent search, form accepted, payment authorized. The Google SRE Book proposes the error budget — 1 minus the SLO — as an arbitrage mechanism between change and reliability.

Proof: indicators per journey, calculation windows, limited exclusions and review of the error budget.

3.4. Monitoring and alerts

Monitoring must combine external availability, system metrics, application errors, logs, field performance and synthetic tests. A successful ping does not prove that a user can submit the form.

Each alert must have an owner, threshold, severity and action. A box containing a thousand ignored alerts is a setting. Remove or fix what doesn't trigger a decision.

Proof: shared dashboard, alert test, incident history and associated runbooks.

3.5. Backup and Restore

A backup is a guess until restored. Define RPO — amount of data that we accept to lose — and RTO — target time to restore the service. Adapt frequency, retention, immutability and separate copies to these goals.

Also back up configurations, media, CMS data, secrets using a suitable procedure, DNS, CDN rules and documentation. Data locked in a SaaS deserves a separate export if its loss blocks activity.

Proof: periodic restoration in an isolated environment, timed result and corrected deviations.

3.6. Updates and vulnerabilities

Classify components: system, runtime, framework, libraries, plugins, themes, container images and third-party services. Set a normal window and a fast track for a critical exploited or exposed vulnerability.

The fix doesn't stop at the "update" button. You have to analyze the exposure, test, save, gradually deploy, monitor and be able to come back. The NIST SSDF explicitly places addressing vulnerabilities within secure development.

Proof: version inventory, scans, related tickets, remediation time and approved exception.

3.7. Changes and backtracking

Any significant change receives a description, an owner, criteria, review, testing and a rollback strategy. Separate environments and rights. Protect the production branch and keep track of what has been released.

The goal is not heavy bureaucracy. Small, automated, observable changes reduce the surface area for failure. The measurements DORA track deployment frequency, delay, failures and recovery times, instead of valuing ticket volume.

Proof: deployment log, automated testing, validation and rollback exercise.

3.8. Performance and capacity

Set budgets: weight, JavaScript, images, third-party requests, LCP, INP, CLS and backend response times. Measure at the 75e percentile and segment mobile, device, country and page type.

Capacity includes normal traffic, campaign, import, bot, seasonal peak and third-party service failure. Providing a limitation mechanism or a queue is often better than oversizing all year round.

Proof: field data, proportionate load tests, alert thresholds and pre-campaign review.

3.9. Security, access and secrets

Enforce MFA on sensitive accounts, least privilege, named accounts, rotation and withdrawal rapide. Keys should not live in code or a shared document. Log administrative actions and review rights.

Site security also includes WAF/CDN, headers, dependencies, forms, API, storage, emails and publisher account protection. It is never “included” without a checklist.

Proof: quarterly access review, secrets register, tests and response plan.

3.10. Support and severity

Define four understandable levels: service unavailable or data at risk; critical function degraded; circumventable anomaly; request for development. For each: channel, coverage hours, response time, communication frequency and restoration target.

Don't promise "response in one hour" if that response could be an accused without a diagnosis. Separate consideration, qualification, workaround, correction and closure.

Proof: time-stamped tickets, compliance with stages and analysis of reopenings.

3.11. Incidents and learning

The runbook specifies command, diagnosis, communication, evidence preservation, decisions and restoration. After a significant incident, write a no-blame analysis: timeline, impact, detection, contributing factors and actions with owners.

“Human error” is not a sufficient cause. Ask why an action was possible, invisible or irreversible.

Proof: report, actions followed until verification and annual exercise.

3.12. Reversibility and end of service

Customer must recover data, code, media, configurations, domains, useful logs and documentation in a usable format. The contract specifies deadline, cost, assistance, deletion and confirmation.

Test an export before you need it. The best-written reversibility clause does not correct an unusable proprietary format or a root account held by the provider.

Proof: annual output packet or at each major change, restored to a test environment.

4. Compare four hosting models

The best model minimizes the total cost of the necessary level of service. Keeping all the servers is no more sovereign if no one knows how to restore them; outsourcing is not simpler if responsibilities remain opaque.

5. Cloud and recovery: anatomy of an ordinary incident

At 9 h 12, support reports that some requests are no longer arriving in the CRM. The site responds. The form displays a confirmation. Infrastructure monitoring remains green. However, the business service has been failing since the evening before.

Server-centric monitoring misses the mark because the failure occurs after form acceptance, in a queue whose messages are discarded by a remote API after a secret silently expires. Path monitoring would have counted confirmations, messages processed and records actually created, then alerted on their discrepancy before the salesperson discovered the problem.

The team must first preserve requests, prevent duplicates, renew secrecy through the intended channel, and replay only unconfirmed events; if the idempotency identifiers, correlation logs and retention queue have been designed together, the restoration consists of a controlled operation rather than a manual export followed by several days of reconciliation.

The post-incident should therefore not conclude “the token was expired”. It examines why the renewal was not owned, why the synthetic test stopped before the CRM, why the rejection alert was not routed and why no table reconciled site inputs and integration outputs.

This scene gives four additional contract requirements. First, monitor end-to-end transactions. Then retain enough data to replay without duplicating. Then, test the secrets and certificates before they expire. Finally, measure the recovery from the business point of view, not from the restartrage of a component.

The lesson is simple. The server may be fine. The service, no.

A mature cloud contract therefore designates the owner of each dependency, documents the degraded mode, protects pending data and specifies who authorizes a replay when the operation risks creating duplicate orders, payments or messages.

The monthly report should make this work visible: service objectives, incidents and near-misses, changes, tested restores, open vulnerabilities, capacity, variable costs and expected decisions. A series of green lights without any connection with the transactions does not constitute management.

Finally add future deadlines – domains, certificates, licenses, end of support and supplier contracts – over a twelve-month horizon. Serious maintenance treats the schedule as a predictable and measurable source of risk.

6. Budget: calculate the total annual cost

Use this formula:

Platform + traffic/storage + licenses + preventive maintenance + incident support + security + backups + improvement + governance.

Very low offers often cover only platform and some automatic updates. Ask for included volume, schedules, exceptions, account ownership, out-of-package rate and services billed during an incident.

The level of service strongly shifts the cost. An on-call 24/7, a target 99,99 %, a restoration of a few minutes and several regions require a different organization from a showcase site tolerating intervention the following working day. Buy the availability that the profession knows how to value.

7. Logiks advice: five tests before signing

1. Ask the provider to restore a backup, not show that it exists.
2. Drop a third-party service into recipe and observe the degraded mode.
3. Check who controls domain, DNS, repository, cloud account and billing.
4. Select a fictitious incident and follow the escalation chain to the business decision maker.
5. Have the full output encrypted and request an export example.

8. 90 day control plan

8.1. Days 1 to 30 — Inventory and criticality

• identify assets, accounts, suppliers and owners;
• map critical pathways and dependencies;
• measure current availability, errors and performance;
• define RPO, RTO and support hours;
• correct orphan access and risky renewals.

8.2. Days 31 to 60 — Operating capacities

• install supervision and actionable alerts;
• document backup, restoration, deployment and incident;
• test patch, rollback and export;
• define SLO and error budget;
• prioritize vulnerabilities and maintenance debt.

8.3. Days 61 to 90 — Contract and exercises

• align contract, RACI, severities and indicators;
• perform an incident drill;
• restore data in an isolated environment;
• share the dashboard with the business owner;
• plan monthly reviews and annual exit test.

9. FAQ

9.1. What is the difference between hosting and maintenance?

Hosting provides the infrastructure. Maintenance work maintains application, dependencies, data, security, performance and operation. An offer can combine the two, but its scope must distinguish them.

9.2. How often should a site be maintained?

Supervision is continuous; reviews and updates follow a pace adapted to the risk. A critical vulnerability may require immediate action, while a minor development waits for a monthly window. Avoid a single schedule for all components.

9.3. Is an SLA of 99,9 % enough?

It theoretically allows 43,2 minutes of unavailability per month. The answer depends on the turnover period, the routes affected and the degraded mode. Define the SLO from the business impact, then verify that the organization can meet it.

9.4. Are the host’s backups enough?

Not always. Check scope, frequency, retention, separation, export and restore. A copy managed in the same account may be affected by a common error or compromise. Test a full restore.

9.5. What should a web maintenance contract contain?

Assets, responsibilities, schedules, severities, deadlines, updates, backups, supervision, security, changes, reports, exclusions, prices, ownership and reversibility. Verbs must be associated with evidence.

9.6. Should you stay with the same service provider as the one who created the site?

This can be effective if the documentation, accounts and contract are sound. This is not an obligation. The ability to transfer without losing domains, data or understanding is precisely a construction quality criterion.

10. Conclusion

Hosting makes the service present. Maintenance keeps it trustworthy. In between is an operating contract: known assets, named responsibilities, proportionate targets, tested restoration and decisions supported by measurements.

The good offer is not the one that promises “no worries”. It is the one that describes what will be monitored, how failure will be managed and how the client will maintain control.

11. Main sources

1. Eurostat — 53% of EU enterprises used paid cloud services in 2025, 3 February 2026.
2. Google SRE — Availability table, accessed on July 13 2026.
3. Google SRE — Production services best practices, accessed on July 13 2026.
4. HTTP Archive — Web Almanac 2025, Page Weight, published in 2026.
5. HTTP Archive — Web Almanac 2025, Performance, published in 2026.
6. NIST—Secure Software Development Framework 1.1, accessed on July 13 2026.
7. DORA — Software delivery performance metrics, accessed on July 13 2026.
8. OWASP — Top 10:2025, accessed on July 13 2026.