From Outage Alert to SLA Claim: Following a GitHub Actions Incident Through the Full Credit Cycle

The alert

On August 6, SLA Credit Watch detected a critical GitHub incident and published an incident page while the disruption was still underway:

GitHub Actions outage — SLA Credit Watch

GitHub's public status record showed that Actions workflows were failing or delayed, hosted and self-hosted runners were affected, and webhook triggers were being throttled. At one point GitHub reported that only a fraction of queued jobs were succeeding. The incident later moved into monitoring while some runner infrastructure was still recovering.

The public status page was enough to answer the first question: Was there a real vendor-side incident?

It was not enough to answer the more valuable question: Did our organization qualify for an SLA credit?

That distinction is central to SLA Credit Watch. A vendor incident is evidence, but it is not automatically proof that a customer's contract, usage, and technical experience satisfy the SLA.

Step 1: Read the SLA before counting downtime

The intuitive approach would be to take the outage duration—more than seven hours—and compare it with a 99.9% availability commitment.

That would be wrong for GitHub Actions.

Under the GitHub Online Services SLA, Actions uptime is calculated per calendar quarter using executions:

Actions uptime =
  (Total Triggered Executions - Unavailable Executions)
  / Total Triggered Executions
  × 100

GitHub defines an unavailable execution narrowly: an execution whose trigger fired successfully but whose Actions history captured no output five minutes later.

This means the outage clock alone does not establish a claim. We needed to inspect our own workflows.

Step 2: Confirm contractual coverage

Using an authenticated, read-only GitHub CLI session, we verified that:

• our organization is on GitHub Enterprise Cloud;
• the reviewing account is an organization owner;
• the affected workflows ran inside that Enterprise organization; and
• GitHub Actions is an SLA-covered service under the applicable customer terms.

This removed the first major eligibility risk. Simply having many GitHub Actions workflows on a Free or otherwise non-covered account would not have been enough.

Step 3: Find our executions during the outage

We inventoried every accessible repository and queried Actions runs created during the public incident window.

Ten workflow runs appeared during that period:

• four completed successfully; and
• six scheduled monitoring runs failed.

The six failures were unusually consistent. Each one remained present for approximately 15 minutes before GitHub ended it. That pattern warranted a deeper review of the job, step, log, runner, and billing-time metadata.

Step 4: Test the failures against GitHub's definition

For all six affected executions, GitHub's APIs showed:

• the workflow run was successfully created;
• the job requested a standard Linux hosted runner;
• no runner was assigned;
• the job contained zero executed steps;
• the downloadable log archive was empty;
• GitHub reported zero billable runner-compute time;
• the job conclusion was cancelled while the workflow conclusion was failure; and
• the workflow itself did not contain a 15-minute timeout.

Successful executions of the same workflow appeared immediately before and after the affected period.

This was the decisive evidence. These were not ordinary test failures after our code began running. Nothing ran at all.

They closely match the SLA's five-minute/no-output definition of an unavailable execution.

Some scheduled events never produced workflow records while GitHub was throttling triggers. Those missing triggers may not count under the literal SLA formula because GitHub requires a successfully fired trigger. We therefore used only the six executions for which a run record and empty execution history existed.

Step 5: Calculate the preliminary quarterly result

At the time of review, the Enterprise organization had 1,379 Actions executions in the third calendar quarter.

Using only the six strongly supported unavailable executions:

(1,379 - 6) / 1,379 × 100 = 99.565% preliminary uptime

That placed the organization in the 5% service-credit band at that moment.

The result is preliminary because the denominator continues growing until September 30. Six unavailable executions keep the final result below 99.9% only if Q3 ends with fewer than 6,000 total triggered executions. Based on the organization's observed run rate, that appeared plausible, but it cannot be finalized before quarter-end.

Step 6: Check whether the credit has monetary value

Technical eligibility and economic value are different questions.

The organization's Actions usage was still covered by included-minute discounts. The billing records showed usage, but no net metered Actions charge at the time of review.

That creates an important ambiguity: even if the execution ratio qualifies, the immediately identifiable fee base may be zero. GitHub's SLA applies the credit percentage to “Applicable Service Fees,” so the support request asks GitHub to confirm whether that means only net metered Actions charges or whether any portion of the Enterprise Cloud fees is attributable to Actions.

This is a useful reminder that an SLA percentage is not automatically a cash amount. Every claim needs both a qualifying service-level miss and an applicable fee base.

Step 7: File a support ticket with reproducible evidence

We filed a GitHub Support ticket referencing:

• the public incident ID;
• the six affected workflow runs;
• their creation and cancellation timestamps;
• the missing runner assignment;
• the zero-step execution histories;
• the empty log archives;
• the zero compute time;
• the workflow definition showing no customer-configured timeout; and
• the preliminary quarterly calculation.

The support form required one workflow-run URL and a specific error message. There was no conventional error message because the jobs never started, so we described the observable platform result precisely:

No error message was emitted because the job never started. The job was never assigned a runner, produced no steps or log output, and GitHub recorded the job as cancelled and the workflow run as failed after approximately 15 minutes.

The ticket asks GitHub to:

1. confirm that the six runs are Unavailable Executions;
2. provide GitHub's authoritative Q3 numerator and denominator;
3. identify the Applicable Service Fees;
4. preserve the relevant runner-assignment and service telemetry;
5. treat the ticket as notice of the potential claim; and
6. confirm whether a separate redemption request is required after quarter-end.

The standard SLA says the written redemption request must be submitted within 30 days after the applicable calendar quarter. For this incident, that normally means filing the formal Q3 request no later than October 30, 2026.

What the full cycle looked like

Public outage detected
        ↓
Incident mapped to an SLA-covered service
        ↓
Customer plan and contract checked
        ↓
Customer executions inspected
        ↓
Qualifying failures separated from ordinary failures
        ↓
Quarterly SLA ratio calculated
        ↓
Applicable fee base checked
        ↓
Evidence-preserving support ticket filed
        ↓
Vendor determination and quarter-end claim pending

What we learned

Status monitoring is the start, not the finish

A public status incident identifies an opportunity to investigate. It rarely proves customer eligibility by itself.

The contract's denominator matters

GitHub Actions measures executions, not outage minutes. Other vendors measure availability by minute, request error rate, region, resource, or affected-user ratio. Applying the wrong denominator can produce a confident but invalid claim.

“No logs” can be the evidence

In this case, the lack of runner assignment, steps, output, and billed compute time was more important than an application error message. The workflow never reached our code.

A qualifying percentage can still produce a zero-dollar credit

Included usage and contract fee allocation can determine whether a technically valid claim has economic value. That question belongs in the support request rather than being guessed.

File notice while the evidence is fresh

Even when the formal calculation depends on quarter-end data, opening a support case creates a timestamped record and asks the vendor to preserve telemetry that customers cannot access themselves.

Where the case stands

The support ticket has been filed. GitHub has not yet approved a credit, confirmed the execution classification, or determined the fee base. We will update this case study after GitHub responds and again after the Q3 calculation closes.

That unresolved ending is part of the point: the real SLA-credit cycle is not “outage detected, money owed.” It is detection, contractual interpretation, customer-specific evidence, calculation, filing, and vendor determination.

SLA Credit Watch is designed to make that full path visible.