Blog
Why Sentry Misses CLI Failures
Exception trackers catch throws inside a process that initialized them. A CLI that exits 1 after printing a config error, or a sample that never imported the SDK, never becomes an event.
2026-08-13 · 6 min read · AethelLayer
Exit codes are not exceptions
sys.exit(1) after a printed config error is a clean shutdown. Sentry's default hooks do not treat it as a crash. The developer still left.
Wrap the CLI process. On a non-zero exit, keep stderr and stdout. Python and many Go CLIs print the useful line on stdout.
The SDK was never initialized
Evaluators fail during install, version selection, or the first login, before your init() runs. An exception tracker loaded in the server sample does not see any of that.
Put the probe on the first command in the quickstart, not after a successful authenticated call.
Grouping by stack hides a printed sentence
Two missing environment variables can share no stack at all. Group by the error code you printed. The message is evidence. The code is the bucket.
Do not upload the environment. Names of missing keys are safe. Values are not.
Keep the human draft
An exception tracker can open an issue by itself. That is a poor fit for a CLI on a stranger's laptop, where a token may sit in argv. Draft the issue. Let someone on your team send it.
The developers who never appear in Sentry are the ones the probe is for.
Keep reading
Capture the failure before they leave
Capture the failure before they leave. Book early access or talk to sales, then install @aethellayer/sdk when you are onboarded.