Bug Report

Describe the bug out loud — get a report you can paste into your tracker

What it makes

incident summary

Development

Real output

An everyday bug, filed as a tracker-ready ticket

A quick spoken report of a bug hit mid-work, with no environment or severity stated.

What you said

So the save button on the settings page doesn't actually save when I click it. It just does nothing, no spinner, no error, nothing. I tried refreshing the page and clicking it again and it's the same thing. Um, I'm pretty sure it was working last week.

What you got

Save button on settings page does nothing on click

Summary

Clicking the Save button on the settings page produces no response — no spinner, no error, and no confirmation. The issue persists after a page refresh. The speaker believes it was working as recently as last week.

Steps to Reproduce

Navigate to the settings page.
Click the Save button.

Actual Behavior

Nothing happens. No spinner, no error message, and no confirmation is shown. Changes do not appear to be saved.

Notes

Reported as a regression — the Save button was working as recently as last week.

Assumptions

Environment: Not specified. The affected version, build, browser, OS, and whether this is on staging or production are all unknown.
Severity: Not stated. Given that saving settings is non-functional, this may be high priority, but severity has not been confirmed by the reporter.
Blast radius: Unclear whether this affects all users or a specific account, and whether it is consistent or intermittent.

Why it’s better

Every fact you gave survives — the dead Save button, the failed refresh, the "worked last week" regression hint — restructured into a titled, scannable ticket. And the three things you did not say (which environment, how severe, how wide the blast radius) come back as explicit Assumptions for the triager to confirm, not as invented values. Nothing is fabricated; nothing actionable is dropped.

A symptom and a hunch — filed without inventing the cause

A spoken report that includes the speaker's own guess at the root cause.

What you said

OK so the live recording keeps dropping the connection after about, I don't know, thirty seconds or so. The websocket just dies on you. I think — and I'm really not sure about this — I think it might be the auth token expiring and the server killing the connection? That's just my guess though. It's pretty annoying because you lose your whole recording when it happens. This is on the live page. I haven't really nailed down the exact steps to trigger it but it's pretty consistent, like always around the half a minute mark.

What you got

Live recording WebSocket drops connection after ~30 seconds, losing the recording

Summary

On the live page, an active recording consistently drops its WebSocket connection at approximately the 30-second mark. When this happens, the entire recording is lost.

Actual Behavior

The WebSocket connection dies roughly 30 seconds into a live recording. The full recording is lost when this occurs.

Steps to Reproduce

Not specified — see Assumptions.

Notes

Speaker suspects the auth token may be expiring server-side and triggering the disconnection, but flagged this explicitly as a guess with no supporting evidence.

Assumptions

Repro path: No specific steps to trigger the issue were given. It is reported as highly consistent (~always at the 30-second mark), so a reliable repro may be straightforward to find — but it has not been documented yet.
Environment: No browser, OS, device, build, or deployment target (staging vs. production) was specified.
Severity: The speaker described losing the full recording as "pretty annoying," but did not assign a severity or indicate whether this is blocking. Severity should be confirmed by the triager.
Blast radius: Unclear whether this affects all users on the live page or is isolated to a specific account, session type, or configuration.

Why it’s better

You guessed the auth token might be expiring — and the report keeps that as exactly what it is: a suspected cause, attributed to you and marked unverified, that "should not drive investigation without verification." A generic formatter would promote your hunch to the diagnosis and send a developer down a false trail. The missing repro steps and environment are flagged rather than invented, and the real signal — drops at ~30 seconds, recording lost — leads the report.

What comes back

Report size tracks input size: a one-line "the button is broken" stays a title, a summary, and the gaps it leaves open; a full incident gets the complete section set.
Technical specifics are preserved verbatim — the exact error string, identifiers, URLs, and version numbers you said, unchanged, because that is what a developer searches on.
It resolves your self-corrections ("staging — no, production") and keeps your genuine alternatives ("Chrome, or maybe Safari") as the real ambiguity they are.
A suspected cause you floated stays a flagged suspicion in the report, attributed to you and marked unverified — it never hardens into the stated root cause.

What you can count on

Won't invent — no fabricated repro steps, versions, environments, or error messages you didn't state
Severity is read, not assigned — it uses your words ("critical," "blocking"), never a rating guessed from your tone
Never diagnoses — your hunch about the cause is recorded as a guess, so no one chases a false trail

Install Bug Report and try it on your own voice.

Is this hat for you?

Shapes a spoken bug into a structured, tracker-ready incident report.

Bug Report turns a spoken, out-of-order description of something that broke into a clean, tracker-ready incident summary a developer can act on in seconds. It captures exactly what you observed — the symptom, the steps, the exact error text, the environment — and surfaces what's still missing as explicit questions a triager needs answered. The discipline is the moat: it never invents the parts you didn't say. It won't fabricate repro steps, a version number, or an environment; it won't rate something "critical" from your tone when you didn't set a severity; and when you guess at the cause out loud, it records your guess as a guess instead of sending a developer down a false trail. You describe the bug; it files the ticket — honestly.

Best for

A bug you hit mid-work — "the export button on the reports page does nothing" comes back as a titled report with the missing repro, environment, and severity flagged for the triager
A rich incident — a crash with steps, an exact console error, and a browser version: it lays out Severity, Steps to Reproduce, the verbatim error, and Environment, ready to paste into your tracker
A bug where you have a hunch about the cause — it records your suspicion as an unverified guess, never as the diagnosis, so nobody chases a false lead
A panicked, vague report ("everything froze, I think I lost work") — it stays calm and structured, flags what is unknown, and keeps "possible data loss" honest instead of asserting it

Not for

A feature request or implementation task — reach for Developer Elite (a full spec) or Delegate (a brief for a teammate)
A quick message, status update, or email — reach for Work Email, Clarity, or Casual Convo
Diagnosing or fixing the bug — it organizes and surfaces what was reported; it does not investigate or propose a root cause
A meeting recap or personal note — reach for Meeting Notes or Voice Journal

Using it

How it works

Just describe what broke — the symptom, any steps, where it happened, the error you saw. Bug Report shapes it into an incident summary.
It leads with the defect: a specific title and a one-line summary a triager can judge priority from, then only the sections you gave material for — Steps to Reproduce, Actual Behavior, Environment, and so on.
It records only what you said. A missing repro path, an unknown environment, or an unset severity becomes a flagged Assumption — never a fabricated value.
It reads severity from your words ("this is blocking the release") but never assigns one from your tone alone — if you did not set it, it asks the triager to.

Try saying

the export button on the reports page is broken, it just does nothing when you click it
checkout crashes to a white screen when you place an order with two or more items in the cart, there's a TypeError in the console, this is on production and it's blocking the release
the live recording keeps dropping the connection after about thirty seconds, I think it might be the auth token expiring but that is just a guess

Tips

Say the exact error text if you have it ("it says TypeError cannot read properties of undefined") — it is preserved verbatim, because that is what a developer searches on.
If you know how bad it is, say so ("this is blocking the release") — severity is read from your words, and left for the triager when you do not.
Don't worry about filling in every field — say what you know. The gaps you leave become flagged questions, not invented answers.