Submitting Bug Reports

Bug reports are the core of Bugnet. Players submit them via the in-game SDK widget, and developers manage them through the web dashboard. Every report captures the information your team needs to reproduce and fix issues quickly.

Each bug report includes the following fields:

• Title — A short summary of the issue
• Description — Detailed explanation of the problem
• Steps to reproduce — How to trigger the bug consistently
• Expected behavior — What should have happened
• Actual behavior — What actually happened
• Platform — The OS or device where the bug occurred
• Game version — The build version the player is running
• Device info — Hardware details (GPU, RAM, screen resolution, etc.)
• Player email (optional) — For follow-up communication with the reporter

Reports can be submitted in three ways:

1. SDK widget — Players open the in-game overlay and fill out a report form without leaving the game
2. REST API — Submit reports programmatically via POST /api/projects/:slug/bugs
3. Dashboard — Team members can manually create bug reports from the web dashboard

# Submit a bug report via the REST API
POST /api/projects/:slug/bugs
{
  "title": "Camera clips through walls in Level 3",
  "description": "When moving into the corner near the waterfall...",
  "steps_to_reproduce": "1. Go to Level 3\n2. Walk to the waterfall\n3. Push into the corner",
  "expected_behavior": "Camera should stay behind the player",
  "actual_behavior": "Camera clips through the wall geometry",
  "category": "visual",
  "priority": "medium",
  "platform": "Windows",
  "game_version": "1.2.0"
}

Categories & Priority

Bug Categories

Bugnet organizes bugs into 8 categories so your team can quickly identify the type of issue and route it to the right person:

Priority Levels

Four priority levels control triage order and help your team focus on the most impactful bugs first:

Priority can be set when a bug is submitted and changed at any time by team members. Auto-Triage (Studio plan and above) can automatically suggest a priority based on the report content and player context.

Status Workflow

Bugs follow a status lifecycle that tracks them from initial report through resolution. Each status represents a distinct phase:

Status Transitions

Bugs typically move through statuses in this order: open → in_progress → resolved → closed. However, any team member with the appropriate role can change a bug's status to any other status at any time. Common transitions include:

• open → in_progress — A developer picks up the bug and starts working on it
• in_progress → resolved — The developer applies a fix and marks it for verification
• resolved → closed — QA or the reporter confirms the fix works
• resolved → open — The fix didn't work; the bug is reopened
• open → wont_fix — The team decides the behavior is intentional or out of scope

Who Can Change Status

Any team member with the developer or admin role can change a bug's status. Players who submitted the report can reopen a bug that was marked as resolved if they believe the issue persists.

Notifications

Status changes automatically trigger notifications. The assigned team member, the reporter (if they provided an email), and any team members watching the bug will receive an email notification when the status changes. Discord webhook notifications are also sent if configured in your project's integration settings.

Assignment

Assign bugs to specific team members to establish clear ownership and accountability. Assignment ensures every bug has a responsible developer and prevents issues from falling through the cracks.

• Assign from the dashboard — Open a bug and select a team member from the assignee dropdown
• Role requirements — Only team members with the developer or admin role can be assigned to bugs
• Email notifications — When a bug is assigned, the assignee receives an email notification with the bug details and a link to the dashboard
• Reassignment — Bugs can be reassigned to a different team member at any time. The new assignee is notified, and the change is recorded in the activity log
• Unassigned queue — Bugs without an assignee appear in a dedicated "Unassigned" queue in the dashboard, making it easy to find bugs that need attention

# Assign a bug to a team member
PATCH /api/projects/:slug/bugs/:id
{
  "assigned_to": "user-uuid-here"
}

Comments & Activity

Comments

Comments allow team members and players to discuss bugs, share additional context, and coordinate fixes. Bugnet supports two types of comments:

• Public comments — Visible to both team members and the player who submitted the report. Use these to ask the player for more details or to let them know a fix is coming
• Internal comments — Visible only to team members. Use these for technical discussion, debugging notes, or internal coordination that players don't need to see

Comments support rich text formatting, including bold, italic, code blocks, and links. Team members can also reply to bug notification emails to add comments directly from their inbox without opening the dashboard.

# Add a comment to a bug
POST /api/projects/:slug/bugs/:id/comments
{
  "body": "I can reproduce this on Windows 11. Looks like a Z-buffer issue.",
  "internal": true
}

Activity Log

Every change to a bug is automatically recorded in the activity log, providing a complete audit trail. The activity log tracks:

• Status changes — When a bug moves from one status to another
• Priority changes — When the priority level is updated
• Assignment changes — When a bug is assigned or reassigned
• Label changes — When labels are added or removed
• Comments added — When a new comment is posted

Each activity entry shows who made the change and when it happened, so your team always has full visibility into a bug's history.

