Sentry event sent but no issue in Epure: causes and fixes

A common moment: you changed the DSN, deployed, threw new Error("test") from staging, and the Issues view still says there is nothing unresolved. Open the browser's network tab or your server log and find the request to /api/<project-id>/envelope/. Its status code and its JSON body decide which section below applies, so read them before sending another test event.

Is the Epure Issues view filtered to another environment?

The Epure Issues view in v0.2.0 shows one environment at a time, Production, Staging or Local, and matches the event's environment value exactly. A 202 Accepted followed by an empty view most often means the event carries another name. @sentry/nextjs falls back to NODE_ENV on the server, so next dev sends development, and Vercel previews send preview (SDK source, checked 6 Nov 2026). Those events are stored, but none of the three filters shows them.

Confirm it in the request body: the event JSON holds "environment":"...". Fix it by setting environment in every Sentry.init to production, staging or local, or by setting SENTRY_ENVIRONMENT on servers. Verify by sending the test again and picking that filter in the environment menu at the top of the Issues view.

Did the Sentry SDK send the event at all?

No request in the network tab or the server log means the Sentry SDK dropped the event before sending, and Epure never saw it. The SDK sends nothing when dsn is empty, enabled is false, beforeSend returns null, or the message matches ignoreErrors. A sampleRate below 1.0 drops that share of errors on purpose; Sentry's options page gives 1.0 as the default (checked 6 Nov 2026).

Short-lived processes are the other case. A script, a queue job or a serverless handler can exit before the SDK's queue empties; add await Sentry.flush(2000) in Node or sentry_sdk.flush() in Python (Python options) before the process ends. Set debug: true in Sentry.init for one run, and the SDK logs whether it captured and sent the event.

Is the event still going to Sentry instead of Epure?

A request to ingest.sentry.io or to your own /sentry-tunnel path means the old DSN is still live in that runtime, so the event is in Sentry, not lost. Browser bundles keep the DSN they were built with, NEXT_PUBLIC_SENTRY_DSN included (Next.js docs), and Sentry's Next.js tunnelRoute forwards only to Sentry SaaS DSNs in its default mode (build options). Rebuild, remove tunnelRoute, and reload the tab. The steps are in change the Sentry DSN.

What does 404 project_not_found mean in Epure?

Epure returns 404 project_not_found when the number at the end of the DSN matches no Epure project. The SDK takes that number as the path segment in /api/<project-id>/envelope/, so a Sentry project id left in place, a typo, or a project deleted since you copied the DSN all end here. A path segment that is neither a number nor a project UUID returns 400 invalid_project instead.

Confirm by comparing the last segment of the DSN in your config with the one in the project's Client Keys settings. Fix it by copying the whole DSN again. Verify with the curl check in change the Sentry DSN, which should now return 202.

What do 401 invalid_dsn, 403 project_mismatch and 403 dsn_revoked mean?

Epure checks the public key in the DSN on every request, and these three codes mean the project exists but the key does not fit. 401 invalid_dsn means the key is missing or unknown, often a Sentry key left in front of the Epure host. 403 project_mismatch means the key belongs to another Epure project. 403 dsn_revoked means the key was revoked in Client Keys; a rotation revokes every active key of the project at once.

The fix is the same for all three: copy the current DSN from Client Keys, update every runtime, and rebuild browser bundles. Verify with one test event; the response turns into 202 Accepted with an id in the body.

What does 403 subscription_inactive mean?

Epure Cloud returns 403 subscription_inactive when the workspace has no active plan, and it refuses new events until one is chosen. The message names the reason: "Trial ended; choose a plan to resume ingestion", "Subscription canceled", "Subscription paused", or "No active plan". A user's first workspace starts with a 14-day trial on Pro limits; a second workspace by the same user starts without a plan. Self-hosted Epure never returns this code.

Issues and events already stored stay readable. Fix it by choosing a plan on Epure pricing (Pro is $29 a month for 200,000 events) or by resuming a paused subscription. Verify with one test event.

Why does Epure return 403 ingest_cap_exceeded?

Epure returns 403 ingest_cap_exceeded when a project has stored as many events this hour as its hourly ingest cap allows. The cap is a per-project setting, Hourly ingest cap, in the project's General settings, and it rejects new events until the next hour starts. Epure also records an ingest_cap_hit alert when the cap is hit, so the Alerts view is the fastest confirmation.

Repeats of one looping error do not use the cap: past the flood rate they are counted, not stored, as the next section explains. Fix it by raising the cap, or by finding the release that started sending many distinct errors at once. Verify when the hour turns: the next event returns 202.

