Website Maintenance SLA Buying Guide for Severity and Evidence

Learn how to evaluate website maintenance SLAs by focusing on severity definitions, response and restoration times, and the evidence you need to verify compliance.

Why Define Severity by User Impact?

When you compare website maintenance proposals, the first thing you notice is how casually vendors use words like "critical" or "urgent." One provider’s "critical" might mean the entire site is down, while another uses it for a broken image on a single page.

That ambiguity leads to missed expectations and disputes when an issue arises. The fix is to define severity not by the vendor’s internal labels but by the actual impact on your users and your business.

Consider a scenario: your online store is processing orders, but the checkout page fails intermittently. For a small blog, that might be a nuisance. For an e-commerce site, it’s a revenue emergency.

The same technical issue has different business consequences depending on your context. Therefore, an SLA that defines severity solely by technical symptoms—like "server error" or "database timeout"—is less useful than one that ties severity to user impact.

A practical principle is to categorize issues based on how they affect your visitors and your operations. For example, a total outage that prevents all users from accessing the site is clearly more severe than a backend-only issue that no visitor sees.

By using impact-based definitions, you and your provider can agree on what constitutes an emergency and what can wait.

This approach also helps you prioritize your own internal resources. If you know that a P1 issue means your entire site is down, you can alert your team and prepare to coordinate with the provider.

Without such clarity, you might waste time debating whether an issue is truly "critical" while your users are already affected.

When reviewing an SLA, look for definitions that reference user-facing consequences. If the document only uses vague terms without explaining what they mean in practice, ask the vendor to clarify.

Severity Levels: Clear Definitions from P1 to P4

A common framework uses four severity levels, from P1 (most severe) to P4 (least severe). Here is a practical breakdown you can use as a reference when evaluating vendor SLAs.

**P1 – Total outage:** The website is completely down, and all users are affected. This includes scenarios like a server crash, DNS failure, or a database corruption that makes the site inaccessible.

Immediate response is required, and the provider should begin work within minutes.

**P2 – Major functionality impaired:** A significant portion of users cannot use a core feature. For example, the site loads, but the shopping cart fails, or the login system is broken.

This affects most users and requires rapid response, though not necessarily an immediate fix.

**P3 – Localized issue:** The problem affects a subset of users or a non-critical part of the site. For instance, a plugin conflict on a specific page or a form that fails only for certain browsers.

Normal handling is acceptable, with a response within a few hours.

**P4 – Minor issue:** This is a cosmetic bug or a small glitch that has no impact on core functionality. Examples include a misaligned image or a typo in the footer. These can be scheduled for a routine maintenance window.

When you see these definitions in an SLA, check that they are tied to user impact, not just technical symptoms. For example, a P2 should specify that "most users" are affected, not just that a "module" is down.

This prevents the vendor from downgrading an issue that actually affects many visitors.

Also, consider how the severity level is determined. Who decides whether an issue is P1 or P2? Ideally, the client can report an issue and assign a provisional severity, but the provider may reclassify after investigation.

The SLA should outline a clear process for escalation if you disagree.

Response and Restoration Times: Setting Realistic Targets

Two terms often get confused: response time and restoration time. Response time is when the provider acknowledges your report and starts working on it. Restoration time is when the issue is resolved, either with a temporary fix or a permanent solution.

Both are critical to measure, but they serve different purposes.

For example, a P1 issue might have a response time of 15 minutes and a restoration time of 4 hours. The restoration could be a temporary workaround, like switching to a backup server, while a permanent fix is applied later.

When setting targets, be realistic. A response time of 5 minutes might sound impressive, but it may not be achievable for a small maintenance provider. Look for targets that align with your own needs and the provider’s capabilities.

Also, consider the difference between business hours and 24/7 coverage. If your site is critical, you may need round-the-clock monitoring and support.

The SLA should specify when response and restoration times apply—whether they are measured during business hours only or around the clock.

Another important aspect is communication. The SLA should define how the provider will keep you informed during an incident. Will they send email updates? Is there a phone number to call?

What is the escalation procedure if the issue is not resolved within the agreed time? Clear communication procedures prevent you from being left in the dark.

Finally, think about evidence. How will you know that the provider met the response and restoration targets? The SLA should require monthly reports that include incident logs, response times, restoration times, and any breaches.

This evidence is essential for holding the provider accountable.

