GitHub API Authentication Failures, June 2026: Monitoring Authenticated Endpoints

The trap: on June 10 2026, valid GitHub credentials started drawing erroneous 401s on what GitHub reported as approximately 15% of API traffic, an incident GitHub ran from 15:20 to 16:39 UTC. The structural problem is that the people most likely to be watching cannot see it the easy way: an anonymous ping has no auth step to fail, and a status-only probe treats a 401 as a clean, valid HTTP status and stays green. The only instrument that catches an auth-plane failure is one that authenticates, calls a protected endpoint, and asserts the authenticated response came back, a 200 and not a 401. Velprove's free multi-step API monitor does exactly that: authenticate, call a protected endpoint, assert 200 and an auth-only field, so green means the authenticated response actually returned. Start free, no credit card required.

When a 401 is the failure, not the gate

Most of the time a 401 is the system working. You called a protected endpoint without valid credentials, the server refused you, and it said so with the correct status code. That is the gate doing its job. The June 10 incident is the other kind of 401, the one where the gate is broken: you sent valid credentials and the server rejected you anyway. GitHub's own words were "erroneous 401 responses." The request was turned away as unauthenticated even though the token was correct. A 200 where you expected a 200, flipped to a 401.

The reason this is so easy to miss is that the failure surfaces as a clean, valid HTTP status, not a 500 and not a timeout. Nothing crashed. Nothing hung. The server answered promptly and politely with the wrong answer. So the two cheapest ways to watch an API both sail straight through it. An anonymous ping that hits a public landing page or an unauthenticated endpoint never exercises the auth path at all, because there is no auth step in it to fail. And a status-only probe that calls a real endpoint but treats anything that is not a 5xx as "up" reads the 401 as a perfectly valid response and stays green for the whole window. This is a textbook member of the silent-outage family we catalog in the anatomy of a silent outage and explain at length in why uptime monitors miss outages: the internal signal looks healthy while a specific population, here every integration holding a valid token, is being locked out.

Why "200 OK" is the wrong question for an authenticated endpoint

For a public, no-auth endpoint, "did it return 200?" is a reasonable first question. For an authenticated endpoint it is the wrong question, because the endpoint can return a non-200 that is itself a correct, valid status, a 401 or a 403, and a status-only check cannot tell "refused you correctly" apart from "refused you erroneously." The question that actually matters is narrower: did the authenticated response come back? Not "did something respond," but "did the response that only an authorized caller is supposed to get come back?" That is the question an erroneous-401 incident answers with a no, and it is the question your monitor has to be built to ask.

The timeline (UTC, primary-source)

The timeline below is taken verbatim from the GitHub Status incident permalink. All times UTC. Source: GitHub Status incident fcj3088jg1wx.

GitHub classified the incident as critical. Start to resolution, the window ran 15:20 to 16:39 UTC, about 1 hour 18 minutes. Two components were named: API Requests and Issues. Issues was mitigated first, at 15:46, with API Requests mitigated about 50 minutes later at 16:36. The resolution update promised a root cause analysis when available; as of writing, none had been published. The only thing GitHub said about cause was that it had "identified a problematic component in our infrastructure," so this post quotes that and does not speculate beyond it.

What broke (and what GitHub did not say broke)

Here is the scope, in GitHub's own framing and no further.

What broke: authenticated API requests. GitHub described it as "sporadic authentication failures impacting approximately 15% of API traffic," and at 16:21 named the symptom precisely: "Erroneous 401 responses are causing app integrations to trigger authentication flows." That last line is the whole shape of the incident in one sentence. Valid credentials drew 401s, and the integrations holding those credentials reacted the way they are designed to react to a 401, by trying to re-authenticate, which did not help because the credentials were never the problem. Issues was also listed as degraded and was the first component mitigated, at 15:46.

A few things this post deliberately does not assert, because GitHub did not publish them. There is no claim about git operations, clone, push, or pull. There is no claim about OAuth login flows for end users, about GitHub Actions, about webhooks, or about Packages, because none of those were named as affected components, only API Requests and Issues were. The 16:21 mention of "app integrations" is a symptom of the 401s, not a separately scoped component. There was no regional scoping published; GitHub framed the impact as a share of API traffic, not a geography. And there is no root cause, because none was disclosed.

The one number, stated carefully

GitHub gave exactly one quantified figure: "approximately 15% of API traffic." That is GitHub's own characterization, repeated across three updates, and it should always be attributed to GitHub, not presented as anyone else's measurement. The word doing the most work next to it is "sporadic." A sporadic failure on a share of traffic is not a steady, every-request break. It means a monitor sampling at an interval could plausibly have seen a red on some polls and a green on others during the window. That detail matters for the honesty boundary later, and it is the reason this post does not build a tidy detection-time story off the 15%: a sporadic, partial failure does not give you a clean, deterministic moment to point at.

