How to turn a Sentry error into a useful bug-report draft
An error event can provide a strong starting point for a bug report when its context is preserved. The draft should explain the observed failure and what a developer still needs to reproduce it.
Start with the right material.
- What you provide
- one readable Sentry event with selected error and environment details.
- The intended result
- A report draft from readable error details without executing code.
How the workflow works.
Use the supplied error message, stack information and environment details. Separate the event's evidence from a proposed cause, and retain relevant references without exposing secrets or unrelated user data.
What to check in the result.
Check versions, timestamps and the scope of the affected event. A stack trace points to observed execution; it does not by itself prove the root cause or establish that a proposed fix works.
Preview the Markdown to check headings, lists and links as well as the words. Keep source references with the document so a reviewer can trace important statements back to the material you supplied.
Learn from the worked example.
The downloadable Markdown example shows one possible organization of the result. Read it alongside the source example and notice which statements are recorded facts, proposed wording or questions still needing an answer.
The supplied example is illustrative. It is not a recorded run on your data.
Download the example ↓Use it with your own material.
- Open the source you want to work with and activate WebAct on that tab.
- Copy the task from the hero, add any required fields or preferences, and review the proposed actions.
- Compare the first result with your source. Ask for a specific correction or refinement where needed.