How to track bugs without Jira

Bug tracking is the original use case for an issue tracker. It's also the use case Jira has slowly buried under a decade of enterprise features, custom workflows, permission schemes, and screen configurations that nobody on the development team wanted in the first place.

If you've ever spent half a morning trying to convince a Jira admin to add a single field to a bug screen, or watched a freelancer sigh at yet another login to yet another bloated dashboard just to file a regression, this post is for you. Here's how to run a bug tracker that takes minutes to set up, costs less per seat than a coffee, and still does everything a working dev team actually needs - without Jira.

What "tracking a bug" actually requires

Strip away the project-management theatre and a real bug tracker needs to do five things:

1. Capture the report fast, with enough context to reproduce it.
2. Plan it: priority, severity, owner, target release.
3. Show you what's open, what's in flight, and what's blocked, at a glance.
4. Tie the fix back to the code (commit, branch, PR, deploy).
5. Keep the conversation in one place so the next person doesn't have to ask.

That's the whole list. Everything Jira layers on top is optional, and most of it costs you focus before it ever earns its keep.

A board that fits a bug workflow

In Todo4you every project defines its own statuses under Settings -> Statuses. For a bug-focused project a workflow like Reported -> Planned -> In progress -> In review -> Verified -> Closed takes about a minute to set up. Each status has a category (backlog, todo, active, review, done) and the rest of the system, including reports and automations, keys off the category - not off hardcoded names. So you can split In review into Code review and QA, or add a Cannot reproduce column, without breaking anything.

The board ships with the things you'd expect: drag and drop with live updates, list view, calendar view, hide and minimize columns per user, and dark mode that actually works in both themes. No screen schemes, no workflow conditions, no admin role required.

Capturing reports without friction

Jira's biggest tax is the moment you ask a non-developer to file a bug. Todo4you has three ways to capture reports that don't make the reporter open a kanban board:

• Inbound email. Each project gets its own intake address. Mail to it lands as a ticket, with the subject as the title, the body as the description, and any attachments and inline images preserved. Reply on the resulting ticket and the reporter gets the reply by email. Forward a customer complaint and you have a ticket without leaving your inbox.
• The MCP server. If you live in Claude, Cursor, or another MCP-aware assistant, you can say "Create a ticket in WEB: title 'Checkout button stuck on Safari iOS', describe what I just told you, tag it ios and bug, assign it to me" and it lands on the board. No tab switch.
• The REST API. Anything the UI does is available under /api/v1/*. Wire your own crash reporter, support form, or status page to POST /api/v1/tickets and bugs file themselves.

Every ticket carries the fields you actually need: a stable reference like WEB-42, a markdown description, a checklist for repro steps, blockers, tags, assignees, priority, deadline, time estimate, and attachments. Images render inline in comments, and there's a built-in annotation tool for circling the broken bit on a screenshot - which is what a bug report usually needs anyway.

Planning without a permission scheme

Severity, area, and customer impact are just tags. Tags are per project, colored, and you filter any view by any combination. A common starter set: bug, regression, critical, customer-reported, plus an area tag per part of the codebase (auth, billing, mobile). Tag filtering combines with assignee and status filters on every view, so "all open critical bugs assigned to me" is two clicks.

For repeat plan work there are Flows, which read like sentences: When a ticket is created, if it has tag critical, then assign it to the on-call engineer, set priority to High, and post a comment. Triggers cover ticket created, moved, updated, deleted, assignee changes, comments, and checklist toggles. Conditions combine with ALL, ANY, and NOT. You won't need a Jira admin to change a Flow - the project owner edits it from a form.

Blockers are a first-class field. Mark bug A as blocked by bug B and A shows up with a red stripe on the board until B lands in a done category. Useful for the "we can't fix this until the API team ships their fix" case that Jira represents with a confusing is blocked by link type.

Closing the loop with Git

Hook up GitHub, GitLab, Gitea, Bitbucket, or Forgejo once per project, and the board takes care of the rest. Reference WEB-42 or #42 in a commit message, branch name, or PR title and:

• The commit shows up in the ticket's Git activity section with a link.
• The branch is linked automatically.
• PR opened, closed, merged, and reviewed events all land on the ticket.
• Auto-move rules fire on the events you choose: on first commit, move to In progress; on PR opened, move to In review; on PR merged, move to Verified.

Auto-moves run through the same pipeline as a manual drag, so Flows and outgoing webhooks fire exactly as if a human had moved the card. The bug's history reads like a timeline: reported, planned, branch pushed, PR opened, reviewed, merged, verified - without anyone typing a status update.

Reports that answer the questions a manager actually asks

Project reports cover bug counts by status category, by tag, by assignee, by priority, and by day of week. Time entries roll up the same way, so "how long did the last ten critical bugs sit before we picked them up" and "how much time did we spend on regression-tagged work this month" are both two clicks. CSV export when finance asks.

If you want the same view across multiple projects, the All boards view shows every active ticket from every project you can see, filterable the same way as a single board.

Real-time, without the F5

Updates push live over Pusher on per-project channels. Move a ticket on your laptop and your colleague's screen updates without a refresh. Comments arrive without polling. Timer state syncs across devices. The browser tab you left open in the morning is still accurate when you come back at 5pm.

Webhooks going out, MCP for AI, API for everything else

The ecosystem cuts both ways:

• Outgoing webhooks under Project settings -> Webhooks send signed POST requests for ticket.created, ticket.moved, comment.added, timer.started, and the rest. Wire your alerting, dashboards, or Slack/Teams channels however you want.
• The MCP server lets your AI assistant read and write tickets directly. Read-only by default; you opt a token into write access when you generate it, and you can scope it to a single project.
• Integrations. Connect Todo4you to Slack, Homey, or other services to automatically create tickets from incoming messages or events.
• A real REST API under /api/v1/* with bearer tokens you generate from your profile. Postman collection on the developers page.

That's the same triple Jira charges per app for, available on every plan.

Mobile, because bugs don't wait

There are first-class iOS, macOS, and Android apps. Triage from a phone, start a timer when you sit down at your desk, attach a screenshot from the device that hit the bug. Same data, same realtime updates, same notifications. Push notifications arrive over APNs and FCM directly, not through a third-party service.

The escape hatch

The single most important question to answer before you adopt any tool: how do I leave? Project settings -> Export gives you every ticket, comment, attachment, time entry, and flow as JSON. Your data is yours. The Flows you build, the integrations you wire up, the API tokens you mint - all yours. Cancel any time and walk out with everything.

A migration plan, in five steps

If you're moving an existing bug tracker into Todo4you, this is what works:

1. Create one project per repository or product surface - not one giant project for everything. Bug projects stay tractable when they map to something you can build and ship.
2. Write your statuses first. Reported -> Triaged -> In progress -> In review -> Verified -> Closed is a good default. Adjust to your reality.
3. Define your tags. Severity (critical, major, minor), source (customer, internal, regression), and area (auth, billing, mobile). Keep it under fifteen tags - more and people stop using them.
4. Wire the integrations. Connect your Git provider, set up auto-move rules, connect Slack or Teams for notifications, and turn on inbound email so support can forward bugs in.
5. Bulk-import open bugs only. Don't import a decade of closed Jira issues. They will sit there gathering dust. Export from Jira, import the open set via the API, and archive the rest in cold storage.

A small team can be off Jira and tracking bugs in Todo4you the same afternoon they decide to switch.

Try it on your own bugs

Sign up at todo4you.com and start a project. Forward your next bug report into your project's intake address. Hook up your Git provider. Watch the loop close itself. Questions, feature requests, bug reports about the bug tracker - info@todo4you.com lands in my inbox.