GitHub's billing system broke for 3h 53m on 24 September 2026, starting at 16:51 UTC. If you tried to create or update billing information on GitHub during that window, the failure was on GitHub's side, not yours.
Started
16:51 UTC
Duration
Lasted 3h 53m
Source
IsDown
Next time
GitHub is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
What happened?
GitHub opened the incident at 16:51 UTC, first describing it as impacted performance for some GitHub services, then narrowing the description to failures on billing information updates. The posted text was specific: customers may be unable to create or update their billing information while the problem persisted. At 17:40 GitHub said it had identified the problem and was working on mitigation, but gave no detail on what the problem was. Nearly an hour later, at 18:22, GitHub posted that it was continuing to work on mitigation, with a promise of another update in about an hour. That update came at 20:10, reporting that mitigation had been applied and signs of recovery were showing. Fourteen minutes later, at 20:24, GitHub moved the incident to monitoring, and the incident was marked resolved at 20:41, 3h 53m after it started. GitHub's own closing note says a detailed root cause analysis would be shared once available, which means the cause is not on the record as things stand. No components are listed as affected in GitHub's own breakdown, and no user reports were filed during the window on this page. This was a single incident, not a cluster, and GitHub filed seven updates across the nearly four hours it stayed open.
Learning
UptimeRobot's own probes against GitHub's api-auth and raw-cdn components, checked every 60 seconds from EU and NA regions, show 100% uptime across the last 24 hours, 7 days and 30 days, and this incident was not registered against those checks. That is not a contradiction. The billing update path is a distinct backend function that external synthetic checks against authentication and raw content delivery simply do not exercise, so a failure confined to billing processing can run for nearly four hours without ever touching the endpoints most monitoring watches. This is the general shape of a provider-side partial outage: the parts of the service you poll stay green while a specific workflow, in this case billing, fails behind the scenes for anyone who happens to touch it. Your own monitoring of your product would have shown nothing wrong either, because the fault never reached your infrastructure at all. GitHub's status page is the only record of this one, and it carries the weight of a single filing from a single source with no independent confirmation. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
