What a Good Enterprise Website SLA Contains

A good website maintenance SLA defines what is covered, how incidents are classified by severity, how fast the supplier must respond and resolve each tier, how performance is reported, and how either side can exit cleanly. Those five elements turn a general promise of support into something both parties can measure. This guide goes through the contract clause by clause, with the questions to ask before you sign.

If you are still deciding whether your site needs an SLA at all, start with the case for treating your website as a production system. This article assumes that decision is made and focuses on the contents.

Clause 1: Scope of services

The scope clause says exactly what the supplier supports. Vague scope is the most common source of SLA disputes, because each side assumes something different is included.

What to define

• Covered environments: production, staging and any development environments.
• Covered components: the CMS, custom code, themes, plugins or modules, and named integrations such as CRM, payment gateway or ERP connections.
• Covered domains and properties: the main site, microsites, landing pages and language versions.
• Service types: incident fixes, preventive maintenance, security updates, minor enhancements and content support, each listed separately.

What to exclude explicitly

List what is outside scope: new features, redesigns, third party outages, issues caused by changes made by the client or other suppliers, and hosting if it is contracted separately. Exclusions are not a sign of a weak supplier. They prevent arguments later.

Clause 2: Severity tiers

Severity tiers classify incidents by business impact so that the most damaging problems get the fastest attention. Four tiers are common, though the labels vary.

Questions to settle

• Who assigns severity: the client, the supplier, or the client with a right for the supplier to challenge?
• Can severity be raised or lowered during an incident as impact becomes clearer?
• Are specific business events, such as a campaign launch or results announcement, treated as higher risk periods?

Define tiers by impact on users and business functions, not by how hard the fix is. A one line configuration error that stops payments is still critical.

Clause 3: Response time and resolution time

This clause is the heart of the SLA and the one most often misunderstood. Response time and resolution time are different commitments.

Response time

Response time is how quickly a qualified person acknowledges the incident and starts work. An automated email reply does not count. The contract should state that response means a named engineer has begun investigating.

Resolution time

Resolution time is how quickly service is restored. Many SLAs distinguish between a workaround, which restores the business function temporarily, and a permanent fix. A realistic SLA commits to a target for the workaround and a plan for the permanent fix, because some root causes take longer to correct safely.

Coverage hours

State when the clock runs. Critical incidents may be covered at all hours, while lower tiers are handled during business hours. In the UAE, define the working week and public holidays explicitly, and say how the clock behaves across weekends and holidays. If the supplier's team works across several time zones, confirm which time zone the SLA uses.

Hypothetical example

A clause might say: for critical incidents, a named engineer responds within a short agreed window at any hour and provides updates at fixed intervals until a workaround is in place; for medium incidents, response within business hours on the next working day. The exact windows depend on the site's risk and the support budget, and should be agreed with the supplier rather than copied from a template.

Clause 4: Availability and the uptime SLA

An uptime SLA states the availability target for the site and how it is measured. A target with no measurement method is close to meaningless.

• What is measured: the homepage only, or a set of key pages and transactions? Functional checks on forms and checkout give a truer picture than a homepage ping.
• How it is measured: the monitoring tool, check frequency and locations. Agree that both parties can see the monitoring data.
• Measurement period: usually monthly.
• Planned maintenance: how much notice is required and whether planned downtime is excluded from the calculation.
• Dependencies: how outages caused by hosting, DNS or third party services are treated if those are contracted separately.

Convert any availability target into allowed minutes of downtime per month. Non technical stakeholders understand a number of minutes far better than an abstract target, and the conversion often prompts a useful conversation about whether the target is realistic for the hosting in place.

Clause 5: Preventive maintenance

A website maintenance SLA should cover the work that stops incidents from happening, not only the response when they do.

• Security patching for the CMS, plugins, frameworks and server software where in scope, with a target window after a critical security release.
• Backups: frequency, retention period, storage location and a scheduled restore test.
• Certificate and domain renewal tracking.
• Performance checks against agreed indicators such as Core Web Vitals.
• Dependency reviews to flag components approaching end of support.

