Uptime.com Blog

SLA Reporting: Tips & Best Practices

Service-Level Agreements (SLAs) are part of the package when it comes to defining contracts, particularly with technology service vendors. An SLA serves to define the metrics, expectations, and penalties that the service provider will adhere to, and SLA reports create accountability.

Taking an active, multi-faceted approach to reporting on SLA accountability helps to construct a reputation of reliability and results-focused service but you’ll need clear metrics from an independent Service Level Indicator (SLI) to back your claims with uptime and response time data. 

SLAs are Like Watermelons?

SLAs can come off as subjective, and have garnered a bit of a prior reputation as “Watermelon Reports”, green status on the surface, hiding red alerts “beneath the rind”. This is a likely source for the trend of SLA reports moving from just a display of policies and metrics into a linkage between measuring processes and projecting results.

What’s Inside an SLA?

What makes an SLA juicy, and why are they such an integral part of ‘getting into bed’ with another company or service provider?

An SLA should:

• Describe the services to be provided
• Define the expected service levels
• Determine the metrics that measure service levels
• Outline the responsibilities of each party
• Establish a protocol for handling penalties, remedies, breaches, & adding or removing metrics

An SLA agreement dictates the contract between company and provider, and should showcase how the service provider influences the company’s business outcomes through their partnership. The other half of the coin is reporting. SLA Reporting is an on-demand report card for services that your client will request at specified periods. 

We can boil an SLA down to three absolutely necessary topics:

Availability

An SLA for uptime is common these days. A guarantee for 100% uptime is never realistic but you will very often see something like 99.99% uptime availability measured monthly. Timing is also an issue and SLA metrics may need to reflect a focus on availability during standard business hours as opposed to all day every day.

Response

An SLA for speed is a parameter you should define, especially if you work from a cloud-based infrastructure. How does your provider calculate SLA Response Time? Is the target response time the same for all the services? 

Customer Satisfaction

How available is the provider’s support team? What is their ratio of solved tickets? What is the average response time of their team to incidents? SLAs blanket all forms of service provided from human to automated.

Proving that you’ve Met SLA Targets

Let’s talk about arguments. When a provider and a customer get into a spat, it’s usually because someone is lacking the facts. In business, if the provider has the facts they can work to correct the understanding and allow the company to save face. If the company holds the facts, they get to request the refund. 

An effective SLA will incentivize the vendor to uphold their SLA declarations while protecting the client’s interests if the vendor fails to do so. As a provider, it’s one thing to declare your services, and another entirely to defend them. 

A Supportive Arsenal

How do you defend your metrics? It goes without saying that you should report your metrics with honest accuracy based on the agreed upon calculations. Beyond that, user experience data can become invaluable should you need to settle a dispute. 

Using Real User Monitoring (RUM) in conjunction with SLA reports can help determine the source of any user experience issues that may come into play when discussing delays and working toward resolutions. RUM reporting compiles data for page load times per browser and per device throughout the user’s session for your URLs and transaction paths. Insights from these reports can be used to strengthen your reported SLA metrics. 

Breaking down the Uptime.com SLA Approach

Uptime.com offers a logical SLA reporting path from the initial check creation through to public & private reporting, and facilitates team communication and response. Here’s the essential path:

1. Start by configuring your checks, individually or in bulk, with your Target SLA% and Target Response time SLA (in secs). 

Create Public SLA pages for your clients to reference your historical percentages and metrics as often as they’d like and build trust between regularly scheduled reporting.

Check out our Sample Public SLA Page

2.  Create SLA reports for specific metrics and services to convey website uptime and SLA accountability to your clients or stakeholders.

3.  Link your SLA reports to Scheduled Reporting at your client’s requested intervals. Generate an SLA report in your account for the past week, or month, etc. and the associated scheduled report will compile data based on your SLA reports configurations. 

Pro Tip: Create separate reports for individual client’s metrics at their requested intervals so the correct policies are always applied. Contracts can vary.

SLAs for Your Team

Generally, SLAs are agreements between separate companies and vendors, but they can also exist within a company between its departments when one department is responsible for managing a certain set of services. 

Take your SLA reporting a step further and generate them for your extended team based on relevant checks or services. In a multi-national company environment, these SLA reports can help bridge time zones and can be generated quickly with the use of check tags to report region-specific, or client specific services to the right team members. 

This way of spotlighting focus on particular services may help expedite troubleshooting when the widespread accessibility and notification features of an Internal Status Page aren’t warranted – like during unexpected downtime. 

The backend requirement of successful SLA agreements and reporting is having control over your systems and services. Reporting is an obligation and a reflection of functionality. A wise devops engineer would see that SLA reporting is also a powerful tool for delegation and internal accountability, and those are assets you can scale.

Admin