What should a public known-issues page include?

For each issue: a plain-language symptom description players will recognize, the current status, a workaround if one exists, and ideally the date noted. The workaround is what makes the page genuinely useful, telling players how to avoid a bug keeps them playing while you fix it.

Should I list embarrassing bugs on my known-issues page?

Yes. Omitting the issue everyone is hitting makes players conclude you are hiding it, which is worse than having no page. Honesty is a competitive advantage, openly showing problems being worked through builds more trust than pretending everything is fine.

How do I keep a known-issues page from going stale?

Drive it from the same issues you already track rather than maintaining a separate document. A public tracker that mirrors your real issue statuses updates automatically when you change a status, so the page never drifts out of sync and updating it costs no extra work.

How to Write a Public Known Issues Page for Your Game

Quick answer: List the real active issues with plain-language descriptions, current status, and any workaround, keep it current, and put it where players look. A good known-issues page deflects duplicates, reassures players, and signals competence, all at once.

A public known-issues page is one of the highest-leverage support assets an indie studio can have. It deflects duplicate reports, reassures players that you are aware of problems, provides workarounds that keep people playing, and signals a level of professionalism that builds trust. The hard part is not building it, it is keeping it honest and current.

What Belongs on the Page

Each entry needs four things: a plain-language description of the symptom the player would recognize, the current status (acknowledged, in progress, fixed), a workaround if one exists, and ideally the date it was first noted. The workaround is what turns the page from a list of problems into a genuinely useful tool, "until we fix this, you can avoid it by doing X" keeps players playing.

Write the descriptions from the player's point of view, not the code's. "Audio cuts out after alt-tabbing" is recognizable; "AudioContext suspended on focus loss" is not. Players should be able to find their issue by matching the symptom they are experiencing.

Keep It Honest and Current

The fastest way to ruin a known-issues page is to let it go stale or to omit the embarrassing bugs. If the page does not list the issue everyone is hitting, players conclude you are hiding it, which is worse than having no page. List the real problems, including the painful ones, and update status promptly. Move fixed items to a 'recently resolved' section so players who waited can confirm.

Honesty here is a competitive advantage. A page that openly admits current problems and shows them being worked through builds more trust than a glossy page that pretends everything is fine.

Let Your Tracking Tool Generate It

Maintaining a separate known-issues document by hand guarantees it will drift out of sync with reality. The sustainable approach is to drive the public page from the same issues you are already tracking, so updating a status in your tracker updates what players see. Bugnet's public tracker and roadmap pages do exactly this: you mark issues public and their live status appears for players automatically, no duplicate document to maintain.

This also closes the loop with reporters. When the issue they reported is on the public page and they can watch it move to fixed, the known-issues page becomes proof that reporting bugs to you works.

A known-issues page that hides the worst bug is worse than no page at all.