Why Developers Don't File SDK Bug Reports

A useful SDK report needs the command, the version, the stack, the environment, and a sentence about intent. The person who just watched auth login die already has a workaround in mind: another vendor, a raw HTTP call, or closing the laptop. Leaving is one gesture. Reporting is a form.

Consumer bug-report posts describe the same trade. The cost is attention, and the payoff is uncertain. For a developer evaluating your CLI, the payoff is even weaker. They do not work for you. They were trying to finish their own task.

Some failures never look like crashes. A retry hides a flaky token endpoint. An empty catch turns a 401 into a blank sample app. The dashboard stays green because the exception was swallowed before it became an event. Your support queue stays quiet for the same reason.

Telling evaluators to 'please file an issue' does not change that. The conditions have to change: the tool keeps the stack, asks one question while the terminal is open, and hands your team a draft. The developer should not have to become your QA department.

Keep the error code, exit status, command name, SDK version, runtime, and a redacted stack. Do not keep secrets, tokens, or request bodies. Then ask what they were trying to do. That sentence is the part no APM trace contains.

AethelLayer is built for that moment. It sits in the CLI, SDK, or API path, holds the failure, and drafts a GitHub issue. A person on your team still hits send.

Count probes that never existed as tickets before. If the same error code shows up from many hashed identities in a week, you have a doc or product bug, not a one-off. Fix the quickstart the same day the pattern repeats.

If you only learn about failures from people patient enough to open GitHub, you are measuring your friendliest users. Everyone else already left.