Skip to content
bucker

If nothing arrives

The most common support question is "I sent an event and nothing happened". Bucker can usually say why, because it records every classified drop. This page is organized by the verdict vocabulary the product uses for the same question, so the name you read here is the name you will see in the dashboard and the CLI.

What exists today. The dashboard's first-event listener polls and shows two states, waiting and received. The six-verdict diagnosis (GET …/onboarding/diagnosis) is specified but not shipped, so for now you work through the checks below by hand. They are ordered the way the diagnosis will order them, and every check names the evidence that settles it. A verdict that depends on a feature that is not built is marked (not yet surfaced).

Work top to bottom: each section assumes the ones above it have been ruled out.

waiting: nothing addressed to this project has reached us

This is a fact, not a spinner. Either the SDK has not run, or it cannot reach us. Separate the two with one command from the machine that runs your app:

curl -i https://us.ingest.bucker.io/api/<projectId>/envelope/ -X POST

(Use the host from your own DSN, which is region-prefixed.) A 401 is the good answer: it proves DNS, TLS, your proxy and any egress filter let you through, and that you were refused only for sending no credential. A connection error or a timeout means your network is eating the request.

nothing_reached_us: the SDK did not run, or it cannot egress

Take these in order. Each one rules something out.

  1. The SDK is initialized, and early. Crash handlers installed after the rest of the app has evaluated do not cover the app evaluating. The init module must be the first import (@bucker/node). Run the verify artifact that create-bucker wrote (bucker-verify, or the /bucker-verify route); it throws on purpose.

  2. The DSN is loaded in the running process. echo $BUCKER_DSN in your shell proves nothing about the container or serverless function that is actually running. The SDK does not throw on a bad DSN; it disables itself and logs once, so look in the process's own log for:

    Warning Meaning
    no DSN is configured, so the SDK is disabled The env var is empty in that process
    the configured DSN could not be parsed (<reason>) A broken copy; see DSNs
    the DSN still contains the documentation placeholder for its public key You pasted the example, not your DSN

  3. The DSN is shaped right. https, a region-prefixed host (us.ingest.…), exactly one path segment, and no password half. Bucker DSNs never carry a secret.

  4. The event was not discarded client-side. sampleRate below 1, a before_send returning nothing, or a rate limit all drop events before the network. These are not silent: they come back as a client_report and show as client_discard on the drops panel (Billing → What we dropped, and why).

  5. The process lived long enough to send. A short-lived process (a script, a serverless function) must await flush() / call bucker_sdk.flush() before it exits. The Node and Python SDKs flush on exit within a bounded timeout; a process killed with SIGKILL flushes nothing.

  6. Browser only: an extension or content blocker. Ad and privacy blockers refuse requests to some telemetry hosts. Try an incognito window with extensions off. A blocked request shows in the browser's network panel as blocked, not as a 4xx.

auth_failed: something reached us with a key we do not recognise

The request arrived and was refused with a 401. The key in the DSN does not match a live key:

  • the DSN was copied partially (a truncated public key);
  • the key was rotated or disabled in Settings → Projects, and the app still has the old one;
  • the DSN belongs to a different environment's project (staging key in production, or the reverse).

Re-copy the DSN from Settings → Projects → Keys and compare it character by character with the one the running process has. (Not yet surfaced: the product does not yet say "a key we do not recognise" on the onboarding screen; today it is a 401 in your SDK's debug output.)

rejected: we received it and refused it

The envelope reached us and was refused with a reason. Every one of these is recorded as an outcome, and the What we dropped, and why panel on the Billing page explains each in a sentence:

Outcome What it means What to do
too_large The envelope exceeded the maximum size Reduce breadcrumbs or captured values
rate_limited The project key exceeded its per-minute limit, or the project is suspended by an operator The SDK backs off on X-Sentry-Rate-Limits and counts what it dropped. A suspended project says so in its drop reason
quota_exceeded The project passed the hard ceiling above its plan volume Sampling degrades traffic first; this is the ceiling after that. Raise the plan or the ceiling
invalid The envelope failed parsing or validation Usually a hand-built client; see the wire protocol
sampled Over plan volume, so traffic is being sampled, not refused Expected; new fingerprints are still kept at full fidelity

An envelope is also accepted but partly dropped when it carries an item type Bucker does not consume yet. That is not an error and the envelope is not refused: each unconsumed item is recorded as an unsupported_item_type drop. This is the case to check if you point an unmodified Sentry SDK at Bucker and see errors but no performance data; see the support matrix in switch from Sentry.

accepted_not_grouped: it was accepted, and the worker has not written the issue yet

Ingest answering 200 means the envelope was queued, not that an issue exists. The worker is what turns it into an issue. When the queue is behind, "accepted" and "no issue yet" are both true, and from outside it looks identical to nothing having arrived.

  • Give it a minute. Over quota, ingest degrades to sampling rather than dropping silently, so a verify event can be delayed but should not vanish.
  • Check the drops panel (Billing → What we dropped, and why): an accepted count that rises while no issue appears is this verdict.

received: it arrived

The event is in the issue list. If the issue is there but its stack trace is minified, that is a symbolication problem and not an arrival problem: see the bundler plugin. If sessions or release health are blank, the SDK was not given a release, and without one it sends no sessions.

accepted_unsupported_items: a Sentry SDK reported, but only things that are not consumed yet (not yet surfaced)

One more verdict is planned for people switching from Sentry: a Sentry SDK is reporting, and everything it sends is an item type Bucker does not consume yet (for example only transaction items from an SDK with error capture turned off). Today this looks like waiting. If you are in that position, the support matrix in switch from Sentry tells you which item types are consumed.

Still stuck

Capture a single deliberate event with the verify artifact, note its time, and look at the drops panel for that minute. Whatever outcome row appears (or none) is the verdict. If there is no row at all, the request never reached us, and the answer is in sections waiting and nothing_reached_us above.