To help you compare SLAs from different vendors, use a checklist that covers these key areas:

Communication: Keeping You Informed During Incidents

When an incident occurs, the SLA should specify how and when you will be updated. Without clear communication requirements, you may be left in the dark while your website is down, leading to frustration and uncertainty.

A robust SLA will define the frequency and channel of updates, ensuring you can track progress and plan your own responses.

**Regular status updates** are a cornerstone of good incident communication. The SLA should state a specific interval—for example, every 30 minutes—during which the provider must send a status update.

This cadence keeps you informed without overwhelming you with messages. For critical incidents, more frequent updates may be appropriate, but the key is that the interval is explicit and measurable.

If the provider fails to meet this commitment, you have a clear basis for complaint.

**Designated channels** for communication should also be agreed upon in advance. Common options include email, phone, or a project management tool like Jira or Slack. The SLA should specify which channel will be used for different types of updates.

For instance, urgent alerts might go via phone or SMS, while detailed written summaries are sent by email. Having a single, agreed-upon channel prevents confusion and ensures that updates are not missed.

Make sure the provider commits to using the channel you prefer and that they have a backup in case the primary channel fails.

**Escalation paths** are essential for ensuring that issues are resolved in a timely manner. The SLA should outline what happens if the initial response or restoration targets are not met.

For example, if a critical issue is not resolved within the agreed restoration time, the incident should be escalated to a higher level of support or management. The escalation path should be clearly defined, including who will be contacted and at what point.

This provides a mechanism to apply pressure and ensures that your issue gets the attention it deserves. Without an escalation path, you may find that your incident languishes in a queue with no clear route to resolution.

In addition to these elements, the SLA should specify who is responsible for communication. A single point of contact (SPOC) is often beneficial, as it avoids multiple people sending conflicting updates.

The SPOC should be named or at least the role defined, so you know who to expect updates from. Also, consider how communication will be handled after hours or on weekends.

If your website is business-critical, you may need 24/7 communication coverage, which should be reflected in the SLA.

Finally, ensure that the communication requirements are realistic and enforceable. Vague statements like "we will keep you informed" are not sufficient. Instead, the SLA should include concrete commitments that can be measured and verified.

Exclusions and Limitations: Avoiding Surprises

Every SLA contains exclusions—situations where the provider is not responsible for meeting the agreed service levels. While some exclusions are reasonable, others can be overly broad and leave you without coverage when you need it most.

Understanding common exclusions and scrutinizing them carefully is essential to avoid surprises.

**Common exclusions** often include failures caused by third-party services, such as your hosting provider, CDN, or payment gateway.

If your website relies on external services, the provider may argue that they cannot be held accountable for outages outside their control.

While this is understandable, you should ensure that the provider is responsible for coordinating with those third parties and for keeping you informed.

Additionally, user-initiated code changes—such as updates made by your own developers—are typically excluded. This is reasonable, but the SLA should clearly define what constitutes a "user-initiated change" to prevent disputes.

Force majeure events, like natural disasters or internet-wide outages, are also standard exclusions, but they should be narrowly defined and not used as a catch-all.

**Require providers to list all exclusions explicitly. ** A vague clause like "other causes beyond our reasonable control" is a red flag. Insist on a comprehensive list that covers every scenario the provider intends to exclude.

This list should be part of the SLA and agreed upon before signing. If a provider is reluctant to specify exclusions, it may indicate that they intend to use broad language to avoid responsibility.

A transparent provider will be happy to clarify what is and isn’t covered.

**Ensure exclusions don’t cover core maintenance responsibilities.

** For example, if the SLA includes regular updates to the CMS or security patches, an exclusion for "software bugs introduced by third-party plugins" might be acceptable, but it should not exclude the provider’s duty to apply those updates.

Similarly, if the provider is responsible for monitoring, they cannot exclude all monitoring failures as "technical issues."

The exclusions should be limited to events that are genuinely outside the provider’s control and not overlap with the core services you are paying for.

To protect yourself, ask for examples of how exclusions have been applied in the past. While the provider may not share specific client details, they can describe typical scenarios.

This will give you a sense of whether the exclusions are used fairly or as a loophole. Also, consider negotiating exclusions that are too broad.

