GitHub Outage, June 2026: Signed-Out Users Lost Pull Requests and Issues

The blind spot: on June 8 2026, GitHub's Pull Requests, Issues, and Actions went down for signed-out visitors while logged-in users saw nothing wrong, an incident GitHub ran from 07:11 to 08:36 UTC. The structural problem is that internal dashboards and logged-in QA are constitutionally blind to a signed-out outage, because everyone doing the checking is signed in. The only instrument that sees this class of failure is an external, unauthenticated monitor that hits the public URL with no auth cookie and asserts on the content a signed-out visitor is supposed to get. That is the monitor Velprove gives you free: an unauthenticated HTTP monitor with a content assertion, so green means the public page actually rendered. Start free, no credit card required.

Why the people checking couldn't see it

A signed-out outage is the one failure shape your own team is structurally unequipped to notice, because the act of checking removes you from the affected population. Every engineer dogfooding the product is signed in. Every internal dashboard queries from an authenticated service account. Every QA pass runs against a logged-in session. So when the break lives specifically on the anonymous, signed-out render path, the people best positioned to catch it are the people least able to see it. They are all on the wrong side of the login.

That is exactly what happened to GitHub on June 8 2026. An engineer with an active session could open a repo's Issues tab or a Pull Request and see it render normally. The internal view was green because the internal view is, by definition, authenticated. Meanwhile the experience that broke was the one nobody on the inside was looking at: the first-time visitor with no account, the search crawler, the anonymous API caller, the developer who clicked a link to a public PR without logging in first.

This is the same structural problem behind every silent outage. An internal signal looks healthy while the external reality is broken. We have written up the broader catalog in the silent-outage taxonomy. The signed-out variant is one of the cleanest cases in that catalog, because the green you see is real. Your authenticated path genuinely works. It is just not the path that broke.

The timeline (UTC, primary-source)

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

GitHub classified the incident as critical. Start to resolution, the window ran 07:11 to 08:36 UTC, roughly 1 hour 25 minutes. The resolution update promised a root cause analysis when available; as of writing, none had been published, so this post does not speculate on cause.

