Website Maintenance Retainer: Compare SLAs and Ownership

Start with the maintained system, not a monthly hour bundle

List what the provider is actually responsible for: domain and DNS, hosting, CDN, certificates, CMS core, themes, plugins, custom code, database, forms, transactional email, analytics, search tooling, consent controls, third-party integrations and deployment pipeline. For each component, name the owner, access holder, monitoring source and support contact.

Then separate three kinds of work. Operational maintenance keeps an agreed baseline healthy. Incident support restores a service after an unplanned failure. Change requests add or alter capability. A retainer can include all three, but the proposal should show the included allowance, approval path and overage price for each. Otherwise a security update may compete with a new landing page for the same unallocated pool of hours.

Record exclusions at the same level of detail. A provider that maintains WordPress code may not control the hosting network, payment processor or an abandoned plugin. Exclusion does not mean silence: require the provider to diagnose ownership, preserve evidence and coordinate with the responsible party.

Define priority by user and business impact

A priority label should be reproducible. Define severity using affected user journeys, breadth, data or security exposure, workaround availability and time sensitivity. A checkout outage for all buyers may be critical. One editor unable to upload a nonurgent image may be low priority. The executive title of the reporter should not change the classification.

Require examples and counterexamples for every level. State who may declare a critical incident, who can downgrade it and how disagreements are escalated. Security events need their own path because a seemingly available website may still require containment. NIST SP 800-61 Rev. 3 places incident response inside broader cybersecurity risk management and emphasizes preparation, detection, response and recovery rather than treating response as an isolated ticket. [1]

The priority matrix should also define communication frequency and the authority to take protective action, such as disabling a vulnerable feature. Fast updates are useful only when the responsible person knows what has changed, what users experience and what decision is needed.

Separate acknowledgement, restoration and permanent resolution

Response time means the provider has accepted ownership and started triage. It does not mean the website works. Define separate targets for acknowledgement, initial diagnosis, user-impact mitigation, service restoration, permanent resolution and post-incident review. State the support hours, time zone, holiday treatment and whether the clock runs continuously for critical incidents.

Document when a clock can pause. A pause should require a specific dependency, an owner and a timestamp, not the phrase waiting for client. If the provider needs an approval, log access or third-party action, the update should say exactly what is required and what can proceed meanwhile. Keep target performance reports separate from contract remedies.

Google's SRE guidance distinguishes an SLO, a target for service reliability used in operating decisions, from an SLA, a business agreement that may trigger compensation. It also recommends stakeholder-approved objectives and a policy that uses reliability data to prioritize work. [2] A buyer can borrow that discipline without copying a hyperscale model: measure a few user-facing journeys and decide what happens when reliability falls below the agreed target.

Require observable user journeys and actionable alerts

Ask what is monitored, from where, at what frequency and by whom. Availability of the home page is not proof that login, search, checkout, lead submission or transactional email works. Select the journeys that matter, define a successful result and record which alerts wake a person versus enter a business-hours queue.

Google's incident-management guide recommends timely, actionable alerts that cover key user-facing functions and focus on symptoms rather than fragile internal causes. [3] The provider should maintain current on-call contacts and playbooks for repeated failures. An alert without an owner or diagnostic path is only noise.

The buyer should receive evidence it can interpret: incident timestamps, affected journey, measurement source, acknowledged time, restoration time, cause when known, follow-up owner and due date. Require a monthly exception report, not a dashboard screenshot with only green averages. A short severe outage can disappear inside a monthly percentage while still exposing a failed response process.

Turn updates and releases into a controlled change process

A patch commitment needs an inventory, severity assessment, testing path, approval rule and rollback plan. Define how the provider learns about CMS, plugin, library and infrastructure advisories, how it checks whether the affected component is reachable, and what happens when an update is incompatible.

WordPress advises backing up before an update, checking plugin and theme compatibility, and visiting the site afterward to confirm it still works. [4] OWASP likewise recommends analyzing vulnerable dependencies, testing patched versions and treating workarounds as temporary mitigations when a safe upgrade is blocked. [5] A scan alone is not remediation evidence.

For routine releases, require a change record with purpose, files or components changed, test results, approver, deployment time and rollback decision. Set a maintenance window where appropriate, but preserve an emergency path for active exploitation or major user impact. Clarify whether the retainer includes fixing compatibility problems or only installing updates. That distinction changes both risk and price.

Specify recovery objectives and test the restore path

Backup frequency is not a recovery promise. Define the maximum acceptable data loss, the target restoration time, retained versions, storage location, encryption, access owner and components covered. A database backup without uploaded files, configuration, DNS records or external integration settings may not recreate the service.

NIST contingency-planning guidance recommends evaluating systems and operations to determine recovery requirements and priorities. [6] Translate that into the website's critical journeys. A brochure site and a store processing orders may need different recovery points and restoration sequences.

