Early burnout signals, not workplace surveillance

Burnout usually announces itself too late — after someone has already quietly overcommitted for weeks. Taskive tries to catch the pattern earlier by reading signals that are already available in a team's existing workflow: how often and when someone commits code, how long tasks take from start to finish (cycle time), how many tasks a person is actively juggling at once (WIP volume), and GitHub pull request activity like review turnaround and merge frequency.

These signals feed a computed burnout risk score, interpreted with an AI layer to translate raw metrics into a meaningful early-warning signal rather than a raw number nobody can contextualize.

• Commit frequency and timing — sustained late-night or weekend commit patterns are a classic early burnout indicator, more useful as a trend than a single data point.
• Cycle time — tasks that are taking meaningfully longer than a person's own baseline can indicate friction, blockers, or fatigue rather than task difficulty alone.
• WIP volume — how many tasks someone has actively in progress at once. High sustained WIP is one of the strongest predictors of burnout risk in software teams.
• GitHub PR data — review turnaround time, PR size trends, and merge frequency add a second, corroborating signal alongside task-level data.

This is the most important design decision behind the feature, so it's worth stating plainly: Taskive never exposes an individual's burnout breakdown to anyone but that individual. Team leads see an aggregate, team-level signal — for example, that overall team burnout risk is trending upward this sprint, or that WIP volume is running above baseline across the team — without per-person attribution.

Individuals see their own score and the signals behind it, framed as a private early-warning tool they can act on — take a lighter sprint, flag a blocker, or talk to their lead about workload — rather than a metric being used to evaluate them. There is no productivity leaderboard, no hours-worked ranking, and no manager view into any single person's raw data. Burnout detection exists to help teams notice a systemic problem before it becomes an attrition event, not to monitor individuals.

Burnout signals are also part of Taskive's MCP server tool surface at the aggregate level, so an AI agent can help a team lead ask "is this sprint's scope realistic given current team burnout signals" without ever exposing individual data through that channel either.

Engineering managers who want an early signal before a 1:1 conversation becomes a resignation conversation. Team leads planning sprint scope who want to know if the team is already running hot before adding more work. And individual contributors who want a private, non-judgmental signal about their own pace — without it becoming ammunition in a performance review.

Burnout detection ships alongside AI risk scoring as part of Taskive's ambient intelligence layer — see how the full platform compares to Linear, Jira, and Trello, none of which offer burnout detection today.