# Sentry is full of failed fetch errors to Croct endpoints from a subset of browsers

Asked by Lena Vogel on 2026-03-11. Tags: nextjs, sentry, ad-blockers, errors.

Triaging our Sentry inbox this week and one issue group dominates everything:

```
TypeError: Failed to fetch
  at fetch (native)
  at HttpTransport.send (croct.js:1:48211)
```

The failing URLs are always `/client/web/track` and `/client/web/evaluate`. It is
a few thousand events per day, but always from the same cohort of browsers, mostly
Firefox and Brave. Production works fine for everyone I can reach.

My suspicion is browser extensions blocking the requests. Is that a known thing,
and should I just silence the issue in Sentry or is there an actual fix

## 2 answers

### Accepted answer from Dario Fontana (2026-03-11)

The EasyList/EasyPrivacy filter lists block the
`/client/web/evaluate`, `/client/web/track`, and `/content` endpoints, so any
browser running an ad blocker generates exactly these failures. Brave blocks by
default, which explains your cohort. It is noise, not an outage.

Two ways to deal with it:

1. Filter it in Sentry. Drop the events in `beforeSend` when the failing URL
   matches the Croct endpoints. Cheap, but the requests still fail for those
   users.

2. Remove the cause with first-party proxying. Point `baseEndpointUrl` and
   `cidAssignerEndpointUrl` at a path on your own domain and proxy the traffic
   through. Requests become same-origin, so filter lists no longer match them.

One thing worth knowing: if you fetch content server-side with `fetchContent`,
that path is unaffected either way, because the browser never calls Croct
directly for that content. The blocked requests only affect client-side
tracking and evaluation.

There is a longer thread on the proxying setup here:
[Ad blockers are blocking Croct endpoints](/answers/ad-blockers-blocking-croct-endpoints)

### Answer from meg (2026-03-12)

Adding a data point: we went the `beforeSend` route first and it worked, but we
later moved to the first-party proxy anyway because the blocked track events
meant a slice of our users never showed up in analytics at all. If you care
about event completeness and not just Sentry hygiene, the proxy is the better
long-term answer. The Sentry filter took ten minutes, the proxy took an
afternoon including the rewrite rule and testing.