Require scheduled restore tests in an isolated environment. The report should identify the backup used, restoration duration, missing dependencies, validation checks and corrective actions. Confirm who may authorize production restoration and how orders or form submissions created after the recovered point are reconciled. The buyer should own or have independent access to the backup location, not discover during an exit that every recovery copy sits inside the provider's account.

Protect performance, accessibility and search during maintenance

Maintenance can keep a site online while its experience degrades. Agree a small quality baseline for representative templates and key journeys. Include browser and device coverage, form validation, consent behavior, analytics signals, crawl controls, structured data where relevant and accessibility checks.

For performance, Google defines current Core Web Vitals around loading, responsiveness and visual stability, with good thresholds of LCP within 2.5 seconds, INP under 200 milliseconds and CLS below 0.1. [7] Use field data where available, record the page set and measurement window, and avoid turning one laboratory run into a contractual site-wide claim.

For accessibility, W3C describes WCAG 2.2 success criteria as testable and technology-neutral, and advises using the current version when updating policies. [8] A retainer should state which checks are automated, which require human evaluation, and whether remediation is included. A provider should not promise conformance based only on a scanner.

Use an eight-gate maintenance acceptance matrix

Do not average these gates into one score. An excellent response time does not compensate for untested recovery or provider-owned credentials. Name the gates that block acceptance and the ones that can remain open with a dated remediation plan.

Worked example: a checkout failure after a plugin update

Consider a fictional ecommerce site whose payment step starts returning an error after a scheduled plugin update at 09:10. Synthetic checkout monitoring detects the failure at 09:13 and alerts the maintenance provider. The agreed matrix classifies a site-wide inability to pay as critical.

The provider acknowledges at 09:18, records the change identifier and stops further deployments. At 09:24 it reproduces the failure, assigns an incident lead and tells the buyer what users see. The team rolls back the plugin in staging, runs checkout and order-notification tests, then restores production at 09:42. Response took five minutes from detection; restoration took 29 minutes. Those are different service outcomes.

The permanent fix is not to leave the plugin old indefinitely. The provider records the incompatible version, checks the upstream advisory, opens a vendor case and tests the corrected release. It reviews orders created around the incident, verifies analytics continuity and writes a short post-incident report. A new pre-release checkout test becomes an action item with an owner and due date.

These times are invented to demonstrate measurement, not a benchmark or client result. Acceptance depends on the agreed clocks, evidence and user impact. The same event would expose a weak retainer if the alert reached nobody, rollback credentials were missing or the buyer could not reconstruct what changed.

Make ownership and exit conditions part of the first proposal

The organization should control the domain registrar, DNS, hosting tenancy, source repository, deployment service, analytics, search tooling and primary CMS administrator account wherever practical. Give the provider named access with least privilege and a removal path. Secrets should move through an approved credential system, not tickets or shared documents.

Require runbooks for deployment, rollback, backup restoration, incident contacts and routine administration. Specify ownership of custom code, design files, licences, documentation and paid extensions. Record which licences are transferable and which must be replaced. A cheap retainer can become expensive when a provider-specific theme, private repository or agency licence blocks a successor.

The exit package should include current source, database and media export, infrastructure and DNS inventory, dependency list, open risks, recent incidents, monitoring configuration, backup location, release history, account map and a live handover session. Test the exit before the final month by asking an internal or independent reviewer to locate the repository, restore instructions and emergency contacts.

Compare retainers with one buyer checklist

• The maintained inventory names components, owners, access, monitoring and exclusions.
• Operational maintenance, incidents and change requests have separate scope and pricing rules.
• Priorities use user impact, security exposure, breadth and workaround availability.
• Targets distinguish acknowledgement, diagnosis, mitigation, restoration and permanent resolution.
• Support windows, clock pauses, escalation and communication frequency are explicit.
• Monitoring covers agreed user journeys and routes actionable alerts to named responders.
• Patching includes inventory, impact analysis, testing, approval, rollback and tracked exceptions.
• Backup terms state recovery objectives, coverage, retention, independent access and restore tests.
• Release records identify the change, test evidence, approver and rollback outcome.
• Performance, accessibility, search, analytics and form checks use an agreed baseline.
• Monthly reports show exceptions, incidents, changes, risks and overdue actions, not only activity hours.
• Buyer-owned accounts, source, licences, documentation and exit exports are contract requirements.

Ask each provider to price the same boundary and scenarios. A lower fee may be rational when the site is simple, the internal team owns incidents or the provider covers business hours only. Do not buy a full retainer when scheduled updates and an on-demand agreement satisfy the actual risk. Conversely, an always-on commercial journey needs tested recovery and incident ownership, not a low monthly hour cap.

TechLithic provides website maintenance and support and WordPress development. Apply this framework equally to TechLithic and competing providers. For the project boundary before maintenance begins, see the website redesign scope guide; for URL and search controls during a major change, use the technical SEO migration checklist.

Frequently asked questions