How Velprove monitors GitHub's authenticated API

The natural instrument for this failure shape is a free multi-step API monitor, and the reason it fits is that an auth-plane failure has more than one moving part to check. A multi-step monitor lets you chain requests and carry a result from one step into the next, and the free plan covers up to three steps, which is exactly enough for the shape that catches an erroneous 401: authenticate, call a protected endpoint, assert the authenticated response.

Step 1: authenticate

The first step performs the auth step, sending a valid token so the monitor is acting as a real authenticated caller rather than an anonymous one. Use a dedicated, low-privilege monitoring token, never a real account's credentials and never a token with more scope than a read of one protected endpoint needs. The point of this step is to establish the authenticated identity the rest of the check depends on, and to confirm the auth step itself succeeds.

Step 2: call a protected endpoint with the token

The second step calls a protected endpoint with that token, the kind of authenticated api.github.com endpoint that returns account-scoped or token-scoped data, the data an anonymous caller could never get. This is the request that an erroneous 401 incident actually breaks, so it is the request your monitor has to make, with the token attached, exactly the way your integration makes it.

Step 3: assert the authenticated response

The third step is where green earns its meaning. You assert two things together. First, the status is 200 and not 401, which catches the bare erroneous-401 case directly. Second, a content match on a field that only appears for an authenticated, authorized response, an account-scoped field the anonymous version of the endpoint never returns. The two together are stronger than either alone: the status assertion catches the clean 401, and the content assertion catches the subtler case where the endpoint returns a 200 with a stripped-down, unauthenticated-looking body. When valid credentials start drawing erroneous 401s, this is the assertion that flips the monitor red, while a bare GET with no token, or an "any non-5xx is up" rule, would stay green.

The mechanics of building the chain, carrying the token from the auth step into the protected call, are covered step by step in the multi-step API monitoring guide, so this post points there rather than re-teaching them. And for why an auth-plane failure is invisible to a service's own /healthz self-report, and the bearer-token protected-route pattern in general, see API health check patterns. If you also want the reachability check on the public health endpoint alongside the authenticated probe, that is monitoring a REST API health endpoint.

The honesty boundary

The strongest version of this post is the version that names what it does not claim.

First, and most important: Velprove did not detect this incident. We did not monitor GitHub. Everything above is the failure shape that a multi-step authenticated API monitor is built to catch, presented as a worked example, not as a claim that we caught it.

Second, a sporadic failure on a share of traffic is not guaranteed to trip on any given poll. GitHub described this as "sporadic" and as affecting "approximately 15% of API traffic," which means a monitor sampling at an interval could have caught a red on some polls and a green on others during the window. An external monitor demonstrates the shape is catchable; it does not guarantee it would have flagged this specific partial, sporadic incident on any single poll. We say that plainly rather than implying clean detection.

Third, an authenticated monitor sees only the endpoint and the identity you point it at. It does not certify the whole API, all token types, or all of your integrations. It tells you whether the one authenticated call you chose still returns the authenticated response, which is enough to surface this class of failure but is not a blanket health claim about everything behind the login.

Fourth, the content assertion is only as good as the field you pick. Assert on a stable field that an authorized response genuinely always contains, not on an optional or A/B-tested field that can legitimately be absent. A brittle field produces false reds; a well-chosen one is what separates "the authenticated response came back" from "something returned 200."

Fifth, on cause: GitHub said only that it had "identified a problematic component in our infrastructure" and that a detailed analysis would follow. None had been published at the time of writing. Anything more specific than GitHub's own words would be guessing, so we quote them and stop there.

This pattern, not just this incident

This incident is the authenticated-plane mirror of one we tore down a few days earlier. In the signed-out mirror of this incident, the June 8 break lived on the anonymous public path: signed-out visitors lost Pull Requests and Issues while authenticated sessions stayed green, and the right instrument was an unauthenticated content monitor on a public URL. This June 10 incident is the exact reverse. The authenticated path itself failed, valid credentials drawing erroneous 401s, while an anonymous probe would have seen nothing, because an anonymous probe never touches the auth plane. Two sides of the login, the same silent-outage family: one breaks for the signed-out world while the signed-in world is fine, the other breaks for the holders of valid credentials while an anonymous caller is fine.

