GitHub went down for over six hours on August 18, 2026, with error rates touching nearly 20% worldwide, and it wasn’t an isolated incident. According to TechCrunch’s reporting, the platform has suffered 257 outages over the past year. The same day, AI coding tool Cursor launched Origin, a rival code-hosting platform explicitly built to interoperate with GitHub rather than compete on lock-in, letting developers sync repositories between the two rather than committing fully to either.
The specific story is about code hosting, but the underlying lesson applies to any business that has put a single provider between itself and its customers, including a company’s own website.
The August 18 Outage and Cursor’s Response
GitHub’s August 18 outage degraded core site functions with close to a one-in-five error rate for over six hours, according to TechCrunch’s account. That single incident sits on top of a documented pattern: 257 outages over the past year on a platform TechCrunch reports has some 180 million developers using its platform. Cursor’s response was to avoid asking developers to abandon GitHub outright; Origin was built with explicit two-way sync so a team’s repositories can live on both platforms simultaneously, described in the company’s own framing as letting “your GitHub repos sit alongside the ones Cursor hosts.”
That interoperability-first design is the detail to pay attention to. Cursor didn’t bet that frustrated developers would do a clean, one-time migration away from an incumbent with 180 million users. It bet that developers want redundancy without having to fully commit to a second platform, which is a different product decision than building a pure GitHub competitor.
Single-Provider Dependencies as Business Risks
For a software team, a multi-hour GitHub outage means blocked deploys, stalled code reviews, and a development pipeline that stops. For a business running its storefront or marketing site on a single host with no failover plan, the equivalent scenario is a multi-hour period where the site itself is unreachable, during which every visitor who would have converted, checked out, or found the business through search fails to connect. The difference in visibility makes this easy to underweight: a developer locked out of GitHub notices immediately, while a customer who hits a down storefront leaves without telling anyone, and the business only sees the gap in the analytics days later, if it notices at all.
The pattern GitHub’s 257 outages over the past year illustrates is not that GitHub is uniquely unreliable. Any single provider, no matter how large or well-resourced, accumulates outage risk by existing at scale. The practical question for a business is what happens to operations during the hours a host goes down, rather than finding a host that never experiences downtime.
Quantifying Downtime
Treating a site outage as an abstract inconvenience changes when it is translated into monetary value. Take an online store averaging a modest $2,000 in daily revenue: a six-hour outage during normal business hours represents a quarter of that day’s sales window gone, since visitors who hit a down site during a shopping session rarely return later that same day to try again. Running that same outage during a planned sale, a holiday shopping period, or right after a paid ad campaign sends a traffic spike increases the impact, because the traffic acquired through paid promotion is the traffic that never converts. Doing this calculation in advance for a site’s typical revenue pattern turns a backup plan from a vague idea into a dollar figure that justifies the setup work redundancy requires.
Practical Redundancy Steps for Small Businesses
Full multi-provider hosting failover, the kind large enterprises run across multiple cloud regions and providers simultaneously, is infrastructure overhead most small businesses do not need and should not try to replicate. However, there are proportionate steps that capture similar protection:
– Off-host backups on a schedule, stored somewhere other than the same server being backed up, preventing a host-side failure from taking the backup down with the live site.
– DNS with a low TTL, allowing domain pointer changes to propagate in minutes rather than the better part of a day.
– A documented recovery process, moving beyond backup files sitting in storage. A backup nobody has ever restored from is an assumption rather than a plan; testing the restore process at least once outside of an emergency is necessary.
– Status page monitoring for your own host, ensuring an outage triggers an alert for you rather than appearing as a customer complaint or a gap in next week’s analytics.
– A clear-eyed view of hosting plan SLAs. An uptime guarantee with service credits compensates financially for downtime; it does not prevent the downtime itself or recover lost sales.
None of this requires running infrastructure across multiple providers simultaneously the way Cursor’s Origin lets developers do with code. It requires treating potential outages as questions to answer before they occur.
Applying the Interoperability Lesson to Hosting
The transferable part of Cursor’s approach is the interoperability-first execution. Origin does not ask developers to choose a side; it lets them keep GitHub as the primary system of record while gaining a second platform that syncs with it. That lowers switching costs compared to an all-or-nothing migration, and it is the principle to apply when evaluating a business hosting setup: protection comes from having code, databases, and assets portable enough that switching or supplementing a primary host during an outage is manageable, rather than maintaining a second full-time host in parallel. A site locked into a host-specific proprietary builder, with no standard export path for content and databases, has signed up for the all-or-nothing version of the GitHub dependency TechCrunch describes, applied to a storefront instead of a codebase.
Evaluating Host Track Records
Most hosting providers publish uptime numbers, but a percentage alone does not provide all necessary context. A 99.9% uptime figure allows for roughly 8.7 hours of downtime a year, and the number that matters for a business is the distribution: was that downtime a handful of scattered two-minute blips overnight, or one six-hour outage during a peak shopping period? Asking a prospective or current host for incident history, rather than relying on marketing-page percentages, and checking whether status pages show transparency during incidents clarifies reliability. AllCloudHost’s own service level guarantees page provides specifics on coverage and incident communication that matter more than headline uptime percentages.
The GitHub outage and Cursor’s response illustrate what happens when a portion of an industry’s workflow depends on one company’s infrastructure staying up. Most small businesses do not operate at GitHub’s scale, but the underlying exposure—one provider, one point of failure, and one bad day taking down everything downstream—scales down just as easily as it scales up.