Customer agreements

GitHub

5 min read Original article ↗

Current uptime can be viewed at the GitHub Status Page, located at githubstatus.com. Capitalized terms not defined in this SLA have the meanings provided in the Customer’s governing Agreement.

1. Definitions.

“Applicable Period” means the calendar quarter in which a Service Credit is owed.

“Applicable Service Fees” means the total fees paid by Customer for a Service that are applied to the Applicable Period in which a Service Credit is owed.

“Downtime” is defined for each Service in Section 5 (“Services Covered by SLA”). In addition to these Service-specific definitions, Downtime does not include Scheduled Downtime, and Downtime does not include unavailability of a Service due to limitations or exclusions identified in Section 4 (“Limitations and Exclusions”).

“Preview” means a service that is not yet generally available.

“Scheduled Downtime” means periods of Downtime related to network, hardware, or Service maintenance or upgrades. We will publish notice or notify you at least five (5) days prior to the commencement of such Downtime, unless a bona fide emergency prevents us from doing so.

“Service” means the specific GitHub service listed in Section 5 (“Services Covered by SLA”).

“Service Credit” is the percentage of the Applicable Service Fees credited to Customer following GitHub’s claim approval.

“Service Level” means the performance metric(s) set forth in this SLA that GitHub agrees to meet in the delivery of the Services.

“Uptime” means the percentage a Service was available out of the total possible availability for the Service in a calendar quarter. Uptime is calculated using the formula specified for each Service below.

2. Uptime Commitment.

GitHub commits to maintain at least 99.9% Uptime for the applicable GitHub service.

If GitHub does not meet the committed Service Level, Customer will be entitled to a Service Credit as indicated in Section 3 (“Service Credits Redemption”).

3. Service Credits Redemption.

Service Credits are calculated as follows:

Uptime

Percentage of Applicable Service Fees

99.5% <= Uptime < 99.9%

5%

99.0% <= Uptime < 99.5%

10%

Uptime < 99.0%

25%

Customer may redeem Service Credits only upon written request within thirty (30) days of the end of the Applicable Period. Written requests for Service Credits should be sent either (a) to GitHub Support if Customer purchases directly from GitHub, or (b) through a Microsoft support ticket if Customer purchases SLA-covered Services through Microsoft.

Service Credits may be in the form of a refund or a credit to Customer’s account. Service Credits cannot be exchanged into cash, and are limited to a maximum of ninety (90) days of paid service per calendar quarter. Customer must have paid all outstanding invoices to receive Service Credits. Service Credits expire upon termination of Customer’s agreement with GitHub.

Service Credits are the sole and exclusive remedy for any failure by GitHub to meet any obligations in this SLA.

4. Limitations and Exclusions.

This SLA and any applicable Service Levels do not apply to any performance or availability issues:

A. Due to factors outside our reasonable control (for example, natural disaster, war, acts of terrorism, riots, government action, or a network or device failure external to our data centers, including at your site or between your site and our data center);

B. For a Preview, or a purchase made with a subscription credit;

C. That result from the use of services, hardware, or software not provided by us, including, but not limited to, issues resulting from inadequate bandwidth or related to third-party software or services;

D. That result from your unauthorized action, or from your lack of action when required to act;

E. That result from anyone gaining access to our network by unauthorized use of your credentials or equipment, or otherwise resulting from your failure to follow appropriate security practices;

F. That result from your violation of applicable Acceptable Use Policies or your Agreement;

G. That result from your use of the Service in a manner inconsistent with the features and functionality of the Service (for example, attempts to perform operations that are not supported), or otherwise inconsistent with our published guidance;

H. That result from faulty input, instructions, or arguments (for example, requests to access files that do not exist);

I. That result from our throttling of suspected abusive behavior or hacked accounts;

J. That result from rate limits, performance degradation, or other latency issues without actual service unavailability (except for services which explicitly include a performance-based Service Level); or

K. Caused by your use of a Service after we advised you to modify your use of the Service, if you did not modify your use as advised.

5. Services Covered by SLA.

The following Services are covered by this SLA:

A. GitHub Actions

“Total Triggered Executions” is the total number of all Actions executions triggered by Customer in a calendar quarter.

“Unavailable Executions” is the total number of executions within Total Triggered Executions which failed to run in a calendar quarter. An execution failed to run when the Actions history log did not capture any output five (5) minutes after the trigger was successfully fired.

Uptime Calculation:

Uptime formula showing “Total Triggered Executions minus Unavailable Executions” divided by “Total Triggered Executions,” multiplied by 100 to calculate uptime percentage.

B. GitHub Enterprise Cloud

“Downtime” is a period of time where either (i) the error rate exceeds five percent (5%) in a given minute for a Service feature or (ii) the Service was unavailable as determined by a combination of GitHub’s internal and external monitoring systems.

“Service Feature” is one of the following components of GitHub Enterprise Cloud: git Operations, Issues, Pages, Pull Requests, Webhooks, and API requests to these components.

Uptime Calculation:

Availability formula showing “Maximum Available Minutes minus Downtime” divided by “Maximum Available Minutes,” multiplied by 100 to calculate percentage uptime.

C. GitHub Packages

“Average Error Rate” is the sum of Error Rates for each hour in a calendar quarter, divided by the total number of hours in a calendar quarter.

“Error Rate” is the total number of failed storage transactions divided by the total storage transactions during a set time interval (currently set at one hour). If the total storage transactions in a given one-hour interval is zero, the error rate for that interval is 0%.

Uptime Calculation for Transfers: same as GitHub Actions

Uptime Calculation for Storage: 100% – Average Error Rate*

* The Uptime Calculation excludes public usage and storage transactions that do not count toward either total storage transactions or failed storage transactions (including pre-authentication failures; authentication failures; attempted transactions for storage accounts over their prescribed quotas)

Version: June 2026