What should a website maintenance retainer include?

Start with the systems covered by the agreement

List the website, application, hosting environment and integrations that the provider is expected to support. Include important boundaries. A website maintainer may not administer company laptops, an email tenant or a payment provider account unless the agreement says so.

For an existing site, arrange an onboarding review. The review should find access gaps, unsupported components and unreliable backups before routine maintenance begins. Without it, a retainer cannot honestly promise to cover every unknown issue.

Distinguish maintenance, incidents and new development

Maintenance keeps the agreed system operating through planned changes and checks. An incident is an interruption or failure requiring investigation. A new feature changes what the system does. All three can involve development, but they should not share one undefined "unlimited support" label.

Ask how capacity is allocated, whether unused time carries forward and when a request needs separate estimation. Clear answers help the business plan its requests and help the provider explain why a redesign is not the same task as updating a plugin.

Agree a change and verification process

Updates need an approach suited to the application. A staging environment, recovery copy or planned maintenance window may be appropriate depending on what could be affected. Record the important journeys that should be checked after a change.

The WordPress hardening handbook treats security as an ongoing process, and keeping software updated is part of its guidance. Updates alone are not enough. The maintenance plan should also say who is responsible for access, recovery and day-to-day operation.

WordPress guidance on hardening and maintenance.

Define communication and response targets

Identify the request channel, working hours and information needed to investigate an issue. A report should explain what the user was doing, what happened and when it began. Screenshots or affected URLs can help, but send secrets and sensitive customer records through an agreed secure channel.

A response target describes when the provider acknowledges or begins handling a request. It does not guarantee a fix within the same period. Third-party outages, missing access and an unknown root cause can all affect resolution. Write emergency arrangements into the agreement.

Make recovery an operating responsibility

Ask who checks backup jobs, who can restore the site and whether a restore has been tested. Clarify whether the plan includes the hosting provider's backup or only assumes it exists. The test is whether the business can recover the data it needs in a way it can accept.

Decide how the provider will obtain authorization for consequential changes during an incident. If a restore overwrites recent records, someone must understand and accept that effect. Agree this in advance, before an outage starts.

Expect a useful record of the work

A maintenance report should distinguish completed work, unresolved issues and recommendations. It does not need to be long, but it should help the business understand what changed and what still needs a decision. Include responsibility for third-party dependencies.

We scope Wasevo support plans around your actual systems and working arrangements. The plan states how requests work and who owns what. It does not promise that every future problem is included.