Quick answer: Yes, but keep it extremely lightweight. A full issue tracker like Jira is overkill for a 48-hour jam. Instead, use a simple text file, sticky notes, or in-code TODO comments. The goal is to spend less than 10 seconds recording each bug so you can decide later whether to fix it or ship with it.

Learning how to track bugs during game jam is a common challenge for game developers. You have 48 hours to build an entire game from scratch. The last thing you want is to lose 30 minutes setting up Jira. But shipping without any bug tracking means you will forget what is broken, fix the wrong things, and submit a build that crashes on the judge’s machine. Here is how to track bugs during a game jam without losing your momentum.

Why Bug Tracking Matters Under Time Pressure

Game jams compress an entire development cycle into a weekend. You will write code faster than usual, skip tests, copy-paste solutions, and make architectural decisions you would never make in production. Bugs are inevitable. The question is whether you know about them when it matters.

The most common failure mode is not a lack of skill. It is submitting a build with a crash you noticed four hours ago, forgot about, and never fixed. A simple tracking system prevents this. It does not need to be sophisticated. It needs to exist.

Method 1: The Shared Text File

The simplest approach is a BUGS.md file in your project repository. Every team member can edit it. Every bug gets one line. This works surprisingly well for teams of two to four people.

# BUGS.md — Game Jam Bug Tracker
# Format: [SEVERITY] Description — Status

[CRASH] Game freezes when entering level 3 door — FIXING
[CRASH] Null reference on player death if no checkpoint — FIXED
[BLOCK] Cannot pick up key item after dropping it — TODO
[MINOR] Player sprite flickers during dash — WONTFIX
[MINOR] Sound effect plays twice on double jump — WONTFIX
[MINOR] Health bar overlaps score text at 4:3 ratio — WONTFIX

Three severity levels are enough: CRASH for anything that stops the game, BLOCK for issues that prevent progress but do not crash, and MINOR for everything else. Three statuses: TODO, FIXING, and FIXED. Add WONTFIX for bugs you have consciously decided to ship with.

Method 2: In-Code TODO Comments

When you are deep in a coding session and discover a bug in the function you are writing, switching to a separate file breaks your flow. Instead, leave a TODO comment directly in the code. Use a consistent tag so you can search for them later.

func take_damage(amount: int) -> void:
    health -= amount
    # JAMBUG: health can go negative, causes underflow in UI
    if health <= 0:
        die()

func collect_item(item: Node2D) -> void:
    # JAMBUG: picking up item during death animation crashes
    inventory.append(item)
    item.queue_free()

The JAMBUG prefix is arbitrary. Pick any unique string that does not appear in your codebase naturally. Before submission, search for it across all files:

# Find all unresolved jam bugs before submission
grep -rn "JAMBUG" --include="*.gd" .
grep -rn "JAMBUG" --include="*.cs" .

This gives you a complete list of known issues with file names and line numbers. You can triage them all at once in the final hour.

Method 3: The Quick Spreadsheet

For larger jam teams (four or more people), a shared Google Sheet or Notion table adds just enough structure. Use four columns: Bug, Severity, Who, and Status. Do not add more columns. Every additional field is friction that makes people skip the tracker and just yell across the room instead.

Pin the link in your team Discord channel. Make it the first message everyone sees. If someone reports a bug verbally, the rule is simple: it does not count until it is in the sheet.

Method 4: Sticky Notes for Solo Jammers

If you are jamming solo, physical sticky notes on your monitor work well. One color for crashes, another for gameplay bugs, a third for polish issues. When you fix one, crumple it up and throw it away. There is something satisfying about the physical feedback that keeps you motivated at hour 36.

The downside is that sticky notes do not survive the jam. Take a photo of your remaining notes before submission so you have a record for post-jam cleanup.

What to Fix vs. What to Ship With

This is the hardest decision in a game jam. Every bug fix costs time that could be spent on gameplay, art, or audio. Here is a decision framework:

Always fix: crashes on startup, crashes during the core gameplay loop, softlocks that prevent reaching the end of your game, save corruption if your game has saving, and any bug that makes the game unplayable on common hardware.

Fix if time allows: bugs in secondary mechanics, visual glitches that are distracting but not game-breaking, audio issues like sounds not playing, and balance problems that make the game too easy or too hard.

Never fix during the jam: edge cases that require unusual inputs to trigger, visual polish on placeholder art you plan to replace, performance optimization unless the game is literally unplayable, and any bug that requires architectural changes to resolve.

A good rule of thumb: if the fix takes less than five minutes and the bug affects the main path through your game, fix it immediately. If the fix takes more than fifteen minutes and the bug is off the main path, mark it as known and move on.

The Final Hour Triage

One hour before the submission deadline, stop adding features. Open your bug list and go through every item. For each bug, make one of three decisions: fix it now, document it as a known issue, or accept it silently.

# Final hour triage checklist
# 1. Search for all JAMBUG comments
grep -rn "JAMBUG" --include="*.gd" .

# 2. Run the game from a clean start
#    - Can you reach the end without crashing?
#    - Does the main mechanic work?
#    - Does audio play?

# 3. Test the export build, not the editor
#    - Export bugs are the #1 surprise at submission time
#    - File paths that work in editor break in export
#    - Autoloads that were never added to export presets

The most dangerous bugs at submission time are export-related. Your game runs fine in the editor but crashes when exported because a resource was not included, a file path uses res:// where it should use user://, or an autoload was not properly configured for export. Always test the exported build, not the editor build.

Post-Jam Cleanup

If you plan to continue developing your game after the jam, the first task is transferring your bug notes into a proper tracker. Go through your BUGS.md, your TODO comments, and any sticky note photos. For each bug, decide whether it still matters in the context of continued development.

Many jam bugs become irrelevant when you start replacing placeholder systems. The health underflow bug does not matter if you are rewriting the health system entirely. The flickering sprite does not matter if you are replacing all the art. Focus your post-jam energy on bugs that will survive the rewrite.

For bugs that do survive, assign proper severity levels and move them into whatever tracking system you use for long-term development. This is also a good time to add crash reporting to your game so that playtesters and early players generate structured reports instead of Discord messages that say "it broke."

"The difference between a game jam entry that gets played and one that gets skipped is usually one crash on the judge’s machine. Track your bugs. Fix the crashes. Ship everything else."

Related Issues

If your jam game is growing into a full project and you need a more structured approach, see our guide on the best bug tracking tools for solo game developers. For prioritizing the backlog that comes out of a jam-turned-project, our article on how to prioritize game bugs after early access launch covers the triage framework in detail.

Track the bug in 10 seconds or forget it forever. In a game jam, there is no middle ground.