A backup that has never been restored is an assumption, not a safeguard. Make restore testing a contractual obligation.

Clause 6: Change management and releases

Many incidents are caused by changes. The SLA should state how changes reach production: a staging environment, testing before release, an approval step for significant changes, release windows that avoid peak trading hours, and a rollback plan for every release. It should also say who is allowed to make changes directly in production, and what happens to response commitments if an unapproved change causes an incident.

Clause 7: Communication and escalation

• Channels: how incidents are raised, such as a ticketing portal, email address or phone line for critical issues.
• Update intervals: how often the supplier reports progress for each severity tier.
• Escalation path: named roles at each level on both sides, with contact details kept current.
• Post incident reports: for critical and high incidents, a written root cause analysis within an agreed period, including preventive actions.

Clause 8: Reporting and service reviews

Regular reporting shows whether the SLA is working. A monthly report typically includes:

1. Availability for the period, measured as agreed.
2. Incidents by severity, with response and resolution times against targets.
3. Maintenance completed: updates, patches, backups and restore tests.
4. Hours used against any allocation for enhancements.
5. Risks and recommendations, such as components nearing end of support.

Pair the report with a regular service review meeting. Quarterly is common for enterprise sites. The review is where recurring issues are discussed and the scope or targets are adjusted.

Clause 9: Service credits and remedies

The reliability engineering definition in Google's Site Reliability Engineering book describes an SLA as a contract that includes consequences of meeting or missing its objectives. For website support, the usual consequence is a service credit against future invoices when targets are missed.

Service credits rarely compensate for the business impact of an outage, so do not treat them as insurance. Their real value is as a signal. Repeated misses should also trigger stronger remedies, such as a remediation plan with dates, or a right to terminate for persistent failure. Have your legal team review how credits interact with liability caps elsewhere in the contract.

Clause 10: Security and data handling

Set out how security incidents are handled: who must be notified, how quickly, and who coordinates the response. Include access control rules, such as individual accounts rather than shared logins, and removal of access when staff change. If the site processes personal data, applicable UAE data protection rules may affect notification and handling obligations, and requirements differ for organisations in DIFC or ADGM, which have their own data protection regimes. Confirm the position with counsel or the relevant regulator rather than relying on a template.

Clause 11: Exit and transition

The exit clause is often missing, and its absence is costly when a relationship ends. A good exit clause covers:

• Notice period for termination by either side, and termination rights for persistent SLA failure.
• Handover obligations: source code, repository access, credentials, documentation, deployment scripts and monitoring configuration.
• Transition support: a period during which the outgoing supplier answers questions from the new one.
• Ownership: confirmation that the client owns the code, content and accounts, subject to any third party licences.

If you are preparing to change supplier or rebuild, the guide on auditing an enterprise website before a rebuild explains what to document first.

Checklist: reviewing a website maintenance SLA before signing

• Scope lists every environment, component and integration, with clear exclusions.
• Severity tiers are defined by business impact, with examples.
• Response and resolution are separate commitments for each tier.
• Coverage hours, weekends, public holidays and time zone are stated.
• The uptime measurement method is defined and visible to both sides.
• Backups include scheduled restore tests.
• Change management requires staging, testing and rollback.
• Escalation contacts are named on both sides.
• Monthly reports and periodic reviews are scheduled.
• Remedies escalate for repeated failure.
• Exit terms include a full handover of code, access and documentation.

Budgeting for support

Support effort is an ongoing operating cost rather than a one off project expense, and finance teams will want to see it planned that way. The article on capex and opex in enterprise web projects explains how to present it, and building an enterprise website business case shows how support fits into the wider justification. To get an accurate quote, give suppliers your severity definitions, coverage hours, integration list and expected volume of enhancements, rather than asking for a generic monthly package.

Talking through support for your website

An SLA works best when the site behind it is well documented and built with monitoring and staging in place. Codeeo's website design and development and WordPress development teams can walk through how your site is built and what level of support its integrations and traffic realistically need. If performance is part of the concern, the Core Web Vitals service page explains how page experience is assessed. To start the conversation, contact Codeeo, or meet the team at the Dubai office.