How to claim an SLA credit from GitHub Enterprise Cloud
GitHub Enterprise Cloud owes a service credit when it misses its 99.9% uptime SLA — but the claim window is quarterly, not monthly, and starts after the quarter closes. Here's the credit schedule and how to file.
GitHub Enterprise Cloud carries a real uptime SLA — and a real service credit when it's missed. But unlike most SaaS vendors, GitHub measures the commitment per quarter, not per month, which changes both how you calculate a breach and when you have to file. Here's exactly what you're owed and how to claim it.
The short answer
GitHub's Enterprise Cloud SLA (covering GitHub.com, GitHub Actions, and GitHub Packages) commits to 99.9% uptime, measured over the calendar quarter. Miss that target and you're owed a service credit worth 5%, 10%, or 25% of the affected quarter's fees, tiered by how far uptime fell. You file by opening a support ticket at support.github.com with your organization name, Enterprise plan confirmation, the affected quarter, and the incident timestamps — and you have 30 days after the quarter ends, not after the incident, to do it. Free, Pro, Team plans, and Codespaces are not covered — the SLA is an Enterprise Cloud benefit only.
What GitHub commits to
| Plan | Covered services | Measurement period | Uptime commitment |
|---|---|---|---|
| GitHub Enterprise Cloud | GitHub.com, GitHub Actions, GitHub Packages | Calendar quarter | 99.9% |
Free, Pro, Team, and Enterprise Server (self-hosted) plans carry no uptime SLA. Codespaces and beta/preview features are excluded even on Enterprise Cloud — so an outage there, however disruptive, isn't claimable under this SLA.
What you're owed
Credits are tiered by the quarter's measured uptime and apply against the quarter's Enterprise Cloud fees:
| Measured quarterly uptime | Credit |
|---|---|
| 99.5% – under 99.9% | 5% |
| 99.0% – under 99.5% | 10% |
| below 99.0% | 25% |
Because the window is a full quarter rather than a month, a single bad day can be enough to breach — but it also means one rough day can get diluted by two otherwise-clean months, so the credit tier depends on the whole quarter's arithmetic, not just the worst incident. Model your figure with the GitHub credit calculator: enter your quarterly Enterprise spend and the quarter's measured uptime to get the tier and dollar amount. The cap works out to roughly 90 days of paid service credited back per quarter at the top tier.
The evidence GitHub expects
- Your organization name
- Confirmation you're on an Enterprise Cloud plan (not Free/Pro/Team, and not self-hosted Enterprise Server)
- The affected quarter
- The incident timestamps for each outage you're citing
Corroborate the outage against the incident record on the GitHub status page.
How to claim a GitHub SLA credit
- Track incidents affecting GitHub.com, Actions, or Packages as they happen during the quarter, noting the start and end times from the GitHub status page.
- After the quarter closes, measure the affected service's uptime for that full quarter and match it to the 5% / 10% / 25% tier.
- Open a support request at support.github.com describing the claim as an SLA service credit request.
- Include your organization name, Enterprise Cloud plan confirmation, the affected quarter, and every incident's timestamps.
- Submit within 30 days of the quarter's end — an approved credit is applied to a future invoice, not refunded as cash.
Watch the deadline — it's quarterly, not monthly
This is the detail that trips people up: GitHub's clock starts at the end of the quarter, not the end of the month or the date of the incident. An outage in January is measured as part of Q1 (January–March), and you don't file until Q1 closes — then you have 30 days from March 31 to submit. Wait for month-end thinking you've missed it, or file too early before the full quarter's uptime is known, and you either forfeit the credit or file with an incomplete number. It's a longer runway than Atlassian's 15-day window, but also a slower one — you can't file the day after an outage even if you want to.
Frequently asked questions
Does GitHub give credits for Actions or Packages downtime?
Yes, if you're on Enterprise Cloud. GitHub.com, GitHub Actions, and GitHub Packages are all covered under the same 99.9% quarterly SLA, so an outage in any of the three counts toward the same measurement. Free, Pro, and Team plans have no SLA at all.
How long do I have to claim a GitHub SLA credit?
30 days after the calendar quarter ends — not 30 days after the incident. A Q1 outage (January–March) must be claimed by April 30. This is quarterly, unlike most SaaS vendors' monthly windows.
How much is a GitHub SLA credit worth?
5% of the quarter's Enterprise Cloud fees for uptime between 99.5–99.9%, 10% between 99.0–99.5%, and 25% below 99.0%. Use the GitHub SLA guide to estimate your amount from your own spend.
Does GitHub Enterprise Server (self-hosted) have an SLA credit?
No. The SLA and credit remedy apply only to GitHub Enterprise Cloud. Self-hosted Enterprise Server has no vendor-side uptime commitment to claim against, since GitHub isn't running the infrastructure.
Are Codespaces outages covered?
No. Codespaces and other beta/preview features are explicitly excluded from the Enterprise Cloud SLA, even though the core plan is covered.
Methodology & caveats
The uptime commitment, quarterly measurement period, credit tiers, 30-day post-quarter window, and coverage exclusions above are transcribed from GitHub's published Enterprise Cloud SLA into Ontracko's profile; verify the exact clause and your order form before filing, since terms can change. Live GitHub incident history is on its status page. For how GitHub compares to other vendors, see which SaaS vendors actually pay SLA credits, or start with what an SLA credit is and the SLA glossary.
*Ontracko monitors GitHub's public status feed, tracks quarterly uptime, and assembles the claim before the post-quarter window closes. Monitor GitHub free — 8% only on recovered credits. See GitHub live status or the GitHub SLA calculator.*
Related reading
How to claim an SLA credit from MongoDB Atlas (99.995% uptime)
MongoDB Atlas commits to 99.995% uptime on M10+ dedicated clusters — about two minutes of allowed downtime a month. Miss it and you're owed 10% to 100% of that cluster's fee, but only if you log a ticket within 24 hours. Here's the credit table and the two-stage claim.
What does a 99.9% SLA actually allow? Uptime, downtime, and your credit
A 99.9% SLA allows about 43 minutes of downtime a month; 99.99% allows about 4. Here's the full uptime-to-downtime cheat sheet, when downtime becomes a breach, and how to calculate the SLA credit you're owed.
How to claim an SLA credit from Microsoft Azure
Azure owes you a service credit when Virtual Machines, SQL Database, App Service and other resources miss their SLA. Here's the exact credit schedule, the deadline, the evidence you need, and how to file the support request.
How to claim an SLA credit from Atlassian (Jira, Confluence, Bitbucket)
Atlassian Premium and Enterprise owe a service credit when Jira, Confluence, or Bitbucket miss their uptime SLA — but you have only until the 15th of the next month to file. Here's the credit schedule and how to claim.
Or browse the SLA glossary and the reliability rankings.
Stop leaving SLA credits on the table
Ontracko monitors your vendors, catches every SLA breach, and drafts the claim. Free — 8% only on recovered credits.
Start monitoring free