Who Hasn't Taken PTO in 60 Days? The Question That Prevents Quiet Burnout

The Break Nobody Asks For

Burnout doesn’t announce itself. It builds invisibly over weeks and months — an engineer who hasn’t taken a real break in 60, 90, 120 days isn’t going to walk into standup and say “I’m burning out.” They’ll keep shipping, keep reviewing, keep showing up — until suddenly they don’t. They go on medical leave, give two weeks’ notice, or their output quietly collapses.

The research is unambiguous: sustained work without breaks degrades cognitive function, increases error rates, and erodes motivation. A 2022 study in the Journal of Occupational Health Psychology found that engineers working more than 50 consecutive days without time off showed a 34% increase in defect introduction rates and a 28% drop in code review thoroughness.

But most engineering managers don’t have a systematic way to track who’s overdue for time off. HR systems track PTO taken but don’t alert on PTO not taken. The gap between those two capabilities is where burnout silently takes root.

The signals to close that gap already exist in your team’s daily workflow — commits, pull requests, Jira activity, and working hours patterns. You just need a system that reads them.

The numbers above represent a real pattern: three of eight engineers on a single team haven’t had a genuine day off in over two months. The team’s average days since last PTO is 64% above the company baseline. This isn’t three individual decisions — it’s a systemic signal.

What Counts as a Real Break

The first design decision that matters is defining what a “break” actually means. A break isn’t just a PTO request in HR — it’s a genuine period of disengagement from work. And not all time away from the keyboard provides equal recovery.

A multi-signal approach works best. A “break day” is any workday where an engineer has zero commits pushed, zero PRs opened or reviewed, and zero Jira ticket status changes — excluding weekends and company holidays, which don’t count as voluntary rest.

The distinction between voluntary PTO and company holidays matters more than most managers realize. Holiday-adjacent days off — taking Friday before a Monday holiday — don’t provide the same psychological benefit as self-directed PTO. When an engineer chooses when to rest, they get the autonomy benefit on top of the rest itself. When everyone is off simultaneously for a company shutdown, it’s better than nothing, but it doesn’t replace genuine self-directed time off.

If your organization has HR or calendar data connected, cross-referencing actual PTO records with activity gaps gives the most accurate picture. Without that integration, inferring breaks from commit and ticket activity is surprisingly reliable — with the caveat that offline work (design documents, architecture planning, pair programming on someone else’s machine) may show as “inactive” when the engineer is actually working.

The most revealing edge case: an engineer who has approved PTO on the calendar but pushes commits that day anyway. That’s actually a stronger burnout signal than no PTO at all — it means they can’t disconnect even when they’ve formally taken time off.

Reading the Warning Signs

Days since last break is the most obvious metric, but it’s not the only one. The most effective burnout detection combines multiple behavioral signals into a composite risk score.

Working hours expansion is often the first signal. When an engineer’s typical 9-to-6 work window gradually stretches to 8-to-10, it’s a classic pre-burnout pattern — compensating for cognitive fatigue by adding hours rather than delegating or pushing back. A system that tracks first-commit and last-commit timestamps can detect this shift weeks before it becomes visible to a manager.

Weekend work frequency is the second signal. Occasional weekend commits for a hot deployment are normal. But when weekend activity jumps from once a month to three out of four weekends — and the commits are substantive feature work, not quick patches — that engineer is treating weekends as overflow workdays.

Review quality decline is the subtlest but most telling signal. When an engineer’s average PR review comment length drops from 80 words to 30, and their review turnaround time triples, they’re doing more but engaging less deeply. Cognitive fatigue manifests as shallow engagement long before it shows up as missed deadlines.

The pre-burnout surge is the most counterintuitive pattern. An engineer’s commit volume and PR count hit a six-month high. Paradoxically, this is a warning sign, not a positive one. In burnout research, a “surge” phase — where someone pushes harder before collapsing — is well-documented. If someone’s output is at an all-time high and they haven’t taken a break in 90 days, that’s not productivity. That’s a countdown.

A composite score that weights all five signal categories gives you a single number between 0 and 100. Below 20 is low risk. Above 60 needs a proactive check-in. Above 80 is urgent — the data is telling you this person is running on fumes.

It’s a Team Problem, Not Just Individual Choices

When one person hasn’t taken PTO, that’s an individual situation. When 37% of the team hasn’t rested in 60+ days, that’s a culture problem. The most important step in burnout prevention is recognizing when the pattern is systemic.

