# SaaS SLA Template for Startups (Free, Fill-in) > A free fill-in SaaS SLA template for small startups: uptime targets, downtime math, service credits, exclusions, and real SLAs from AWS, Google and GitHub. - Canonical: https://zeroraised.com/blog/saas-sla-template - Published: 2026-11-12T13:30:00Z - Author: ZeroRaised Team (https://zeroraised.com/blog/authors/zeroraised) - Publisher: ZeroRaised (https://zeroraised.com/) - Section: Building - Tags: saas, legal, templates, b2b **Short answer:** When a customer asks "what's your SLA?", offer 99.9% monthly uptime on a paid plan, measured by an outside monitor, with capped service credits as the sole remedy and a 30-day claim window. That matches what [Google Workspace](https://workspace.google.com/terms/sla/) and [GitHub](https://github.com/customer-terms/github-online-services-sla) publish, and a small team can keep it. Uptime figures and credit tiers come from each vendor's own SLA page, checked 12 Nov 2026. The template, arithmetic and advice are ours. ## TL;DR - **SLA vs SLO:** an SLA has consequences for missing the target; an SLO does not ([Google SRE book](https://sre.google/sre-book/service-level-objectives/)). - **The math:** 99.9% allows 43.2 minutes of downtime per 30-day month; 99.99% allows 4.32. - **Benchmarks:** Google Workspace and GitHub commit to 99.9%. AWS EC2 commits to 99.99% across two or more Availability Zones, 99.5% for a single instance ([AWS](https://aws.amazon.com/compute/sla/)). - **Upstream limit:** Supabase's uptime SLA covers Enterprise customers only ([Supabase](https://supabase.com/sla)). - **Template:** a full fill-in SLA is below. **Disclosure:** ZeroRaised is a launch site for bootstrapped products with no commercial relationship with any vendor named here. This is not legal advice. ## SLA vs SLO vs terms of service **SLO (service level objective).** The [Google SRE book](https://sre.google/sre-book/service-level-objectives/) defines it as "a target value or range of values for a service level that is measured by an SLI", where the SLI is "a carefully defined quantitative measure of some aspect of the level of service that is provided." **SLA (service level agreement).** The same chapter calls SLAs "an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain." Its test: "An easy way to tell the difference between an SLO and an SLA is to ask "what happens if the SLOs aren't met?": if there is no explicit consequence, then you are almost certainly looking at an SLO." **Terms of service.** Your ToS covers the whole relationship: acceptable use, payment, liability caps, termination. The SLA is a narrow attachment with one measurable promise and one remedy. Our guide on [how to write terms of service for a SaaS](https://zeroraised.com/blog/how-to-write-terms-of-service-for-a-saas) covers the rest; the template below assumes the liability cap lives there. Our read: run an internal SLO stricter than your public SLA (say 99.95% behind a 99.9% promise) so you get warned before you owe anyone a credit. ## The downtime arithmetic The formula is simple: **Allowed downtime = (1 - uptime %) x minutes in the period** A 30-day month has 43,200 minutes (30 x 24 x 60). A 365-day year has 525,600 minutes. Our arithmetic: | Uptime | Downtime per 30-day month | Downtime per year | |---|---|---| | 99% | 432 min (7h 12m) | 5,256 min (3d 15h 36m) | | 99.5% | 216 min (3h 36m) | 2,628 min (1d 19h 48m) | | 99.9% | 43.2 min | 525.6 min (about 8h 46m) | | 99.95% | 21.6 min | 262.8 min (about 4h 23m) | | 99.99% | 4.32 min (about 4m 19s) | 52.56 min (about 53m) | Our read: four minutes a month (99.99%) is less than one bad deploy plus a rollback. If you are asleep when the alert fires, you have already missed it. ## What real SLAs promise Published commitments checked today, useful as anchors when procurement pushes for more: | Provider | Uptime commitment | Credit tiers | Claim window and cap | |---|---|---|---| | [Google Workspace](https://workspace.google.com/terms/sla/) | "at least 99.9% in any calendar month" | Days of service added: 3 days (< 99.9% to >= 99.0%), 7 days (< 99.0% to >= 95.0%), 15 days (< 95.0%) | Support case "within thirty days"; capped at fifteen days of service | | [GitHub](https://github.com/customer-terms/github-online-services-sla) (Actions, Enterprise Cloud, Packages) | "at least 99.9% Uptime" | 5% (99.5% to < 99.9%), 10% (99.0% to < 99.5%), 25% (< 99.0%) of fees | Written request within 30 days of the end of the period; max 90 days of paid service per quarter | | [AWS EC2, Region-level](https://aws.amazon.com/compute/sla/) | "at least 99.99%" across two or more AZs | 10% (< 99.99% to >= 99.0%), 30% (< 99.0% to >= 95.0%), 100% (< 95.0%) | By "the end of the second billing cycle" after the incident | | [AWS EC2, Instance-level](https://aws.amazon.com/compute/sla/) | "at least 99.5%" | 10% (< 99.5% to >= 99.0%), 30% (< 99.0% to >= 95.0%), 100% (< 95.0%) | Same as above | | [Amazon S3 Standard](https://aws.amazon.com/s3/sla/) | Credits start below 99.9% | 10% (< 99.9% to >= 99.0%), 25% (< 99.0% to >= 95.0%), 100% (< 95.0%) | Case in AWS Support Center with "SLA Credit Request" in the subject | | [Supabase](https://supabase.com/sla) (Enterprise) | "at least ninety-nine and nine tenths percent (99.9%)" each calendar month | 10%, 15%, 20%, 30% at 99.9%, 99.0%, 98.0%, 96.0% thresholds | Total credits capped at 20% of fees paid in the preceding 12 months | 99.9% is the common public number, and every one of them limits the downside: credits not cash, a claim deadline, a cap. GitHub states that "Service Credits are the sole and exclusive remedy", and Supabase says credits "are not refunds, cannot be exchanged into cash, and may only be applied to future billing charges." Not everyone publishes a number. Slack's page says Salesforce "uses commercially reasonable efforts to make the online Slack Services available 24 hours a day, 7 days a week" ([Slack SLA](https://slack.com/terms/service-level-agreement)). That wording is a legitimate answer for customers who do not need a numeric SLA. ## You can't promise more than your upstream Your uptime is capped by the services you run on. If your host gives no SLA on your plan, that risk is yours. - **Supabase:** each product "is individually covered by a 99.9% uptime commitment for customers with an Enterprise tier subscription." The [pricing page](https://supabase.com/pricing) shows "Uptime SLAs" not included on Free, Pro and Team. - **Vercel:** the [pricing page](https://vercel.com/pricing) mentions "platform SLAs" only for Enterprise. - **AWS EC2:** 99.99% needs two or more Availability Zones; a single instance gets 99.5%. Our read: on a single EC2 instance (upstream 99.5%) plus a database plan with no SLA, promising 99.9% means underwriting the gap with your own credits. Promise 99.5%, upgrade the upstream, or exclude third-party outages, and remember that customers will not care whose fault a two-hour outage was. ## When to offer an SLA (and when to say no) Our read: offer one when the customer is on an annual or higher-priced plan, their procurement team requires it, and you already measure uptime from outside your infrastructure. Gate it to your top tier or annual plans, as Supabase does with Enterprise; it also gives a reason to upgrade. Say no, or point to "commercially reasonable efforts", when the customer is on a cheap monthly plan (the credit is a few dollars, the paperwork is the same), when you cannot measure uptime yet, or when they want 99.99%, uncapped credits, cash refunds or consequential damages. Those terms can turn one bad night into a loss larger than the contract. ## How to measure and report it cheaply 1. **An outside monitor** checking a health endpoint every minute from more than one region, since your server cannot report its own downtime. Our [free uptime monitoring roundup](https://zeroraised.com/blog/free-uptime-monitoring) compares free tiers. 2. **A public status page** recording incident start and end times: your evidence in a credit dispute. See our guide to [SaaS status pages](https://zeroraised.com/blog/saas-status-page). 3. **A monthly uptime number** per service, using the template's formula, kept for at least the claim window. Define "down" mechanically, for example two consecutive failed checks from two regions. ## The SaaS SLA template Replace everything in [brackets] and delete what you do not need. This is our starting point, not legal advice: have a lawyer review it before attaching it to your terms or order form. ```text SERVICE LEVEL AGREEMENT This Service Level Agreement ("SLA") forms part of the agreement between [Company Legal Name] ("we", "us") and the customer named in the Order Form ("Customer") for the [Product Name] service (the "Service"). It applies only to Customers on the [Plan Name(s)] plan(s) with paid, undisputed invoices. 1. DEFINITIONS "Monthly Uptime Percentage" means (Total Minutes - Downtime Minutes) / Total Minutes x 100, measured over a calendar month, not counting anything excluded under section 4. "Downtime" means a period of at least [2] consecutive minutes in which the Service's [web application / API at https://api.example.com/health] fails to respond successfully, as measured by our external monitoring from at least [2] geographic locations. "Service Credit" means a percentage of the monthly fee for the affected Service, applied to a future invoice. 2. UPTIME COMMITMENT We will use commercially reasonable efforts to make the Service available with a Monthly Uptime Percentage of at least [99.9]%. 3. MEASUREMENT Uptime is measured by [Monitoring Provider] at intervals of [1] minute. Our measurement and the incident history on [status page URL] are the authoritative record. Customer may request the monthly uptime report for any month in the preceding [3] months. 4. EXCLUSIONS Downtime does not include unavailability caused by: (a) Scheduled Maintenance (section 5); (b) Customer's systems, network, or use of the Service in breach of the agreement; (c) suspension of the Service under the agreement; (d) failures of the public internet or of third-party providers outside our reasonable control, including [hosting provider / DNS provider]; (e) force majeure events; (f) features labelled alpha, beta, preview or free; (g) slow performance or latency where the Service still responds. 5. SCHEDULED MAINTENANCE Up to [4] hours per month, with at least [48] hours' notice on our status page, scheduled where possible between [22:00 and 06:00 UTC]. 6. SUPPORT RESPONSE TIMES (targets only, no Service Credits) Contact [support@example.com], [09:00 to 17:00 UTC, Monday to Friday]. Severity 1 (Service down for all users): [4] hours, any time Severity 2 (major feature impaired): [1] business day Severity 3 (minor issue or question): [2] business days 7. SERVICE CREDITS If the Monthly Uptime Percentage falls below the commitment, Customer is eligible for the following Service Credit: Below [99.9]% but at or above [99.0]%: [10]% of monthly fee Below [99.0]% but at or above [95.0]%: [25]% of monthly fee Below [95.0]%: [50]% of monthly fee For annual plans, the monthly fee is the annual fee divided by 12. 8. CLAIM PROCESS To receive a Service Credit, Customer must email [billing@example.com] with the subject "SLA Credit Request" within [30] days after the end of the affected month, including the dates and times of the Downtime. We will confirm or decline the claim within [15] business days. Credits are applied to the next invoice and are not refundable or exchangeable for cash. 9. CREDIT CAP Total Service Credits for any calendar month will not exceed [50]% of the monthly fee for that month. 10. SOLE REMEDY Service Credits are Customer's sole and exclusive remedy for any failure to meet the uptime commitment in this SLA. 11. CHRONIC FAILURE If the Monthly Uptime Percentage is below [99.0]% in [3] consecutive months, or in any [4] months in a rolling 12-month period, Customer may terminate the affected subscription by written notice within [30] days and receive a pro-rata refund of prepaid fees for the unused term. This is in place of, not in addition to, Service Credits for those months. ``` Notes on the choices, all ours: - **A 50% cap.** It keeps a disastrous month survivable. Our tiers sit between GitHub's (5% to 25%) and AWS S3's (10% to 100%). - **Latency excluded.** GitHub likewise excludes "rate limits, performance degradation, or other latency issues without actual service unavailability." - **Support times without credits.** Buyers like response targets; tying credits to them is how solo founders pay for a slow Saturday reply. - **Chronic failure exit.** Procurement often asks for a way out if you are repeatedly down. Offering one with a high bar usually ends the negotiation faster than refusing. ## A worked example Illustrative numbers, ours. A customer pays $400 per month on your Business plan. In March (31 days, 44,640 minutes) you have one 75-minute outage and nothing excluded. - Uptime = (44,640 - 75) / 44,640 x 100 = 99.83% - That is below 99.9% and above 99.0%, so the credit is 10%: **$40** off the next invoice. - If instead you had an 8-hour outage (480 minutes), uptime is 98.92%, the 25% tier: **$100**. Still under the 50% cap of $200. Compare that with an uncapped "refund all fees" clause and you see why the cap matters. ## Frequently asked questions ### What uptime should a small SaaS promise in its SLA? Our read: 99.9% per calendar month for most small SaaS products. It allows 43.2 minutes of downtime in a 30-day month, matches what Google Workspace and GitHub publish, and is achievable on mainstream hosting. Go to 99.5% if you run on a single server or a host that gives you no SLA at all. ### Is an SLA the same as terms of service? No. Your terms of service cover the whole relationship: acceptable use, payment, liability and termination. An SLA is a narrower document, usually attached to the terms or an order form, that sets a measurable service target and the consequence, usually a service credit, if you miss it. ### What is the difference between an SLA and an SLO? Google's SRE book defines an SLO as a target value for a service level measured by an indicator, and an SLA as a contract with consequences for meeting or missing those SLOs. Its test: ask what happens if the SLO is missed. If there is no explicit consequence, it is an SLO. ### How much service credit should I offer? Published SLAs give a useful range. GitHub gives 5%, 10% or 25% of fees in three tiers, AWS S3 gives 10%, 25% or 100%, and Supabase gives 10% to 30% with a total cap of 20% of fees paid in the previous 12 months. Our template uses 10%, 25% and 50%, capped at 50% of one month's fees. ### Should I offer an SLA on my cheapest plan? Our read: no. Gate it to an annual or higher-priced plan, as Supabase does with Enterprise. Credits on a cheap plan are tiny for the customer but the measurement and reporting work is the same for you, so the SLA belongs where contract size justifies it. ## Launch with your promises in writing Add "SLA available on [plan]" to your [product launch checklist](https://zeroraised.com/blog/product-launch-checklist-for-bootstrapped-makers) so the next buyer who asks gets a link instead of a scramble, then [submit your product](https://zeroraised.com/submit) for free. For more practical guides on selling software without investors, [join the ZeroRaised newsletter](https://zeroraised.com/newsletter). ## Sources - [Google SRE book, Service Level Objectives](https://sre.google/sre-book/service-level-objectives/), last checked 12 Nov 2026 - [Amazon Compute Service Level Agreement](https://aws.amazon.com/compute/sla/), last checked 12 Nov 2026 - [Amazon S3 Service Level Agreement](https://aws.amazon.com/s3/sla/), last checked 12 Nov 2026 - [Google Workspace Service Level Agreement](https://workspace.google.com/terms/sla/), last checked 12 Nov 2026 - [GitHub Online Services SLA](https://github.com/customer-terms/github-online-services-sla), last checked 12 Nov 2026 - [Slack Service Level Agreement](https://slack.com/terms/service-level-agreement), last checked 12 Nov 2026 - [Supabase Enterprise Platform Uptime SLA](https://supabase.com/sla), last checked 12 Nov 2026 - [Supabase pricing](https://supabase.com/pricing), last checked 12 Nov 2026 - [Vercel pricing](https://vercel.com/pricing), last checked 12 Nov 2026 ## Frequently asked questions ### What uptime should a small SaaS promise in its SLA? Our read: 99.9% per calendar month for most small SaaS products. It allows 43.2 minutes of downtime in a 30-day month, matches what Google Workspace and GitHub publish, and is achievable on mainstream hosting. Go to 99.5% if you run on a single server or a host that gives you no SLA at all. ### Is an SLA the same as terms of service? No. Your terms of service cover the whole relationship: acceptable use, payment, liability and termination. An SLA is a narrower document, usually attached to the terms or an order form, that sets a measurable service target and the consequence, usually a service credit, if you miss it. ### What is the difference between an SLA and an SLO? Google's SRE book defines an SLO as a target value for a service level measured by an indicator, and an SLA as a contract with consequences for meeting or missing those SLOs. Its test: ask what happens if the SLO is missed. If there is no explicit consequence, it is an SLO. ### How much service credit should I offer? Published SLAs give a useful range. GitHub gives 5%, 10% or 25% of fees in three tiers, AWS S3 gives 10%, 25% or 100%, and Supabase gives 10% to 30% with a total cap of 20% of fees paid in the previous 12 months. Our template uses 10%, 25% and 50%, capped at 50% of one month's fees. ### Should I offer an SLA on my cheapest plan? Our read: no. Gate it to an annual or higher-priced plan, as Supabase does with Enterprise. Credits on a cheap plan are tiny for the customer but the measurement and reporting work is the same for you, so the SLA belongs where contract size justifies it.