Work templates

Bug report template

A good bug report lets someone who has never seen the problem reproduce it on the first try, without having to message you back. This format puts the steps, the expected result and the actual result side by side, and it also records what you have not checked yet.

Free to copy and edit · October 29, 2026 · By Jerry Liu

A completed example

This fictional example shows the level of detail to aim for. It is not a customer's work history.

Bug report: Saved filters disappear after switching workspaces
Product: Ledgerline web app
Reported by: Priya N., Support
Date: 2026-10-06
Severity: Medium, a workaround exists
Environment: Chrome 129 on macOS 15.1, staging build 4.18.2, account role Editor

Summary:
A saved filter on the Invoices page is missing after switching to another workspace and back. It only comes back after a full page reload.

Steps to reproduce:
1. Sign in and open the workspace "Northfield Ops".
2. Go to Invoices, filter by Status = Overdue, click Save filter and name it "Overdue".
3. Switch to the workspace "Harbor Retail" from the top-left menu.
4. Switch back to "Northfield Ops" and open Invoices.

Expected result:
"Overdue" is listed under Saved filters.

Actual result:
Saved filters shows "No saved filters". Reloading the page brings "Overdue" back.

How often: 4 of 5 attempts on staging. Not tried on production yet.

Attachments:
- Screen recording: overdue-filter-missing.mov
- Console log showing a 404 on /api/filters at 10:42

Workaround: Reload the page after switching workspaces.

Not yet checked:
- Firefox and Safari
- Viewer role
- Whether filters saved before 4.18.0 are affected

Notes: First reported in a customer ticket on Oct 3, shortly after the 4.18.0 release. Cause not known.

Make it yours

Your draft

No sign-up

The example is fictional. Edits stay in this page and disappear when you leave. Copy or download your work to keep it.

Replace your draft?

Your edits will be replaced. Copy or download them first if you want to keep them.

How to fill it in

  1. Write the title last, naming the action and the failure so someone can find it in a search of the tracker.
  2. Reproduce the bug once more from a clean start and write each step as you do it, including the exact values you typed.
  3. Copy error messages word for word into Actual result instead of paraphrasing them.
  4. List what you have not tested under Not yet checked so the developer knows where the gaps are.
  5. Attach a screenshot or recording and note the time it happened so it can be matched to server logs.

Start from your actual work

On a Mac, Dayflow can help you remember the work behind the update. It drafts a timeline from screen activity. Export a date range as Markdown from Settings → Export. Review that record alongside your calendar and task tracker, then fill in the template above.

For a guided walkthrough, see exporting your work history or drafting a report with Claude Code. Check the assistant's draft before sending it.

Local AI keeps screenshot analysis on-device. Your own cloud provider or Dayflow Pro processes selected screenshots off-device. An assistant can receive the Dayflow data it retrieves in your conversation. Local storage does not make a cloud assistant conversation local. Read the data-flow guide before choosing a workflow.

Questions about this template

What should a bug report include?

At minimum: a clear title, the environment (device, browser, version, account type), numbered steps to reproduce, the expected result and the actual result. Add how often it happens, attachments such as screenshots or logs, any workaround, and what you have not tested. Missing steps or a missing version number are the most common reasons a bug gets sent back.

How do I write good steps to reproduce?

Start from a known state, such as a fresh sign-in, and write one action per line. Include exact values, menu names and button labels. Follow your own steps once more before submitting. If the bug only happens sometimes, say how many tries it took, and note anything that seemed to matter, like timing or a specific account.

What is the difference between severity and priority in a bug report?

Severity describes how badly the bug affects users, such as data loss versus a cosmetic glitch. Priority is how soon the team will fix it, and it depends on roadmap, users affected and effort. The reporter usually suggests severity. Priority is normally set by whoever owns the backlog, so a bug report is not a decision on when it gets fixed.

Should a bug report explain the cause?

Only if you actually know it. A bug report records what you observed, not a diagnosis. Guesses written as facts can send a developer in the wrong direction. If you have a theory, put it in Notes and label it as a theory. Writing "Cause not known" is honest and useful.

How can I remember what I was doing before a bug appeared?

Write notes right after it happens, or keep a screen recording running while testing. On a Mac, Dayflow drafts a timeline of your day from screen activity, which can help you recall the apps and pages you used beforehand. Check the timeline against what you remember, and add anything that happened off screen.

Can I use this template in Jira, GitHub or a shared doc?

Yes. It is plain text with simple labels and hyphen bullets, so it pastes cleanly into most issue trackers, Word or Google Docs. In a tracker, you can move fields like Severity and Environment into the tool's own fields and keep the rest in the description.

Use the right format for the next step

Remember the work behind the update

Dayflow drafts a work timeline on your Mac. You decide what belongs in the report.

Download DayflowmacOS 14 or later · Free app · Local or your own AI provider