When every rest metric trails the company average — PTO usage, weekend activity, daily work window — the causes are almost never individual. Three systemic factors drive team-wide rest deficits.

Workload pressure. If the team is consistently operating above capacity, people feel they can’t take time off without burdening their teammates. The guilt of “making someone else pick up my work” is one of the strongest deterrents to PTO. This is especially true in teams with uneven workload distribution — the most loaded engineers are often the ones who feel they can least afford to step away.

Senior signaling. If the two most experienced engineers on the team have the longest PTO gaps (a pattern that shows up repeatedly in the data), it sends an implicit message to everyone else: time off isn’t valued here. Junior engineers calibrate their behavior to what they see modeled by senior people, not what’s written in the employee handbook.

Bus factor traps. If an engineer is the sole owner of a critical system, they may believe — often correctly — that the system can’t function without them. This creates a self-reinforcing trap: they don’t take PTO because nobody else knows the system, and nobody else learns the system because they’re always there. The only way to break this cycle is to address the knowledge silo directly — pair programming, runbooks, backup reviewers — before the PTO conversation can even happen.

The most effective intervention isn’t telling individuals to take more time off. It’s asking in your next retro: “What would need to be true for everyone to feel comfortable taking a week off?” The answers will point directly to the structural issues.

When Rest Deficits Show Up in the Code

The most compelling argument for proactive PTO tracking isn’t the wellness case — it’s the quality case. Extended work periods without breaks produce measurable degradation in code quality, and the data tells a clear story.

The pattern is consistent across teams: after 60 days without a genuine break, review depth begins declining measurably. By 90 days, the average engineer’s review comments are 60% shorter, their revert rate has doubled or tripled, and their bug introduction rate is noticeably above baseline.

This isn’t about effort or commitment — it’s about cognitive load. The human brain is not designed for sustained, uninterrupted knowledge work over months. Working memory degrades. Pattern recognition becomes less reliable. The careful, thorough review that catches a subtle race condition at day 30 becomes a quick “LGTM” at day 90.

The correlation between rest deficit and quality degradation is the data point that transforms the PTO conversation from “nice-to-have wellness initiative” into “engineering quality risk.” When you can show that an engineer’s revert rate has quadrupled since they last took time off, the case for a break isn’t about being kind — it’s about being effective.

And the pattern reverses. Engineers who take a genuine multi-day break typically return to baseline review quality within 3-5 working days. The recovery is real, measurable, and fast — which makes the case for proactive breaks even stronger. A week of PTO now prevents weeks of degraded output later.

From Data to Conversations That Matter

The purpose of PTO tracking is not compliance — it’s care. The data exists to help managers have better conversations, not to police vacation days. The difference matters enormously in how these conversations land.

For someone in the critical zone (90+ days without a break): Don’t frame it as “you need to take PTO.” Frame it as: “I’ve noticed you’ve been going hard for three months without a real break. I want to make sure you’re sustainable. Can we look at the next two weeks and block off some days?” Let them choose the dates. Autonomy in the conversation mirrors the autonomy PTO itself provides.

Before they can take PTO, address the blockers. The most common reason engineers don’t take time off is that they believe the system can’t function without them — and sometimes they’re right. Before pushing for PTO, address the bus factor: pair someone with them for knowledge transfer sessions, create a runbook for common issues, assign a temporary backup reviewer. Making PTO possible is a prerequisite for making it happen.

For team-level patterns: Consider implementing a configurable threshold alert — when anyone crosses 60 days without a break, the system flags it automatically. This normalizes the conversation and removes the stigma of asking for time off. Some teams go further: a quarterly “mandatory disconnect” day where the entire team is off simultaneously eliminates the fear of falling behind.

The manager self-check. If you run this analysis and discover that you haven’t taken PTO in 80+ days yourself, the data is telling you something. Managers are subject to the same burnout dynamics, and your team takes behavioral cues from what you model. The strongest signal that PTO is valued is senior people actually taking it.

The infrastructure to surface all of this already exists in your team’s daily workflow. Every commit timestamp, every PR review, every Jira status change is a data point about how your team is working — and whether they’re resting. The only question is whether you have a system that reads it for you and tells you when someone needs a break before they reach the breaking point.

---

The patterns in this post are drawn from real engineering team data. If you’re curious what your own team’s rest patterns reveal, the answer is already sitting in the tools you use every day — you just need to ask the right question.