For instance, if the SLA excludes "any downtime due to maintenance," clarify that scheduled maintenance must be communicated in advance and performed during low-traffic windows, and that it does not count toward the agreed uptime.

Finally, remember that exclusions are not necessarily deal-breakers. They are a normal part of any SLA. The key is to understand them fully and ensure they are balanced.

Monthly Reports: Evidence of SLA Compliance

A monthly report is your primary evidence that the provider is meeting the SLA targets. Without such reports, you have no way to verify compliance or hold the provider accountable.

Therefore, the SLA should require the provider to deliver a detailed monthly report that includes specific metrics and supporting documentation.

**Reports should include** at least the following: the number of incidents that occurred during the month, the response time for each incident, the restoration time, and the resolution rate.

These metrics allow you to see whether the provider is consistently meeting the agreed targets. For example, if the SLA promises a response time of 30 minutes for critical issues, the report should show the actual response times for each critical incident.

If any incidents exceeded the target, they should be highlighted, along with an explanation.

**Require screenshots or ticket logs as evidence. ** A summary table is useful, but it is not sufficient.

The provider should attach ticket logs or screenshots from their helpdesk system that show the timestamps of when incidents were reported, when the provider responded, and when the issue was resolved.

This raw data allows you to verify the accuracy of the summary. If the provider is unwilling to share this level of detail, it may be a sign that they are not tracking their performance accurately or that they have something to hide.

**Agree on compensation if targets are missed. ** The SLA should include a service credit or penalty mechanism for when the provider fails to meet the agreed targets.

For example, if the response time for a critical issue exceeds the target, you might be entitled to a credit on your next invoice. The amount and conditions should be clearly defined in the SLA.

This not only provides a remedy for you but also incentivizes the provider to meet their commitments. Without such a mechanism, the SLA is merely a statement of intent with no teeth.

When reviewing monthly reports, look for trends. A single missed target may be an anomaly, but repeated failures indicate a systemic problem. The report should also include a summary of any ongoing issues or root cause analyses.

If the provider is consistently missing targets, you may need to escalate the matter or consider terminating the contract.

Finally, ensure that the reporting schedule is realistic. Monthly reports are standard, but for high-traffic or business-critical websites, you might require weekly or even real-time dashboards.

The SLA should specify the format and delivery method of the report, such as a PDF emailed to you or access to an online dashboard.

How to Compare SLAs from Different Vendors

When evaluating maintenance proposals, you need a systematic way to compare SLAs from different vendors. A side-by-side comparison allows you to see which vendor offers the most robust coverage and which terms are most favorable to you.

The following framework will help you make an objective decision.

**Create a comparison table** listing each vendor’s severity definitions, response times, restoration goals, communication procedures, exclusions, and reporting practices. This table should be filled out using the actual text from each vendor’s SLA.

Do not rely on summaries provided by sales representatives; go directly to the contract language. This ensures that you are comparing like-for-like terms.

**Check that all terms are clear and measurable. ** Vague language such as "we will respond promptly" is not acceptable. Each term should have a specific number or a defined process.

For example, response time should be stated in minutes or hours, and severity levels should be defined based on user impact. If a vendor’s SLA is full of ambiguous terms, it may be a sign that they are not committed to accountability.

**Ask vendors for historical SLA achievement rates (with evidence). ** While past performance is not a guarantee of future results, it gives you an indication of the vendor’s reliability.

Ask for a summary of their SLA compliance over the past six to twelve months, including any service credits issued. A vendor with a high achievement rate is more likely to meet their targets.

To make the comparison easier, use the following checklist as a guide. For each vendor, note whether they meet each criterion and any comments.

This checklist is a starting point. You may also want to consider other factors such as the vendor’s experience with your CMS, their security practices, and their customer support reputation.

However, by focusing on the SLA terms, you can ensure that you are comparing vendors on a consistent basis.

When you have completed the table, review the results. Look for vendors that meet all or most of the criteria. If a vendor fails on a critical point, such as not providing evidence in monthly reports, you may want to eliminate them from consideration.

Remember that the cheapest option is not always the best value. A slightly higher price may be worth it for a more comprehensive SLA that gives you peace of mind.

Finally, do not be afraid to negotiate. If a vendor’s SLA is missing a key element, ask if they can add it. Many providers are willing to customize their SLAs to win your business.

Next step

Download the website maintenance SLA comparison checklist to evaluate vendor proposals.