fix(health-menu): handle incident.io status fetch failures#59156
Merged
rafaeelaudibert merged 1 commit intoMay 20, 2026
Conversation
The HealthMenu's incident.io status poll calls fetch against an external domain (posthogstatus.com) with no error handling, surfacing every network failure (ad blockers, tracking-protection extensions, DNS hiccups, brief status-page outages) as an unhandled TypeError: Failed to fetch. The rawStatus selector already degrades to 'operational' on a null summary, so swallow failures silently while still reporting them as handled exceptions to error tracking for visibility. Generated-By: PostHog Code Task-Id: 2f250c27-2e9b-4b23-bb6a-d21ea91fc73d
Contributor
|
🎭 Playwright didn't run on this PR — your changes touch code that could affect E2E behavior, but Playwright is opt-in via label now to keep CI cost down. Add the Most PRs don't need this. Real regressions still get caught on master and fix-forward. |
Contributor
|
Reviews (1): Last reviewed commit: "fix(health-menu): handle incident.io sta..." | Re-trigger Greptile |
Contributor
|
Size Change: +8.11 kB (+0.01%) Total Size: 118 MB 📦 View Changed
ℹ️ View Unchanged
|
rafaeelaudibert
approved these changes
May 20, 2026
rafaeelaudibert
deleted the
posthog-code/fix-incidentio-fetch-error-handling
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The globally-mounted HealthMenu polls
posthogstatus.com/api/v1/summaryevery 5 minutes (and on visibility change) to surface PostHog status. The fetch had no error handling — every network failure surfaced as an unhandledTypeError: Failed to fetchand got reported to error tracking.Because the call hits an external domain, failures are common and outside our control: ad blockers, tracking-protection extensions, DNS hiccups, transient status-page outages, or a backgrounded tab waking up. Each misbehaving client can emit hundreds of events. This was the source of repeated 500+ event spikes drowning out real signal in error tracking, while UX itself was unaffected (the
rawStatusselector already degrades to'operational'whensummaryis null).Changes
In
frontend/src/lib/components/HealthMenu/incidentStatusLogic.tsx:fetch+response.json()pair intry/catchso network failures returnnullinstead of throwing into kea-loaders as an unhandled rejection.if (!response.ok) return nullbefore parsing the body, so a 5xx from the status page doesn't try to parse HTML as JSON.posthog.captureExceptionas handled exceptions, with HTTP status context where available. This preserves visibility (we can still see if the status page goes down or if a deployment breaks the integration) while keeping them out of the unhandled-error stream.The
rawStatusselector at line 169 already returns'operational'for anullsummary, so degrading silently is safe.How did you test this code?
I'm an agent (PostHog Code). No manual testing was performed in this session — the local environment did not have
node_modulesinstalled, so I could not run typecheck or the dev server. The change is small and matches theposthog.captureExceptionimport pattern already used infrontend/src/initKea.tsand other logics in the repo.Suggested manual verification:
www.posthogstatus.comin DevTools (Network → Block request domain), reload, confirm no unhandled exception in the console and the menu shows operational state.posthog.captureExceptiondebug output / error tracking dev instance).Publish to changelog?
no
Docs update
No docs change required.
🤖 Agent context
Authored by PostHog Code agent (claude-opus-4-7) in response to a signal report flagging six recurring error tracking issues all resolving to
incidentStatusLogic.tsx:156over the past month, with repeated 500+ event spikes weeks apart confirming this was a persistent client-side fetch error rather than a one-off.Decisions:
.catch(() => null)chained on the promise but preferred explicittry/catchso we could distinguish HTTP errors from network errors and add useful context (status code) to the captured exception.captureExceptioncall so we don't lose all visibility — the goal is to eliminate unhandled errors, not to hide the integration's health entirely. Handled exceptions can be filtered out of dashboards/alerts.