There is a third GitHub teardown in the same family, and it is worth naming precisely so it does not read as overlap. In the GitHub Actions May 2026 teardown, a different authenticated-API surface failed: the orchestration field itself was stuck behind an otherwise healthy 200, a workflow run that kept reporting the wrong state. That is a different failure layer from this one. There, the response came back, the status was fine, and the break was in a value inside the body. Here the break is one layer earlier, in the auth plane: the response that came back was a 401, the request never got far enough to return a body to inspect. Same vendor, same authenticated API, two distinct layers, the auth plane rejecting a valid credential versus an orchestration field stuck behind a 200.

The generalized lesson is for any product with a token-authenticated API, not just GitHub. The vendor API your product consumes, or the API you expose to your own customers, can have its auth plane fail, valid tokens drawing erroneous 401s, while a ping on the public surface stays perfectly green. If that is the shape of your stack, Velprove for API monitoring and Velprove for SaaS are built around exactly this gap.

Frequently Asked Questions

What were the GitHub API authentication issues on June 10 2026?

GitHub ran an incident from 15:20 UTC to 16:39 UTC on June 10 2026, roughly 1 hour 18 minutes. GitHub described it as sporadic authentication failures impacting approximately 15% of API traffic, with erroneous 401 responses on API Requests; Issues was also briefly listed as degraded and was mitigated first. GitHub classified the incident as critical. The 15% figure is GitHub's own published characterization. The root cause was not disclosed; GitHub said only that it had identified a problematic component in its infrastructure and that a detailed analysis would be shared when available.

Was the GitHub API down on June 10 2026?

No, not fully. GitHub characterized it as sporadic authentication failures on approximately 15% of API traffic, which means by GitHub's own number roughly 85% of API traffic was unaffected, over a window of about 1 hour 18 minutes. That is a partial, sporadic degradation of authenticated requests, not a full API outage. GitHub itself did not use the word outage for this incident.

What is an erroneous 401, and why doesn't a normal uptime check catch it?

An erroneous 401 is an unauthorized response returned on a valid credential. The request was rejected as unauthenticated even though the token was correct, which is what GitHub reported on June 10 2026. A normal uptime check misses it for two reasons. An anonymous ping has no auth step to fail, so it never exercises the path that broke. And a status-only probe treats 401 as a clean, valid HTTP status rather than an error, so it stays green. You only catch this class of failure by asserting that the authenticated response actually came back: status 200, not 401, plus a field only an authorized response contains.

How do you monitor an authenticated API endpoint for auth failures?

Use a multi-step API monitor. Step one authenticates, sending a valid test token or performing the auth step. Step two calls a protected endpoint with that token. Step three asserts the authenticated response came back: status 200 rather than 401, plus a content match on a field that only appears for an authenticated, authorized call. When valid credentials start drawing erroneous 401s, that third assertion flips the monitor red. Velprove's free plan covers the three-step shape, which is exactly enough for authenticate, call, assert.

Did Velprove detect the GitHub API authentication failures?

No. Velprove did not monitor GitHub and did not detect this incident. This post uses it as a worked example of the failure shape an authenticated API monitor is built to catch, not as a claim that Velprove caught it. There is an extra honesty point specific to this incident: GitHub described the failures as sporadic and affecting approximately 15% of API traffic, so even the right monitor is not guaranteed to trip on any given poll during a partial, sporadic failure. The monitor demonstrates the shape is catchable; it does not guarantee it flagged this specific partial incident.

Does GitHub have an SLA for an API authentication incident like this?

Consumer plans (Free, Pro, Team) do not carry a contractual SLA, and a roughly 1 hour 18 minute partial degradation is unlikely to breach a typical 99.9 percent monthly threshold even where an SLA applies. The operational angle here is visibility, knowing your integration started getting erroneous 401s and that the cause was upstream, not the service credit. For the deeper SLA-credit math, see the SLA-vs-SLO-vs-SLI breakdown.

Monitor your authenticated API

The trap is that an auth failure looks like the system working. A clean, valid 401 sails through a status-only probe, and an anonymous ping never touches the auth plane at all, so the one failure that locks out every holder of a valid token is the one your cheapest checks are built to miss. The fix is a monitor that authenticates, calls a protected endpoint, and asserts the authenticated response came back, a 200 and not a 401, plus a field only an authorized call returns.

Velprove's free multi-step API monitor covers exactly this shape: up to three steps, which is all it takes to authenticate, call, and assert; ten monitors; five regions on every plan; and commercial use allowed, no credit card required. Try Velprove and point a multi-step monitor at the authenticated API your product depends on. If your stack is API-shaped, start with Velprove for API monitoring.