How to claim GitHub Actions service credits in four steps — a practical playbook for SaaS engineering & finance teams

Every quarter, lean SaaS teams leave meaningful money on the table with GitHub Actions. Service credits are contractual, public, and recoverable — but they are also easy to miss during outages, slow to post, and rarely filter up from the engineering on-call into the finance queue. The pattern that closes the gap is unglamorous: confirm the incident meets GitHub’s published SLA, assemble the evidence pack against the cited clause, file once through GitHub Support with the right context, and run the follow-up cadence until the credit lands on the right invoice. This guide walks through that pattern, end to end.

You can run the playbook by hand. You can also wire it into an agent that watches github.statuspage.com for events that match your stack, drafts the case in your Slack for sign-off, and then runs the entire loop while your team sleeps. Either way, the four steps below are the same.

Step 1 — Confirm the incident meets GitHub’s credit policy

GitHub’s published Service Level Agreement defines when credits are owed — not every incident qualifies. Before opening a case, build a clean rubric in your head that maps the outage to a specific capability and credit tier. Skipping this step is the most common reason claims get closed without a credit: the case reads as a generic engineering complaint, not a contractual SLA breach.

Three things must be true at once:

• The impacted capability is on GitHub’s SLA (Actions, Packages, Codespaces, the REST/GraphQL API, Pages) AND your uptime dipped below the GitHub‑defined threshold for that capability during the incident window.
• The incident was on GitHub’s side per github.statuspage.com — not a degraded runner you control, a webhook consumer you own, or a third-party Actions marketplace image that’s outside GitHub’s SLA scope.
• Your GitHub account is in good standing — credits only apply to the billing month of the affected organization, so make sure your invoice and incident are tied to the same account.

Cross‑reference the status page entry — event URL, component, UTC start/end, post‑mortem link — against your own telemetry. Save both; GitHub’s review will start there. If your org audit log or Actions run history shows gaps that don’t appear on github.statuspage.com (rare, but it happens with regional runner degradations), reconcile the gap before filing. GitHub does not chase ambiguity for you.

Step 2 — Assemble the evidence pack

GitHub Support responds fastest to a tidy evidence folder, not a long email. Build the pack before you write the case body so the email stays short and the reviewer doesn’t have to reverse‑engineer your numbers from prose.

A complete pack contains:

• The github.statuspage.com event (event URL, component state, start/end UTC timestamps, GitHub’s post‑mortem link if published).
• Audit log + Actions run history export for the affected workflow, runner pool, or API endpoints over the incident window (request id, status, latency, error class). Export as CSV — not screenshots.
• Your measured GitHub availability for the month, computed the way the SLA defines (typically monthly uptime %, per capability). Show the math on a one‑page summary so the reviewer can re-check it in seconds.
• A timeline of customer impact: delayed CI runs, failed deploys, support tickets, refund/credit issuance, on-call wakeups. Anything that proves real users felt the outage.
• The matching SLA clause: capability name, SLA URL, the credit tier owed, and your invoice month so the reviewer can apply the credit to the right statement.

The case reviewer is reading ten other cases today. If your uptime number is in the first paragraph and the SLA clause is cited by URL in the second, the review goes one way. If they have to hunt, the case gets closed unceremoniously.

Step 3 — File the case through GitHub Support with the right context

Open the case via support.github.com → category “Service availability / SLA.” Plan tier matters here: Enterprise Cloud customers get the dedicated SLA desk with priority routing. If you are on Free/Team/Business, the credit request rides on a standard technical support case; it still routes to the SLA desk, but expect a longer review window.

In the body of the case, lead with what the reviewer needs:

• One sentence: which capability (Actions, Packages, Codespaces, REST/GraphQL API, Pages…), which organization, what your measured monthly uptime was for the window.
• Second sentence: the GitHub SLA clause you are claiming against (URL + the credit tier row from the published schedule).
• Third sentence: the customer‑impact summary — minutes of delayed CI runs, failed deploys, downstream pages — whichever is more concrete for your business.
• Then the evidence pack as attachments, filenames labelled so they read in order (01-status-event.pdf, 02-audit-export.csv, 03-uptime-summary.md, 04-impact-summary.md).
• Close with a single, specific ask: “Apply a <X>% credit to the <month> invoice per the <capability> SLA, tier <Y>.” Vague asks produce vague replies.

A useful shortcut is to stamp a small JSON manifest onto the case so the reviewer can paste the IDs and timestamps into GitHub’s internal tooling without re‑typing:

{
  "capability": "GitHub Actions",
  "region": "us-east-1 runner",
  "slaUrl": "https://docs.github.com/en/site-policy/github-terms/github-sla",
  "slaClause": "API Monthly Uptime ≥ 99.9%",
  "measuredUptimePct": 99.42,
  "creditTierPct": 25,
  "invoiceMonth": "2026-07",
  "statusEventUrl": "https://github.statuspage.com/incidents/<id>",
  "windowUtc": { "start": "2026-07-29T03:11:00Z", "end": "2026-07-29T05:48:00Z" }
}

Step 4 — Run the follow-up cadence until the credit posts

GitHub rarely closes a credit case on the first reply. The cadence that works across hundreds of cases is short, predictable, and polite:

1. Day 3 after the case opens: if there is no acknowledgement, reply once with the evidence pack repeated in‑line and a “gentle bump.” Most reviews move at this point.
2. Day 7: if the reviewer is still asking for the same evidence, escalate per your plan tier — reply “Escalating per Enterprise Cloud SLA tier,” attach the original message ID, and request your account manager touchpoint if you have one.
3. Day 14: if the case is still open without a clear credit decision, request the credit determination in writing. Reply with a one‑line summary of where the review stands, including any reviewer objections, and ask for the credit calculation shown line by line.
4. Day 30: if the credit has been approved but not posted, follow up with a reference to the determination and ask for the invoice‑on‑which‑it‑lands date. GitHub Billing needs that nudge.

Track every case in a single ledger — case ID, capability, claim amount, status, last contact, next action. The ledger is what makes the recovery loop auditable for finance and transparent for engineering. Most teams do this in a shared spreadsheet; a few have moved it into a queue that the ops agent owns end‑to‑end.

Closing notes

The four steps are the same whether you file one case a year or one a week. The lift is small — most credit‑bearing GitHub incidents at a typical SaaS company resolve into a four‑to‑five‑figure recovery over a quarter — but the lift is per‑incident, every incident, all year. The teams that get the money are the ones that turn it into a queue the finance lead owns, with a vocabulary (one rubric, one evidence folder shape, one cadence) that everyone can run without re‑deriving it.

Recoupfox is built to be that queue. It watches github.statuspage.com for events that match your stack, drafts the case with the rubric and evidence baked in, queues it to your Slack for sign‑off, and then runs the cadence for you until the credit posts. If you would rather a vigilant agent handle the loop, get a Recoupfox for your stack.