File Attachments

Attach screenshots, log files, save files, and other documents to bug reports to provide additional context for your team. Visual evidence and crash logs are often the fastest way to diagnose an issue.

• SDK auto-capture — When a player opens the bug report widget, the SDK automatically captures a screenshot of the current game state and attaches it to the report
• Manual upload — Team members and players can drag and drop files or use the upload button in the bug detail view
• Storage backends — Files are stored using S3-compatible storage (AWS S3, DigitalOcean Spaces, MinIO, etc.) or local file storage for self-hosted deployments
• Authenticated access — Attachments are served with authentication. Only team members and the player who submitted the report can access the files, ensuring sensitive data like save files and crash logs remain private

Bulk Operations

When managing a large number of bugs, bulk operations let you take action on multiple reports at once. Select bugs from the bug list view in the dashboard using the checkboxes, then choose a bulk action from the toolbar.

Available bulk actions:

• Change status — Move multiple bugs to a new status at once (e.g., close all resolved bugs after a release)
• Change priority — Reprioritize a batch of bugs simultaneously
• Assign to team member — Assign multiple bugs to a developer in one click
• Add labels — Tag multiple bugs with the same label for organization
• Remove labels — Remove a label from multiple bugs at once

Bulk operations are available from the bug list view in the dashboard. Select the bugs you want to modify using the checkboxes on the left, then use the bulk action toolbar that appears at the top of the list.

Upvoting

Players can upvote bug reports they have also experienced, helping your team understand how widespread an issue is and prioritize accordingly.

• Upvote count — The number of upvotes is displayed in both the bug list and the bug detail views
• Prioritization signal — Bugs with more upvotes are more impactful and should generally be addressed first. Sort by upvotes to see the most-reported issues at a glance
• Public bug tracker — If you have enabled the public bug tracker for your project, players can browse and upvote existing bugs directly from the public page, reducing duplicate submissions
• One vote per player — Each player can upvote a bug only once to keep counts accurate

Duplicate Detection

Duplicate bug reports create noise and fragment the information your team needs. Bugnet uses similarity matching to flag potential duplicates and help consolidate related reports.

• Automatic suggestions — When a player or team member submits a new bug, Bugnet analyzes the title and description against existing reports and suggests similar bugs before submission
• Similarity matching — Reports are compared using text similarity on the title and description fields to identify potential duplicates
• Noise reduction — By catching duplicates early, your team spends less time triaging repeat reports and more time fixing bugs
• Consolidation — When a duplicate is identified, relevant information from the new report can be merged into the original bug

# Find similar bugs before submitting
POST /api/projects/:slug/bugs/similar
{
  "title": "Camera clips through walls",
  "description": "The camera goes through wall geometry in certain corners"
}

# Response: list of similar existing bugs with similarity scores

Search & Filtering

Bugnet provides powerful search and filtering tools to help you find exactly the bugs you are looking for, even across projects with hundreds or thousands of reports.

Full-Text Search

Search across bug titles and descriptions using the search bar at the top of the bug list. Full-text search matches partial words and is case-insensitive.

Filters

Narrow down your bug list using any combination of the following filters:

• Status — Filter by open, in_progress, resolved, closed, or wont_fix
• Priority — Filter by critical, high, medium, or low
• Category — Filter by any of the 8 bug categories
• Platform — Filter by the platform the bug was reported on
• Game version — Filter by the game build version
• Assignee — Show bugs assigned to a specific team member, or show only unassigned bugs
• Labels — Filter by one or more labels
• Date range — Show bugs created or updated within a specific time period

Saved Filters

Combine multiple filters into a saved filter that you can reuse with one click. Saved filters are shared across your team and appear in the sidebar of the bug list. See the Project Management docs for more details on creating and managing saved filters.

Sorting

Sort your bug list by any of the following fields:

• Created date — Newest or oldest bugs first
• Updated date — Most recently active bugs first
• Priority — Critical bugs at the top
• Upvotes — Most-reported issues first

Bug Dependencies

Some bugs are related to or depend on other bugs. Bugnet lets you create dependency relationships between bugs so your team can plan the fix order and understand how issues are interconnected.

Dependency Types

• Blocks — This bug must be fixed before the linked bug can be addressed
• Blocked by — This bug cannot be fixed until the linked bug is resolved

Working with Dependencies

• Create dependencies — Open a bug's detail view and add a dependency link to another bug by ID or by searching for it
• Dependency chains — View the full chain of dependencies in the bug detail view to understand the order in which bugs need to be fixed
• Cross-project support — Dependencies can span across different projects, which is useful when a shared library or engine bug affects multiple games
• Fix planning — Use dependency information to plan your sprint or patch schedule. Bugs that block many other bugs should generally be fixed first