Bug Trackers Are Now Burnout Detectors — And Management Is Taking Notes

When your on-call rotation becomes an HR metric

A fintech engineering manager recently discovered that teams opening more than 40% of their incident tickets outside working hours had a 24% higher attrition rate over six months. The data didn't come from an employee survey or exit interview. It came from Jira.

Across Reddit's engineering communities this past week, team leads shared screenshots of dashboards they've built on top of incident management platforms like Linear, Jira, and Incident.io. The original purpose: track software bugs and outages. The new use: detect which engineers are drowning and which teams are on the edge of collapse.

One manager's dashboard flags individuals mentioned in more than 70% of urgent Slack war rooms. Another tracks services that generate more than five false-positive alerts per week — a proxy, he argues, for monitoring noise and chronic stress. A third measures how often specific engineers become the default fire-fighter, the person everyone pages first.

None of these tools were designed as wellness products. But the metadata they collect — time stamps, resolver names, escalation paths — turns out to be remarkably revealing about organizational health.

The shadow HR system nobody planned

Incident.io, a London-based incident management platform, published a case study this week describing how a European SaaS company uses its incident timelines to identify what it calls "organizational anti-patterns." The example: a manager who only appears in incident Slack channels when executives join. Another: engineers who show up in every critical incident, suggesting either heroism or a dangerous single point of failure.

The vendor stops short of marketing this as a burnout prevention tool. But the signal is clear: leadership teams are reading operational data as cultural health metrics, whether the product intended it or not.

The shift is happening quietly, without the oversight that typically accompanies employee monitoring. When a company deploys workplace surveillance software, there are usually policies, disclosures, and HR involvement. When a company deploys a bug tracker, there's a Jira admin and a Slack integration. The surveillance comes later, as a creative use of existing data.

One VP of Engineering on Reddit described the realization bluntly: "We built this dashboard to understand our incident response process. Then we noticed the same three names showing up in every midnight page. Suddenly we weren't looking at a process problem anymore."

What gets measured gets managed — or fired

The line between observation and intervention is thin. Once you know that a particular engineer is being paged 40% more than their peers, what do you do with that information? Redistribute the load? Or start questioning why that person seems to be involved in so many incidents?

The risk is that neutral operational data gets reinterpreted through a performance lens. High incident involvement could mean someone is overworked and needs support. It could also be read — fairly or not — as a sign that someone is causing problems, missing edge cases, or not writing resilient code.

Several engineering leaders in the Reddit threads acknowledged this tension. One noted that their company now includes "incident load" in performance reviews, alongside code quality and project delivery. Another said their CTO uses incident frequency as a factor in promotion decisions, under the theory that senior engineers should write code that breaks less often.

The original intent may be humane — identifying burnout before it leads to attrition. But intent and implementation diverge quickly when operational data becomes an input to HR systems.

The bigger pattern: every tool is a people tool

This isn't unique to incident management. Slack message timestamps reveal who's working weekends. Calendar analytics show who's in back-to-back meetings for eight hours straight. Git commit logs expose who's pushing code at 2 AM.

B2B collaboration and productivity tools generate vast amounts of metadata about how people actually work. That data was originally collected to make the tools function — to route messages, schedule meetings, track changes. But once it exists, it's available for secondary analysis. And management has strong incentives to analyze it.

The incident management example is notable because it's so indirect. These platforms don't market themselves as employee monitoring tools. They're infrastructure. Yet the metadata they produce may be more revealing than any survey or self-report.

The consent problem nobody's solving

When an engineer agrees to use Jira, they're consenting to track bugs. They're not explicitly consenting to have their work patterns analyzed for burnout risk or performance issues. But the distinction may not matter in practice, because the data doesn't care why it was collected.

This raises questions that most B2B vendors and their customers haven't seriously addressed. Should employees be notified when operational tools are being used for HR-adjacent analysis? Should there be limits on what kinds of inferences management can draw from incident logs or Slack timestamps? Who decides?

Right now, the answer is: nobody. The data exists, the tools make it easy to query, and management has legitimate reasons to want visibility into team health. The gap between "we're tracking incidents" and "we're tracking you" is narrower than anyone planned.

One thread participant summed it up: "I thought I was building an ops dashboard. Turns out I built a burnout detector. Not sure how I feel about that."

Neither is anyone else. But the dashboards keep getting built.