How to Define SLA Uptime Targets for Maintenance Contracts

When a client asks during a contract renewal, "What uptime can you guarantee?", agencies that confidently define an SLA avoid disputes later. Those that guess — or commit to a number without defining what it covers — tend to face awkward conversations when a site goes down.

This guide walks through how to define an SLA for a maintenance contract, from choosing the right uptime number to drafting the measurement scope and getting client sign-off.

What SLA Means in Uptime Monitoring (30-Second Definition)

An SLA (Service Level Agreement) is a documented commitment on minimum service quality. In the context of website monitoring, the core metrics are:

The heart of a well-written SLA is agreeing in advance on what gets measured and what falls outside your responsibility.

Choosing the Right Uptime Number: 99.9% vs 99.99%

Uptime is expressed in "nines." Here is what each level means in real downtime:

Practical Selection for Agencies

99.9% is appropriate when:

• The site is a corporate or informational site
• Your team handles overnight incidents the next morning
• You cannot realistically staff 24/7 on-call coverage

99.99% is worth considering when:

• The site is an e-commerce or booking system where every minute of downtime has direct revenue impact
• Industry regulations require it (finance, healthcare)
• You have a 24/7 on-call rotation in place

Honest advice: For most agencies, guaranteeing 99.99% is technically achievable but operationally unrealistic. Infrastructure failures at the hosting or CDN layer are outside your control. Only commit to what you can actually control.

Defining the Measurement Scope

The measurement scope matters more than the number itself.

What to Include and Exclude

Monitored URLs:
- https://example.com/ (homepage)
- https://example.com/contact/ (contact form)

Excluded from measurement:
- Outages caused by third-party services (CDN, hosting provider, DNS registrar)
- Downtime caused by client-initiated changes (DNS edits, CMS content errors)
- Natural disasters or infrastructure-level failures (AWS, GCP major outages)
- Planned maintenance windows (agreed in advance, max 2 hours/month)

Configuring Monitors in Miterl

Miterl monitors each URL individually and reports uptime as uptime_30d.

# Create a monitor for the homepage
curl -X POST https://miterl.com/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/",
    "name": "example.com - Corporate Site",
    "type": "http",
    "interval_seconds": 60,
    "alert_contact_ids": [1, 2]
  }'

Retrieve the monthly uptime figure for SLA reporting:

curl -s "https://miterl.com/api/v1/monitors/1" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq '{name: .name, uptime_30d: .uptime_30d}'
# Output: {"name": "example.com - Corporate Site", "uptime_30d": 99.97}

The Client Agreement Process

Step 1: Measure First, Commit Second

Before promising any uptime number, measure actual uptime for one to three months. Committing to 99.9% and then reporting 99.7% in month one is a poor start to a client relationship. Miterl's free plan captures the data you need to establish a baseline.

Step 2: Define Exclusions Before Signing

Agreeing on exclusions upfront prevents disputes. Document explicitly:

• Third-party outages: Hosting provider, CDN, DNS registrar failures
• Client-caused downtime: CMS errors, DNS configuration changes by the client
• Force majeure: Large-scale infrastructure failures beyond anyone's control
• Planned maintenance: Pre-notified downtime during the agreed maintenance window

Step 3: Set Realistic Penalties

SLA penalties are commonly structured as service credits — a percentage of the monthly fee returned if the SLA is missed.

Always cap the total penalty at 100% of the monthly fee. Exposure beyond the contract value is unreasonable for a maintenance provider.

Step 4: Define the Reporting Cycle

State in the contract that monthly uptime reports will be delivered by a specific date. Miterl makes this straightforward with API-based report generation:

# Pull monthly uptime across all monitored sites
curl -s "https://miterl.com/api/v1/monitors?per_page=100" \
  -H "Authorization: Bearer YOUR_API_KEY" | \
  jq -r '.data[] | "[\(.name)] Monthly uptime: \(.uptime_30d)%"'

