Developer Tools
GitHub SLA credit guide
What GitHub owes you when it misses its uptime commitment — its published tariff (5%, 10% or 25% of a quarter's fees), the quarter-end filing deadline and how to file. The unit is the calendar quarter, so no amount is computed here from a single month.
What SLA credit are you owed when GitHub is down?
GitHub Enterprise Cloud (all services) carries a 99.9% quarterly uptime commitment, and GitHub does pay a service credit for missing it. Its tariff is published and it is assessed on the CALENDAR QUARTER: 5%, 10% or 25% of that quarter's fees, depending how far the Quarterly Uptime Percentage fell. Ontracko measures calendar months, and three of them aggregate into that one quarterly figure, so a single bad month establishes no breach on its own: this page quotes no percentage against one month, no dollar amount and no calculator, because a figure priced off a month against a quarterly tariff can be out by a factor of three. File within 30 days of the end of the affected calendar quarter. Ontracko does that arithmetic for you once GitHub is connected: it scores all three calendar months, sums their downtime over the quarter's own minutes to get the Quarterly Uptime Percentage, reads the band off GitHub's published table and drafts the claim with the figure in it — and while a month of the quarter is still unscored it drafts protectively, stating no figure at all. Monitoring, incident timing and the dated evidence a claim is built on are free either way.
Full GitHub claim guide · What is an SLA credit? · SLA glossary
Uptime commitment
99.9%
Filing window
30 days
counted from the end of the affected calendar quarter
Services with SLA data
1
GitHub’s credit is assessed on the calendar quarter
GitHub publishes its tariff and applies it to the Quarterly Uptime Percentage — the availability of the whole quarter — and calculates the credit against the fees for that quarter. Three calendar months aggregate into that single figure, so one bad month establishes no breach on its own. This is the published table:
| Quarterly Uptime Percentage | Credit (% of that quarter's fees) |
|---|---|
| 99.5% – under 99.9% | 5% |
| 99% – under 99.5% | 10% |
| below 99% | 25% |
Transcribed from GitHub’s own SLA (primary source ↗). The claim is due within 30 days of the end of the affected calendar quarter — read that anchor carefully, because a reader who counts the window from the incident date instead will believe a claim that is still live has already expired.
What this page does not do is put a number on it. It holds no spend figure for you and no scored months, so applying the table above to anything here would be a guess with a percentage sign on it — which is why there is no calculator on this page. Ontracko does that arithmetic for you once GitHub is connected: it scores all three calendar months, sums their downtime over the quarter's own minutes to get the Quarterly Uptime Percentage, reads the band off GitHub's published table and drafts the claim with the figure in it — and while a month of the quarter is still unscored it drafts protectively, stating no figure at all.
Credit tiers by service
GitHub Enterprise Cloud (all services)’s credit tariff is published, and it is assessed on the calendar quarter: 5%, 10% or 25% of that quarter's fees, depending how far the Quarterly Uptime Percentage fell — the table is above. Ontracko measures calendar months and three of them aggregate into that one quarterly figure, so a single month indexes no band here and this page computes no amount from one. A VERIFIED PAYER WHOSE TARIFF IS QUARTERLY, SO NO AMOUNT IS EVER PRICED OFF A SINGLE MONTH — the three months of the quarter are aggregated into one Quarterly Uptime Percentage first, and until all three are scored no figure is stated at all. GitHub's SLA is assessed on the CALENDAR QUARTER: the credit is applied to the Quarterly Uptime Percentage and calculated against the fees for that QUARTER, at 5% below 99.9% down to 99.5%, 10% below 99.5% down to 99%, and 25% below 99%. Three calendar months average into that one figure, so a single bad month establishes nothing on its own — pricing that table off one month's uptime and one month's spend can be wrong by roughly three times — and the profile therefore carries NO MONTHLY credit tiers at all; the table above is indexed on the quarter and is applied only once all three of its months have been scored. The filing guide carries the full table. THE DEADLINE IS 30 DAYS AFTER THE END OF THE QUARTER in which the breach occurred, not 30 days after the incident. THE CAP IS NOT A PERCENTAGE: credits are capped at approximately 90 days of paid service per quarter. SCOPE IS NARROW: GitHub Enterprise Cloud (including Actions and Packages) ONLY — not Free, Pro or Team plans, and not Codespaces; scheduled maintenance and beta/preview features are excluded. Ontracko scores calendar months and sums their downtime over the quarter's own minutes to get the figure this tariff is indexed on — cite the quarter, not the month, when filing.
How to file a GitHub SLA credit claim
Portal: GitHub Support ↗
- ⚠️ THIS SLA IS QUARTERLY: the tariff is applied to the Quarterly Uptime Percentage and calculated against that QUARTER's fees, and three calendar months aggregate into that one figure — so a single bad month establishes no breach on its own, and no figure taken from one month means anything here. Ontracko computes the quarterly figure for you from the three scored months and prices the claim against the published bands; while any month of the quarter is still unscored it states no amount at all and files protectively, so check which quarter this claim covers, and whether it is complete, before quoting anything from it.
- THE FULL TARIFF, as a percentage of the fees for the affected QUARTER: quarterly uptime below 99.9% and at or above 99.5% → 5%; below 99.5% and at or above 99% → 10%; below 99% → 25%. Ontracko indexes this table on the quarterly figure it computed; if you are filing by hand, take the quarter's uptime from section 3, pick the band, and apply it to that quarter's fees for the affected service.
- ⏰ THIRTY DAYS AFTER THE END OF THE QUARTER in which the breach occurred — the window runs from quarter-end, not from the incident. Put the date in the calendar the moment the quarter closes.
- Check the scope first — it is narrow: GitHub ENTERPRISE CLOUD only, including Actions and Packages. Free, Pro and Team plans get nothing, and Codespaces is excluded even on Enterprise.
- Sign in as an organization owner on your GitHub Enterprise Cloud account.
- Open a support ticket → category Billing → mention "SLA service credit claim", and name the quarter you are claiming for in the subject.
- Paste the claim text from section 8, citing the incident links from githubstatus.com in section 3 — and list every incident in the quarter, not only the worst month, because the tariff is indexed on the quarter as a whole.
- THE CAP IS NOT A PERCENTAGE: credits are capped at approximately 90 days of paid service per quarter, so the ceiling is denominated in service time rather than in dollars.
- Excluded: scheduled maintenance, beta and preview features.
Evidence you’ll need
- •Organization name
- •Enterprise plan confirmation
- •Affected quarter
- •Incident timestamps
Common exclusions
- •Scheduled maintenance
- •Beta/preview features
- •Codespaces
- •Non-Enterprise (Free/Pro/Team) plans
Frequently asked
What is GitHub's SLA uptime commitment?
GitHub Enterprise Cloud (all services) carries a 99.9% quarterly uptime commitment.
Does GitHub pay an SLA service credit?
Yes, and its tariff is published. GitHub applies it to the Quarterly Uptime Percentage — the availability of the whole quarter — and credits 5%, 10% or 25% of that quarter's fees, the band depending on how far the quarterly figure fell. Because it is assessed on the CALENDAR QUARTER and not on a single month, this page quotes no percentage against one month and no dollar amount: three calendar months aggregate into that one figure, one bad month establishes no breach on its own, and a credit priced off a month against a quarterly table can be out by a factor of three. The claim is due within 30 days of the end of the affected calendar quarter. Ontracko does that arithmetic for you once GitHub is connected: it scores all three calendar months, sums their downtime over the quarter's own minutes to get the Quarterly Uptime Percentage, reads the band off GitHub's published table and drafts the claim with the figure in it — and while a month of the quarter is still unscored it drafts protectively, stating no figure at all.
What is the deadline to file a GitHub SLA credit claim?
Claims are generally due within 30 days of the end of the affected calendar quarter (verify the exact clause in GitHub's SLA before filing).
Does Ontracko file GitHub SLA credit claims for me?
Ontracko monitors GitHub for free, detects SLA breaches automatically, and assembles the complete claim package (evidence + credit math + claim text). You file it; Ontracko charges 8% only on credits that are actually recovered.
Let Ontracko file it for you
Connect GitHub and Ontracko monitors the SLA, catches every breach, and drafts the claim with the evidence attached. Free — 8% only on recovered credits.