Quick answer: Pull the numbers from your tracker on a fixed day each week, write a short narrative explaining what moved, and publish three variants — executive summary, developer details, QA tactical view. Same time, same format, every week. The discipline beats the template.
A weekly bug status report is one of those boring-sounding rituals that turns out to be quietly load-bearing. Without one, every stakeholder has a different mental model of how things are going. With one, your team has a shared picture: what’s actually happening to quality, where the risks are, and what’s getting fixed next. Done right, it takes an hour to produce and saves many hours of meetings and confused Slack threads.
The Core Numbers
Every report starts with the same set of metrics, pulled from your bug tracker’s API:
- New this week: count of bugs reported in the last seven days, broken out by priority.
- Fixed this week: count of bugs marked resolved.
- Net change: new minus fixed — positive means the backlog grew.
- Still open: total open by priority at end of week.
- Median age (open): half of open bugs are older than this.
- Top crashes: the five highest-impact crash signatures by session impact.
- SLA compliance: percentage of P0/P1 meeting response and resolution targets.
Automate the pull. You should not be hand-counting these on Monday morning. A small script that queries the tracker API and dumps a Markdown table takes a couple of hours to write and pays back every week forever.
#!/usr/bin/env python
import datetime, requests, os
API = "https://api.bugnet.io/api/v1"
TOKEN = os.environ["BUGNET_TOKEN"]
now = datetime.datetime.utcnow()
since = (now - datetime.timedelta(days=7)).isoformat()
def q(path):
return requests.get(API + path,
headers={"Authorization": f"Bearer {TOKEN}"}).json()["data"]
new = q(f"/bugs?created_after={since}")
fixed = q(f"/bugs?status=resolved&resolved_after={since}")
open_ = q("/bugs?status=open")
print(f"New: {len(new)} Fixed: {len(fixed)} Open: {len(open_)}")The Narrative
Numbers without narrative are worse than no report. The reader needs to know what to pay attention to. Two to four short paragraphs is plenty, covering:
Trend this week. “Open P0/P1 dropped from 18 to 12, driven by yesterday’s hotfix. Net backlog grew by 22 reports, mostly P3 cosmetic issues from the UI revamp.”
Hotspots. “The Steam Deck save-corruption bug is our top priority. Reproduced internally; fix expected Thursday. A new cluster of audio crashes on Windows 11 24H2 appeared Wednesday; assigned to James.”
Upcoming. “Next patch (1.4.2) scheduled for Monday will include the save fix and five P1 fixes. Hotfix 1.4.3 may follow later in the week depending on the Windows audio investigation.”
Risks. “SLA compliance on P2 bugs has dropped for three weeks running — we have 40 P2 bugs older than 30 days. Propose dedicating Tuesday of next week to a P2 sweep.”
The Three Versions
Same data, three audiences. Don’t try to unify them.
Executive summary. Five bullets and a trend arrow. “Quality trending up” or “Quality trending down, investigating.” Names of top three risks. One line on delivery impact: “Still on track for May 15 release.” Execs don’t need to see signatures; they need to know whether to be worried and whether to unblock anything.
Developer report. Full numbers, top crash signatures with links, per-module breakdown if you have one. This is what engineers read first thing Monday to orient their week. Include upcoming scheduled work and known blockers.
QA report. Focus on aging, triage queue depth, SLA compliance, and any signatures that need reproduction work. This is where you assign the week’s QA effort and flag incoming test-plan work for the next patch.
The fastest way to kill a status report is to send the same wall of numbers to everyone. Each audience stops reading once they realize it isn’t written for them. Three tailored versions take fifteen minutes more to produce and get read three times as often.
Cadence and Discipline
Send it the same time every week. I prefer Monday morning — it sets context for the week and captures the weekend’s reports. Some teams prefer Friday so the report closes out the week; pick one and stick to it. The pattern-recognition value of a report comes from the consistency.
Keep it short enough to fit on one screen for the exec version. The detailed version can be longer but should start with the same summary bullet list so a skim works.
What to Skip
Do not include every bug by name. Do not list every engineer’s per-ticket progress. Do not paste the entire SLA dashboard. Those are appendices at best. The report should be the analysis, not the raw data. Link to the dashboard for drill-down.
Do not make it a team brag sheet. “We fixed 47 bugs this week” is less useful than “we fixed 47 bugs, including the top three crashes that were blocking the Steam Deck rating.” Impact, not effort.
After a Few Weeks
Once you’ve been sending the report for a month, the week-over-week deltas become the most valuable part. A table that shows the last six weeks of new, fixed, open, median age, and SLA lets readers spot trends instantly. A single-week number is almost useless in isolation; six weeks tells you whether quality is getting better or worse.
Related Issues
For the SLA instrumentation that feeds this report, see how to set up a bug report SLA for your studio. For the broader metrics menu, read bug reporting metrics every game studio should track.
A weekly report is the smallest dose of truth an organization can reliably swallow. Send it every week and the truth compounds.