For automating report generation and delivery end-to-end, see "SLA Report Automation Guide for Agency Maintenance Subscriptions."

Common SLA Pitfalls and How to Avoid Them

Pitfall 1: Vague Definition of "Uptime"

Problem: A client calls a slow page load an "outage" and claims an SLA breach.

Fix: Define uptime explicitly as "the monitored URL returning HTTP status 2xx." If response time is in scope, add a separate metric: "response time under X seconds at the monitoring check interval."

Pitfall 2: Changing the Measurement Tool Mid-Contract

Problem: Switching monitoring tools changes how uptime is calculated, leading to discrepancies.

Fix: Name the tool in the contract — "Uptime is measured by Miterl (https://miterl.com) and its data is the authoritative record."

Pitfall 3: Third-Party Outages Not Excluded

Problem: An AWS regional outage takes down the client's site. The client argues this is your SLA breach.

Fix: Explicitly exclude third-party infrastructure outages from the SLA. Miterl lets you add notes to incidents; use these to record the root cause as a third-party event for documentation.

Pitfall 4: Conflating Uptime Guarantee with Response Time Guarantee

Problem: "99.9% uptime, 24/7" implies you respond to incidents within minutes, but overnight issues get handled the next morning.

Fix: Separate uptime measurement (continuous, automated) from response time commitment (tied to business hours). A clean contract reads: "Uptime is measured 24/7. Incident response begins within 30 minutes during business hours (Mon–Fri 09:00–18:00 JST) and by 10:00 on the next business day for off-hours incidents."

SLA Contract Language Template (Excerpt)

UPTIME SLA — EXCERPT

1. Uptime definition
   Uptime is defined as the percentage of time during which the
   monitored URL returns an HTTP 2xx status code, as recorded by
   Miterl (https://miterl.com).

2. Monitored URLs
   - https://example.com/
   (Additional URLs specified in Exhibit A)

3. Uptime target
   Monthly uptime: 99.9% or greater

4. Exclusions
   a) Planned maintenance (pre-notified, max 2 hours/month)
   b) Outages caused by third-party services (hosting, CDN, DNS)
   c) Downtime caused by client-initiated changes
   d) Force majeure events

5. Remedies for breach
   If monthly uptime falls below 99.9%, Client receives a service
   credit of 10% of the monthly fee, applied to the following invoice.
   Maximum credit is capped at 100% of the monthly fee.

6. Reporting
   A monthly uptime report is delivered by the 5th of the
   following month.

Monitoring Setup Checklist Once the SLA Is Signed

• All contracted URLs registered in Miterl
• Monitoring interval set to 1–3 minutes (coarser intervals inflate reported uptime)
• Alert contacts configured (Slack, email)
• Maintenance windows configured to suppress alerts during planned downtime
• Monthly report delivery automated or calendared

For configuring response time thresholds as part of an SLA that covers latency, see "Response Time Monitoring Guide: Detecting HTTP Response Failures Early." For the exact downtime figures behind each uptime percentage, see "Uptime 99.9% vs 99.99%: Downtime Calculator and What the Numbers Mean."

Summary

Defining an SLA is less about picking a number and more about agreeing clearly on what gets measured and what falls outside the contract.

• Measure first for one to three months; commit to a number only after establishing a baseline
• Exclude what you cannot control — third-party infrastructure and client-caused downtime
• Separate uptime measurement (24/7 automated) from incident response time (business hours)
• Deliver monthly reports on a fixed schedule to make the SLA tangible to clients

Once your SLA is defined, the next step is producing the reports that demonstrate you are meeting it. "Uptime Report Guide: Client-Facing SLA Reports That Build Trust" covers report structure and delivery timing. To automate the entire reporting pipeline, see "SLA Report Automation Guide for Agency Maintenance Subscriptions." Full feature documentation is at /en/docs. Common questions are answered in the FAQ. Sign up free to start measuring your baseline today.