This SLA outlines the service levels and performance metrics for the Services provided by Service Provider.
General Principles
This SLA applies only to the Services explicitly covered in Schedule A.
All times are based on SLA time zone unless otherwise specified.
Service Provider is not responsible for issues arising from Client’s actions, third-party vendor issues beyond Service Provider’s control, or Force Majeure events.
Incident Response & Resolution Times
Severity Level
Definition
(Client Impact)
Response Time (Initial Acknowledgment)
Resolution Time Target
Severity 1
Critical business function/system is completely down. High user impact.
Within Severity 1 response time minutes
Within Severity 1 resolution hours
Severity 2
Significant degradation of service, major function impaired. Some user impact.
Within Severity 2 response time minutes
Within Severity 2 resolution hours
Severity 3
Minor service degradation, isolated issue, or low user impact.
Within Severity 3 response hour
Within Severity 3 resolution hours
Severity 4
General inquiries, non-critical issues, feature requests.
Within Severity 4 response time hours
Best effort, within Severity 4 resolution business hours
Business Hours (Offshore): While support is 24/7, resolution times for Severity 3 & 4 issues, and potentially non-critical development tasks, may primarily occur during the offshore team’s standard business hours.
Definition of Resolution: The issue is either fully resolved, a workaround is in place, or a clear plan for definitive resolution has been communicated to Client.
Service Availability/ Uptime Guarantee
Cloud Services Instance Uptime: Service Provider will use commercially reasonable efforts to ensure Uptime guarantee% uptime availability for the Client’s primary Cloud Services instances under its management, excluding scheduled maintenance.
Scheduled Maintenance: Service Provider will provide Client with at least Scheduled maintenance notice hours’ prior notice for any planned downtime or scheduled maintenance that may impact Service availability. Such maintenance will be scheduled during periods of lowest anticipated impact to Client’s operations.
Service Credits for SLA violations
In the event Service Provider fails to meet the specified SLA targets, Client shall be entitled to service credits as follows:
Severity 1 Resolution Time Miss: Severity 1 service credit % of the Monthly Service Fee for each occurrence.
Severity 2 Resolution Time Miss: Severity 2 service credit% of the Monthly Service Fee for each occurrence.
Uptime Guarantee Miss:
Below Uptime credit threshold %: Uptime service credit % of the Monthly Service Fee.
Maximum Service Credits: The total amount of service credits that can be claimed by Client in any single calendar month shall not exceed Maximum service credit % of the Monthly Service Fee for that month.
Credit Application: Service credits will be applied against the subsequent month’s invoice.
Reporting
Service Provider shall provide Client with a brief monthly report by the Reporting day business day of each month, including:
A summary of critical incidents (Severity 1 and 2) reported and resolved during the previous month.
Notable system improvements, configuration changes, or optimizations implemented.
No additional reporting shall be required unless mutually agreed in writing.
Review and Adjustment
This SLA may be reviewed and adjusted annually by mutual written agreement of both parties to reflect changes in Client’s requirements, technology, or market conditions.
Definitions
“Availability” means the ability to login and perform operations by means of the Platform.
“Claim” means a claim for a Service Credit submitted by opening a support case, on the basis that the Platform has been Unavailable during a service period.
“Licensee” refers to the person or entity who is using and paying for services on the Platform.
“Incident” means any set of circumstances resulting in the Unavailability of or data loss in the Platform at any time, consistent with the Service Level commitments under this Agreement. An Incident, for purposes of submitting and determining the validity of a Claim, shall not be based on any SLA Exclusions.
“Service Level” means the amount of time expressed as a percentage during which the Platform is available and accessible to users.
“Service Year” is the 365 day period preceding the date of an SLA claim.
“SLA Exclusion” means an instance or reason for which the Service Level Commitment hereunder does not apply and the associated inability to login and perform operations by means of the Platform does not constitute Unavailability or Data Loss for purposes of a Service Credit.
“Unavailable” or “Unavailability” means each full increment of 5 minutes during your use of the Platform where access to the Platform has no functionality.
Schedule A
Scope of Services
This Schedule A details the specific IT infrastructure, support, and development services to be provided by Service Provider.
IT Infrastructure Management
Proactive Monitoring: 24/7 monitoring of Client’s Service provider description instance health, performance, resource utilization (CPU, memory, disk, network), and critical application uptime.
Patch Management: Timely application of security patches and critical updates to operating systems, databases, and core software components within the Client Environment.
Configuration Management: Management and maintenance of Cloud Services configurations, firewall rules, network settings, and other infrastructure components.
Backup & Disaster Recovery Oversight: Monitoring and management of existing backup solutions. Assistance with disaster recovery planning and periodic testing.
Security Management: Basic security monitoring, vulnerability scanning (if applicable and agreed upon), and incident response coordination.
Cost Optimization Support: Recommendations and assistance with optimizing Cloud Services resource usage to manage costs.
Capacity Planning: Monitoring resource consumption and providing recommendations for scaling infrastructure as needed.
Support Staff
Level 1 & 2 Support:
Availability: 24 hours a day, 7 days a week, 365 days a year.
Channels: Support via email, ticketing system, and/or designated chat channels. Phone support for critical (Severity 1) issues.
Incident Management: Logging, prioritization, diagnosis, and resolution of incidents related to the Client Environment.
Problem Management: Identification of root causes for recurring incidents and implementation of preventative measures.
Service Request Fulfillment: Handling of routine requests such as user account management, access provisioning, and software installations/configurations.
Monitoring & Alerting: Proactive response to alerts generated by monitoring systems.
Personnel: A team of approximately Off-shore FTE resourcesoffshore full-time equivalent (FTE) resources dedicated to providing 24/7 coverage.
Software Development & Maintenance
Bug Fixing: Diagnosis and resolution of software defects and errors in Client’s applications.
Enhancements/Upgrades: Implementation of feature requests and upgrades to existing software components (scope to be defined per request/mini-SOW), including upgrade to support Upgrade network.
IT Administration
User Management: Creation, modification, and deletion of user accounts and permissions across various systems (e.g., User management examples, specific application user management).
Access Management: Configuration and maintenance of access control policies.
System Configuration: Assistance with configuring and deploying new software or system components.
Documentation: Maintenance of IT infrastructure documentation, runbooks, and procedural guides.
Vendor Coordination: Liaising with third-party software vendors or service providers for support or technical issues.
Personnel: IT administrator personnel part-time IT Administrator(s), equivalent to approximately IT administration hours hours per month.
Account Management
Single Point of Contact: A dedicated Account Manager for strategic oversight, relationship management, and escalation.
Regular Reviews: Monthly or quarterly review meetings to discuss service performance, new requirements, and strategic alignment.
Reporting: Provision of monthly service reports detailing activities, performance metrics, and recommendations.
Disclaimer: The original creator, the author of this template, and fynk GmbH are not responsible for any damages or liabilities that may result from using this template. This template should not be considered a substitute for legal advice, and consulting with a legal professional is recommended before use. fynk GmbH, the original creator, and the author do not provide legal advice and will not be held accountable for any legal consequences arising from its use.
More than1.000 teamschose fynk to outgrow legal chaos.
What a service level agreement covers and how to use this template
Learn what a service level agreement is, how uptime guarantees and service credits are structured, how incident severity tiers drive response and resolution time commitments, and how to customize this template for your IT service arrangement.
Use this template if:
You’re an IT managed services provider or SaaS vendor documenting performance commitments separately from the master service contract, so operational targets can be updated without renegotiating the full agreement
Uptime guarantees, response times, and service credit calculations need to be specific and measurable, not vague best-effort language
Incident severity tiers need to be defined before an outage happens, with agreed response and resolution windows for each
Service credits for missed SLA targets should trigger automatically on the next invoice, not require the customer to file a claim
The service scope spans multiple delivery areas (infrastructure, support, software development, IT administration) and each needs its own performance targets
What is a service level agreement?
A service level agreement is a formal commitment between a service provider and a customer that quantifies the performance the customer is entitled to receive and specifies what happens when the provider falls short. According to the NIST Computer Security Resource Center, an SLA “addresses specific aspects of the service, such as responsibilities, details on the type of service, expected performance level, and requirements for reporting, resolution, and termination.”
An SLA isn’t a standalone contract. It attaches to an underlying services agreement (a master service agreement, managed IT contract, or similar) and governs operational performance within that relationship. The SLA can be updated as service requirements evolve without reopening the master agreement.
Three things distinguish an SLA from a general warranty or service description:
Quantified targets: commitments are expressed as measurable numbers (99.9% uptime, 4-hour resolution for critical incidents) rather than qualitative language like “reasonable efforts”
Automatic remedies: service credits trigger when targets are missed, without the customer having to prove damages or initiate a claim
Continuous measurement: performance is tracked on an ongoing basis with regular reporting, not just assessed at the end of the contract
Common contexts include:
IT managed services: a managed service provider (MSP) commits to infrastructure availability, helpdesk response times, and software maintenance windows for a business client
Cloud and SaaS: a cloud provider documents uptime SLAs, incident response procedures, and support tier commitments for enterprise customers
Outsourced IT operations: an organization outsources network administration, security monitoring, and software support to a third-party provider under a multi-year agreement
Internal IT service desks: a corporate IT department publishes an SLA to internal business units setting response time expectations for ticket resolution
Key provisions in a service level agreement
1. General principles and responsibilities
The opening section establishes the operational framework before any specific targets are set:
Scope limitation: the SLA applies only to the services explicitly covered in the attached scope schedule. Services not listed in the schedule are outside the SLA’s commitments, preventing scope creep from eroding guaranteed service levels.
Time zone: all response and resolution time commitments run against a specified SLA time zone, so there’s no ambiguity about when a clock starts for a global service team.
Exclusions: the categories of events that don’t count against the provider’s SLA performance. This template excludes incidents arising from the client’s own actions, third-party vendor issues outside the provider’s control, and force majeure events. Vague exclusion clauses are the most contested part of any SLA dispute. Exclusions must be specific and pre-agreed to be enforceable.
The provider’s representations and warranties about its service capabilities are documented in the master service agreement; the SLA’s targets are the measurable expression of those commitments.
2. Incident response and resolution times
The incident management framework defines how problems are classified and how quickly they must be addressed:
Severity tiers: incidents are classified into four tiers based on business impact. Severity 1 (critical) means a critical business function or system is completely down with high user impact. Severity 2 means significant service degradation with some user impact. Severity 3 means minor degradation or an isolated issue with low impact. Severity 4 covers general inquiries, non-critical issues, and feature requests. Each tier carries separate response and resolution time commitments.
Response time: the maximum time from incident report to the provider’s initial acknowledgement. Commitments are expressed in minutes for Severity 1 and 2 incidents and in hours for Severity 3 and 4.
Resolution time: the maximum time to resolve the issue or have a workaround in place. The template defines “resolution” as the issue being fully resolved, a workaround in place, or a clear plan for definitive resolution communicated to the client.
Business hours for lower-severity work: resolution of Severity 3 and 4 issues, and non-critical development tasks, occurs primarily during the offshore support team’s standard business hours, even though support coverage itself is 24/7.
Uptime commitments are the most visible SLA metric and the one customers negotiate hardest:
Availability percentage: the provider commits to a specified uptime percentage for the client’s primary cloud services instances under its management, excluding scheduled maintenance. The template defines “Availability” as the ability to log in and perform operations on the platform.
Unavailability threshold: “Unavailable” is defined as each full 5-minute increment during which the platform has no functionality. Partial degradation doesn’t count; the platform must be completely non-functional for a period to count against the uptime guarantee.
Scheduled maintenance: planned downtime requires the provider to give the client advance notice of at least the agreed number of hours before any maintenance that may impact availability. Maintenance is scheduled during periods of lowest anticipated impact to the client’s operations.
Stop relying on memory for deadlines that cost money.
Service credits are the primary financial remedy when the provider misses a target:
Per-incident credit formula: the template specifies a credit percentage of the monthly service fee for each occurrence of a missed resolution time target. Severity 1 and Severity 2 resolution misses each carry their own credit percentage, set by the parties.
Uptime credit formula: if availability drops below the agreed uptime threshold, a separate credit percentage of the monthly service fee applies. The threshold and credit percentage are configurable fields.
Monthly credit cap: the total credits claimable in any single calendar month are capped at a maximum percentage of that month’s service fee. Without a cap, a severe outage month could theoretically offset the entire invoice.
Credit application: service credits are applied against the subsequent month’s invoice automatically, rather than requiring the client to file a separate claim. Indemnity for consequential losses beyond the credit cap is typically addressed in the master service agreement’s liability provisions.
5. Performance reporting
Reporting converts operational data into the evidence base for SLA compliance:
Report content: each monthly report covers a summary of critical incidents (Severity 1 and 2) reported and resolved in the previous month, plus notable system improvements, configuration changes, and optimisations implemented. The report is delivered by an agreed business day of each month.
Reporting frequency: monthly. The template states that no additional reporting is required unless mutually agreed in writing, so ad hoc reporting requests outside that cadence need a written amendment.
Report delivery deadline: the provider delivers the report by a specified business day each month. The deadline is a configurable field in the template.
Using digital contract management to store each monthly report alongside the SLA creates a clean evidentiary record if a service credit dispute needs to be resolved.
6. Review and adjustment
SLAs need to evolve as the service environment changes:
Annual review: this SLA is reviewed and adjusted annually by mutual written agreement of both parties. Adjustments reflect changes in the client’s requirements, technology, or market conditions.
Written agreement required: changes to the SLA targets, service scope, or credit formula take effect only when both parties agree in writing. Oral waivers of SLA targets aren’t enforceable.
Term and termination: the SLA’s term and termination follows the underlying service agreement; specify whether performance obligations and credit accrual continue through any transition or wind-down period.
Who needs a service level agreement?
IT teams defining the performance commitments their department or external provider must meet and tracking compliance against those commitments
Legal teams structuring the credit mechanism, exclusions, governing law and jurisdiction, and limitation of liability provisions so the SLA works as a standalone enforceable document
Procurement teams negotiating uptime targets, response time windows, and credit caps with managed service providers and cloud vendors
Operations teams managing day-to-day service delivery, incident classification, and escalation procedures under the SLA
Finance teams tracking service credit accrual, applying credits to invoices, and modeling the cost impact of SLA miss scenarios
How to customize this template
Set uptime targets based on the actual criticality of the services being covered. A 99.9% target is standard for non-critical systems; production environments supporting revenue-generating operations typically warrant 99.95% or higher. Don’t agree targets the provider can’t meet: the credit mechanism only works if the target is genuinely achievable.
Define the severity tiers with concrete examples of what qualifies as each level. “Production system completely unavailable” is unambiguous; “significant impact to operations” isn’t. Both parties should be able to classify an incident independently and reach the same answer.
Agree the measurement methodology before finalizing the availability percentage. Who runs the monitoring? What constitutes a monitoring failure vs. a service failure? If the provider’s own monitoring system is the only evidence of uptime, the customer has no independent check.
Set the credit cap at a level that represents a real incentive for the provider without creating unlimited exposure. A 30% monthly credit cap is common; higher caps are sometimes agreed for mission-critical services but require corresponding pricing adjustments.
Specify the scheduled maintenance window in the SLA and the advance notice period required. Emergency maintenance (unplanned patching for a security vulnerability) needs a shorter notice window with a separate procedure.
Align the review cadence with the volatility of the service environment. If the scope of services changes frequently, quarterly reviews prevent the SLA from becoming obsolete. Annual reviews are sufficient for stable, commodity services.
For the underlying contract governing the service relationship, see:
This service level agreement template is ready to customize in fynk. Set the uptime targets, severity tier definitions, response and resolution time windows, and credit formula for your service arrangement, then send for signature.
With fynk, you can:
Review uptime guarantees, service credit calculations, and exclusion clauses using AI review, flagging ambiguous measurement methodology and credit cap provisions before the SLA is signed.
Track SLA compliance, uptime percentages, incident counts, and credit accrual across your service portfolio using dashboards, giving your IT and finance teams a live view of service performance against committed targets.
Populate uptime targets, response and resolution time windows, credit percentages, and service fee amounts using dynamic fields, so every figure is consistent across the SLA body, Schedule A, and any credit claim forms.
Set reminders for monthly report deadlines, quarterly review meetings, and SLA renewal notice dates using tasks and reminders, so operational obligations never slip because a calendar date was missed.
FAQs
A service level agreement (SLA) is a formal commitment between a service provider and customer that quantifies performance expectations and specifies what happens when they're not met. It expresses commitments as measurable targets (uptime percentages, response times, resolution windows) and provides automatic remedies (service credits) when those targets are missed. An SLA attaches to an underlying services contract and governs operational performance within that relationship. It can be updated as service requirements change without reopening the master agreement.
A master service agreement (MSA) establishes the commercial and legal framework of the service relationship: payment terms, IP ownership, liability caps, termination rights, and governing law. An SLA defines the operational performance standards within that relationship: uptime guarantees, response times, and credit remedies. The MSA governs what happens if the relationship breaks down; the SLA governs day-to-day service delivery. Most managed IT relationships use both documents, with the SLA incorporated by reference into the MSA and updated more frequently as the service environment evolves.
Service credits are typically calculated as a percentage of the monthly service fee for each percentage point of availability below the guaranteed level. For example, a provider guaranteeing 99.9% uptime might credit 10% of the monthly fee if availability drops to 99%-99.9%, and 25% if availability drops below 99%. The SLA also sets a credit cap (typically 30-50% of the monthly fee) limiting the total credit in any billing period, and specifies whether credits are applied automatically on the next invoice or require the customer to submit a claim.
Standard SLA exclusions include: scheduled maintenance windows where advance notice was given, customer-caused incidents (the customer's own actions caused the outage), failures of third-party systems outside the provider's control (internet service providers, upstream DNS, third-party APIs), and force majeure events. The exclusions must be specific and pre-agreed: vague language like 'events outside our control' is commonly disputed. If a monitoring system failure coincides with a service outage, the SLA should specify which party's monitoring data is authoritative.
Most managed IT SLAs include a formal review cadence, typically quarterly or annually, where both parties assess whether the targets still reflect the current service environment. Reviews are triggered earlier if the service scope changes materially, if a new system is added to the SLA's scope, or if the provider consistently misses or consistently exceeds targets (both indicate the targets are miscalibrated). Changes agreed at a review are documented in a signed amendment to the SLA; oral agreements to waive targets aren't enforceable.
Searching for a contract management solution?
Find out how fynk can help you close deals faster and simplify your eSigning process – request a demo to see it in action.
