# 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:

```bash
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`](sdk-node.md#init)). 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](dsn-and-regions.md) |
   | `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](ingest-protocol.md) |
| `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](switch-from-sentry.md).

## `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](sdk-bundler-plugin.md#troubleshooting). 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](switch-from-sentry.md) 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.