What does 403 ingest_plan_limit_exceeded mean?

Epure Cloud returns 403 ingest_plan_limit_exceeded only for a new or regressed issue, after the monthly quota and its grace of 5% are both used. The message says so: "Monthly event quota and new-issue grace are used up; existing issues are still counted". Events of existing open issues still get 202 and raise their counts. Epure emails the workspace at 80% and 100% of the quota and never bills overage automatically.

Fix it by moving to a larger plan, or wait for the next month; the rule is on Epure pricing. Self-hosted Epure has no monthly quota.

Why does the issue count go up but no new event appear?

Epure samples a flood per fingerprint: it stores up to 100 events a minute for one identical error and 150 a minute for one throw site, and counts the rest. Counted events get 202 Accepted, raise the issue's count, and store no payload, so the latest event you open can be older than your last test. The same happens over the monthly quota, where existing issues are counted without storing new payloads.

Nothing is broken here. To see a fresh event, wait a minute and send one test error, not a loop. How the valve decides is on the spike valve page.

Why does Epure answer 202 and store nothing?

Epure answers 202 Accepted and stores nothing in three cases. An envelope with only transaction, replay_event, profile or other non-error items is accepted and dropped, because Epure tracks errors only. An event whose SDK event_id Epure already received gets 202 again without a second copy; SDK event ids are deduplicated for 7 days. And an event that matches an inbound filter you turned on is dropped.

Confirm the first case in the request body: it has no "type":"event" item. For the second, replaying a captured envelope with curl reuses its id; let the SDK generate a new one. Inbound filters (Crawlers, Extensions, Localhost, Legacy browsers, ResizeObserver, Chunk load and message patterns) live in the project's Filters settings and are all off by default. The Localhost filter only drops events tagged production that come from a loopback URL.

What does 503 backlog_unavailable mean?

Epure returns 503 backlog_unavailable when it could not commit the event to its durable inbox, and 503 grouping_capacity when grouping is saturated. In both cases the event was not kept, and the response says so rather than acknowledging data it cannot retain. Related 503 codes such as plan_lookup_unavailable and quota_lookup_unavailable mean a lookup failed for that one request.

Send the event again after a short wait. A retry with the same SDK event_id is safe, because Epure stores an event once per id (durable ingestion contract). On a self-hosted instance, a lasting 503 points to PostgreSQL storage or a stuck worker; /health/ready reports the backlog, and self-hosting troubleshooting lists the checks.

Why does the browser console show a CORS error?

Epure adds Access-Control-Allow-Origin to an ingest response only when the page's origin is in its allowed list, and its error responses carry no CORS headers at all. A browser therefore reports a rejected request, such as 401 invalid_dsn, as a CORS block and hides the real status. The CORS message is often the symptom of another cause on this page.

Confirm with curl from a terminal, which ignores CORS: post to the same URL with the same key and read the status. Fix that status first. On a self-hosted instance, also add your app's origin to EPURE_CORS_ORIGINS (comma-separated, for example https://app.example.com) and restart; production refuses *. The variable is described in self-hosting configuration.

Does Epure return 429 Too Many Requests on ingest?

Epure's ingest route never returns 429. In v0.2.0 a flood of one error gets 202 and is counted, and a full project gets 403 ingest_cap_exceeded; Epure's 429 responses come only from sign-in, OAuth and API rate limits. A 429 on an error request therefore comes from somewhere else: Sentry itself, because the old DSN is still live, or a proxy or CDN between your app and Epure.

Check the request host first, as in the section on events still going to Sentry. If the host is Epure's and a proxy sits in front, look at the proxy's rate-limit rules for the /api/ path.

How do you keep test events from disappearing?

Most of these causes disappear with four settings checked once per runtime: the Epure DSN from Client Keys, an environment of production, staging or local, tracesSampleRate: 0, and no tunnelRoute. Name each test error uniquely, such as Epure check 2026-11-06 staging, so a new issue is easy to find and cannot group into an old one. The Sentry SDK compatibility matrix lists the SDK versions the ingest tests cover.

What if none of these causes fits?

When the response is 202, the environment is right and the issue still does not appear, collect three things: the SDK name and version, the request's status and body, and the id Epure returned. A 400 invalid_envelope or 400 invalid_event_json means the payload itself could not be parsed, which points to a custom transport or a proxy that rewrites bodies. Every code on this page is defined in the ingest route source. The full switch, with rollback, is in switch from Sentry and keep the Sentry SDK.