What broke for signed-out visitors (and what didn't)

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

What broke: Pull Requests, Issues, and Actions, for unauthenticated, signed-out users. The incident title named Pull Requests and Issues; the 08:13 and 08:35 updates explicitly added Actions. GitHub described the impact as "degraded availability" and "degraded performance," with the incident title using the word "unavailable."

What GitHub did NOT claim was affected: authenticated web sessions. The 08:13 update is explicit that impact was "limited to unauthenticated users." We state that as GitHub's characterization of the blast radius, not as an independently verified absolute, because we did not measure it ourselves. But it is the published scope, and it is the whole reason this incident is a clean case study in signed-out blindness.

A few things this post deliberately does not assert, because GitHub did not publish them. There is no error rate or percentage of failed requests; GitHub did not quantify the blast radius. There is no claim about git operations, clone, push, or pull, because GitHub did not mention them. And there is no root cause, because none was disclosed. The supportable story is narrow on purpose: a critical incident, scoped by GitHub to the signed-out public surface, on three named features, for about 85 minutes.

The ~62-minute scoping delta

There is one supportable number worth pulling out, and it has to be stated carefully so it does not get read as something it is not.

GitHub opened the incident at 07:11 UTC with a generic line: "investigating reports of impacted performance for some GitHub services." It was not until 08:13 UTC, roughly 62 minutes later, that the public update first identified who was actually affected: "impact is limited to unauthenticated users." For that first hour, every public status update said only "some services" or "Issues degraded," without naming that the blast radius was the anonymous public surface.

Be precise about what this delta is and is not. It is a scoping delta: the gap between acknowledging a problem and characterizing who it hit. It is NOT a detection-delay number. GitHub's feed reports the impact start time as equal to the acknowledgment time, so there is no GitHub-stated earlier impact-start to subtract, and this post does not invent one. We are not claiming the outage was silently broken for some measured number of minutes before GitHub noticed. We are pointing at the 62 minutes during which the public-facing scoping was generic, which is exactly the window where an external signal that already knew "the signed-out path is broken" would have been most useful to anyone trying to triage their own reports.

How Velprove monitors public/unauthenticated access

This is the solution, and it follows directly from the spine. If your own checking is blind because it is authenticated, the fix is a monitor that is deliberately unauthenticated.

The instrument is an external HTTP and content monitor that requests a public URL with no session cookie, the same as a first-time anonymous visitor, and asserts on the content the signed-out page is supposed to render. The public surface to probe is whatever a signed-out user actually hits: a public repository's Issues or Pull Requests page, or an anonymous endpoint on api.github.com that returns public data without a token. Point the monitor there as an anonymous client, exactly as the public reaches it.

The load-bearing detail is what you assert on. A status code alone is not enough. During a signed-out break, the anonymous path can still return a 200 from a fallback render, an error page, or a partial shell, and a status-only probe would stay green through the whole incident. So you assert on two things together: a 200 status, and a content match on a string or element that only the real public page renders for an anonymous visitor. For a public Issues page that might be the issue-list heading or a known issue title that always appears for the signed-out view; for an anonymous API endpoint it is a field that the public JSON always contains. When the signed-out experience breaks, the content assertion fails even if the status code does not, and the monitor turns red while a logged-in session would still look fine.

For the broader reason a plain 200 OK probe misses this entire class of failure, see why HTTP probes miss this class of failure.

One note on vantage point, since it only matters if you choose to use more than one: a monitor runs from one region you pick. The June 8 incident was characterized by GitHub as a feature-scoped impact rather than a regional one, so a single unauthenticated monitor from any one region would have been watching the right surface.

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 an external unauthenticated monitor is built to catch, presented as a worked example, not as a claim that we caught it. If you read a detection into this post, that is more than the facts support.

Second, an unauthenticated monitor sees the public surface and only the public surface. It catches a signed-out break on a page or endpoint you point it at. It does not see authenticated-only subsystems, the logged-in dashboards, the account-scoped APIs, the parts of the product that only exist behind a session. Those need their own instrument. The signed-out monitor is exactly as wide as the anonymous public path and no wider.

Third, we do not claim to know what broke inside GitHub. The resolution update said a root cause analysis would be shared when available, and at the time of writing none had been published. Anything more specific than GitHub's own words would be guessing, so we quote them and stop there.

Fourth, the content assertion is only as good as the string you pick. Assert on something stable that the public page genuinely always renders for an anonymous visitor, not on a marketing banner or an A/B-tested element that can legitimately disappear. A brittle assertion produces false reds; a well-chosen one is what separates "the public page rendered" from "something returned 200."

This pattern, not just this incident

The signed-out outage is the mirror image of a failure we teared down recently. In the GitHub Actions May 2026 detection teardown, the authenticated and orchestration surface degraded while the public web surface stayed up, and the right instrument was a content-aware API monitor on an authenticated runs endpoint. Here the asymmetry is reversed: the public, signed-out surface broke while the authenticated experience stayed fine, and the right instrument is an unauthenticated content monitor on a public URL.

The two read as a pair. Same underlying lesson, opposite sides of the login. In one, a plain probe on the public web stayed green while authenticated orchestration burned; in the other, an authenticated session stayed green while the anonymous public path burned. Both are members of the same family in our catalog of silent outages: an internal signal looks healthy while a specific external population is locked out of the truth. The only durable defense is to monitor the exact surface and the exact identity (or absence of identity) that your own checking can't reach. If your team is all signed in, the surface you can't see is the signed-out one.

This is the generalized lesson for any product with a public surface, not just GitHub. Marketing pages, docs, public dashboards, anonymous API endpoints: any of them can break for the logged-out world while your logged-in team sees green. If that is the shape of your stack, Velprove for SaaS and Velprove for API monitoring are built around exactly this gap.

Frequently Asked Questions

Was GitHub down for everyone in June 2026?

No. GitHub characterized the June 8 2026 incident as limited to unauthenticated, signed-out users accessing Pull Requests, Issues, and Actions. In GitHub's own words at 08:13 UTC, impact was limited to unauthenticated users. Signed-in developers were not characterized as impacted. That is GitHub's characterization of the blast radius, not an independently measured absolute, but it is the published scope.

What happened during the GitHub signed-out outage on June 8 2026?

The incident ran from 07:11 UTC to 08:36 UTC on June 8 2026, roughly 1 hour 25 minutes. During the window, Pull Requests, Issues, and Actions were degraded for unauthenticated visitors while authenticated sessions rendered normally. GitHub classified the incident as critical. The root cause was not disclosed in the resolution update, which stated a detailed analysis would be shared when available.

Why could logged-in users still see Pull Requests and Issues?

The break lived on the anonymous public render path, the version of a page served to a visitor with no session cookie. An authenticated request takes a different path through GitHub's systems and rendered normally, which is why a signed-in engineer browsing the same repo saw nothing wrong. The two experiences diverged: green for the logged-in account, broken for the signed-out public.

How can you monitor a signed-out outage?

Point an external unauthenticated monitor at a public URL with no session cookie, and assert on content that only the anonymous public path renders, not just a 200 status. A status-only probe can stay green on a fallback or error page that still returns 200. A content assertion on a string the public page is supposed to render turns the monitor red when the signed-out experience breaks, even while a logged-in session stays fine.

Did Velprove detect the GitHub outage?

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 external unauthenticated monitor is built to catch, not as a claim that Velprove caught it. The honest framing is the pattern, not a detection.

Does GitHub have an SLA for this, and would it credit?

Consumer plans (Free, Pro, Team) do not carry a contractual SLA, and a roughly 1 hour 25 minute degradation is unlikely to breach a typical 99.9 percent monthly threshold even where an SLA applies. The operational angle here is visibility, not the credit. For the deeper SLA-credit math, see the SLA-vs-SLO-vs-SLI breakdown.

Monitor your public surface

The trap is the blind spot: your whole team is signed in, so the one outage you are structurally unequipped to notice is the one that only hits signed-out visitors. The fix is an external monitor that hits the public URL with no auth cookie and asserts on the content a signed-out visitor is supposed to get, so green means the public page rendered, not just that something returned 200.

Velprove's free plan covers this: ten monitor slots you can spread across regions, content assertions on HTTP monitors, email alerts, and no credit card. Sign up free and point an unauthenticated monitor at your own public surface. If your stack is API-shaped, start with Velprove for API monitoring.