What belongs in a website maintenance agreement

A website maintenance agreement should identify the systems covered, the hours someone is available, and what starts and stops each service clock. “Fast support” is not measurable. A response commitment is also different from a promise to restore service. This is an operational checklist for comparing proposals, not contract or legal advice.

Name the service boundary and the access required

List domains, environments, CMS components, hosting accounts, integrations, and monitoring locations. Specify which organization controls each account. A provider cannot independently restore a system when nobody has authorized access to its infrastructure or backups.

Separate routine maintenance, incident response, and requested improvements. State whether updates, restore tests, content edits, and dependency reviews are included, scheduled separately, or charged against a time allowance. Define how additional work is estimated and approved before it begins.

Document external dependencies such as payment providers and email services. The maintenance team may diagnose or escalate their failure without being able to repair them. That boundary should be visible before an outage, along with the customer contact authorized to approve temporary alternatives.

Define severity and clocks in plain language

Use business impact rather than who submitted the ticket. A possible severity model is:

Situation	Operational treatment
Site unavailable or critical task blocked without workaround	Incident escalation
Important function degraded with a workable alternative	Prioritized support
Cosmetic defect or planned content request	Scheduled queue

This is a proposed classification, not an industry standard. Agree on what counts as a critical task for your site. A broken donation form may matter more than an unavailable archive filter.

Define acknowledgement, active investigation, mitigation, and restoration separately. Say whether time is measured continuously or only during covered hours. For teams in Costa Rica and the US, use an explicit time zone and holiday calendar; “business hours” alone leaves too much unresolved.

A hypothetical response promise at the edge of coverage

Suppose a proposal offers a one-covered-hour acknowledgement during weekday support. A critical form fails on Friday evening after coverage ends. These are hypothetical terms. Without separately purchased on-call coverage, the response clock may not start until the next covered period.

That arrangement can be reasonable for some sites. It is unsuitable if weekend transactions are central to the business. Ask the provider to walk through the scenario, including who receives the alert, who can mitigate the issue, and when the business gets its next update.

Do not interpret acknowledgement as restoration. The first can confirm receipt; the second requires usable service. If restoration has a target, identify dependencies and the evidence used to measure completion.

Require operating evidence and a clean handover

Ask for an incident record, update history, restore-test results, and a list of unresolved risks. AWS runbook guidance recommends documented procedures with tools, permissions, and error handling. The useful deliverable is a procedure another authorized person can follow, not merely a monthly activity total.

Include an operational handover checklist covering account ownership, backup access, configuration records, and open tickets. Avoid storing secrets directly in reports.

Before choosing a plan, send each provider the same after-hours failure scenario and compare their written answers. The support and maintenance service at 5e Labs is a place to discuss those operating requirements against the actual systems you need covered.