Tracking On-Call Hours for Salaried and Hourly Staff Without Mandatory Software Registration
The Most Common On-Call Tracking Mistake (And Why It Quietly Backfires)
Most team leads I've worked with do the same thing when on-call rotations start getting messy: they pick a time tracking tool, send out account invites to the whole team, and wait for compliance that never comes. Within two weeks, half the staff hasn't registered. The salaried engineers figure they don't need to log anything because "they're not paid by the hour." The hourly technicians register but forget to submit entries after a 2 AM page. By month-end, you're staring at a dashboard with 40% coverage and no clean way to reconcile payroll or prove comp time.
The mistake isn't the tool. The mistake is assuming that mandatory software registration is the only way to track on-call hours. It's not. And for mixed teams of salaried and hourly staff, it's often the worst approach you can take.
Mistake #1: Treating Salaried and Hourly On-Call the Same Way
Here's what happens when you apply one tracking rule to everyone: salaried employees either over-log (trying to "prove" they worked) or under-log (because they assume it doesn't matter). Hourly employees, meanwhile, may log every minute they had their phone on — even if they were never paged — because they're worried about getting shorted on pay.
The Fix: Split Your Tracking Logic From Day One
Hourly staff need precise, minute-level tracking for on-call availability and actual call-out engagement. That's a compliance requirement, not a preference. If an hourly technician is restricted from leaving town or drinking at a wedding because they're on rotation, that availability time may be compensable depending on your jurisdiction and whether they're "engaged to wait" or "waiting to be engaged."
Salaried staff don't need the same granularity. What you need from them is a simpler log: date, whether they were paged, approximate time spent resolving the issue, and whether they're banking comp time for it. That's it.
I run a 12-person ops team — 7 salaried engineers and 5 hourly field technicians. For the hourly group, I track availability hours separately from engagement hours. For the salaried group, I only track engagement and comp-time accrual. One spreadsheet, two tabs, two different column structures. No software registration required from anyone.
Mistake #2: Mandatory Registration Kills Compliance
Every additional login is friction. When your on-call rotation includes contractors, part-time staff, or people who only get paged once a month, asking them to register for a full time tracking platform is overkill — and they know it. They'll create the account, log in once, and never return.
The Fix: Use Submission-Based Tracking Instead
Instead of requiring everyone to register for a platform, set up a system where on-call hours can be submitted without an account. A shared form, an email template, or even a structured Slack/Teams message that feeds into a central log works fine. The key is that the person submitting doesn't need to remember a password or navigate a dashboard. They just need to send the right information to the right place.
Here's the workflow I use: every on-call shift ends with a simple message in a dedicated channel — "On-call log: [Name], [Date], [Paged: Y/N], [Time spent: X min], [Notes]." A designated person (or a simple automation) copies that into the tracking sheet. No registration, no app download, no learning curve.
Mistake #3: Not Defining What "On-Call" Actually Means
This is the mistake that causes the most arguments. If you don't define what counts as on-call time, your team will invent their own definitions — and they won't match.
The Fix: Set Three Clear Thresholds
Before you track anything, write down these three definitions and share them:
- Availability hours: The window during which someone is expected to respond. For my team, that's 6 PM to 6 AM, Monday through Friday, and 24 hours on weekends. This is tracked for hourly staff only.
- Engagement time: The actual time spent working a page or call. We round to the nearest 15 minutes with a 30-minute minimum per incident. So a 7-minute page still logs as 30 minutes.
- Disruption premium: Any page between 11 PM and 5 AM gets a 1.5x multiplier on engagement time for comp-time purposes. This applies to salaried staff who accrue comp time.
Last quarter, one of my salaried engineers got paged 4 times in a single Tuesday night between midnight and 4 AM. Each resolution took roughly 20 minutes of actual work. But with the 30-minute minimum and the disruption premium, that night banked him 3 hours of comp time (4 × 30 min × 1.5). He took Friday off. No debate, no negotiation — the math was already defined.
Mistake #4: Relying on Memory and Chat Logs
"I'll remember to log it" is the most expensive sentence in on-call management. Nobody remembers at 2 AM. And scrolling through three weeks of Slack history to reconstruct who got paged when is a task nobody wants to own.
The Fix: Create a Structured Log Template
The log doesn't need to be fancy. It needs to be consistent and immediate. Here's the template my team uses — it's a plain text format anyone can send from their phone:
ON-CALL LOG
Name: [First Last]
Date: [YYYY-MM-DD]
Paged: [Yes/No]
Engagement minutes: [number, 0 if not paged]
Issue summary: [one line]
Comp time requested: [Yes/No]
This takes under 60 seconds to fill out. It works whether you're salaried or hourly. And because it's structured, whoever maintains the central sheet can parse it without ambiguity. The trick is making it a habit — the log gets sent within 30 minutes of the shift ending, not "whenever I remember tomorrow."
Mistake #5: No Backup When Someone Forgets to Log
Even with the best template, people forget. A system that depends 100% on self-reporting will always have gaps. The question isn't whether people will forget — it's what you do when they do.
The Fix: Cross-Reference With Incident Records
Your monitoring system, ticketing tool, or paging platform already has the data. PagerDuty, Opsgenie, VictorOps — whatever you use — logs when pages were sent and acknowledged. Your phone system logs outgoing and incoming calls. Your ticketing system shows when incidents were created and resolved.
Once a week, I spend 15 minutes cross-referencing. I pull the paging history for the week, compare it against the on-call log submissions, and flag any gaps. If someone was paged on Wednesday but didn't submit a log, I follow up directly. This isn't about catching people — it's about making sure nobody loses comp time or pay because they forgot to send a 60-second message after a rough night.
Mistake #6: Over-Engineering the Process
I've seen teams build elaborate on-call tracking systems with custom fields, approval workflows, automated escalation rules, and integration pipelines. Six months later, nobody maintains it. The person who built it left. The documentation is outdated. And the team is back to tracking on-call hours in a spreadsheet anyway.
The Fix: Keep It to Three Data Sources
Your on-call tracking system should pull from exactly three places:
- The submission log — the structured messages your team sends after each shift.
- The paging/incident record — your monitoring or alerting system's history.
- The payroll or comp-time sheet — where the final numbers land.
That's it. If you're maintaining more than three sources, you're creating work for yourself that won't survive the next team reorganization. A Google Sheet or Excel workbook with one tab for hourly tracking, one for salaried comp time, and one for the weekly reconciliation log covers 95% of what you need. No mandatory software registration. No per-seat licensing costs. No onboarding training.
Building a Registration-Free Workflow That Actually Works
Let me walk you through the exact setup I use for my team. It's not sophisticated, and that's the point — it's survived three team leads and two reorgs because it's simple enough that anyone can maintain it.
Step 1: Set Up the Central Log
Create a spreadsheet with two tabs. Tab one is for hourly staff: columns for name, date, shift start, shift end, availability hours, paged (Y/N), engagement minutes, issue ID, and notes. Tab two is for salaried staff: columns for name, date, paged (Y/N), engagement minutes, comp-time multiplier, comp-time accrued, and notes.
Step 2: Create the Submission Channel
Use whatever communication tool your team already lives in — Slack, Teams, email, even SMS. Create a dedicated channel or address for on-call logs. The only rule: every log submission goes there in the template format. No side conversations, no "I'll log it later." The channel is the system of record.
Step 3: Assign a Weekly Reconciler
One person — rotating monthly if you want to share the burden — spends 15-30 minutes every Monday morning doing the cross-reference. They check the paging history against the submitted logs, fill in any gaps, calculate comp-time accruals, and flag discrepancies. This is the single most important role in the whole process. Without it, the system drifts.
Step 4: Publish the Numbers
Share the weekly summary with the team. Transparency matters. When people can see that their logs are being used — that comp time is being honored, that hourly pay is accurate — they'll keep submitting. When the log feels like a black hole, compliance drops. A simple Monday message like "Last week's on-call summary: 3 pages, 2.5 hours comp time accrued, all logs submitted" reinforces the habit.
The Payoff: What Clean On-Call Data Gets You
When this system is running properly, you get three things that matter. First, payroll is accurate — no more end-of-month scrambles to figure out who owes whom. Second, comp time is fair and transparent — no more "I think I'm owed a day off" conversations based on fuzzy memory. Third, you have real data to answer the question every team lead eventually faces: "Are we paging people too much?"
Last year, after six months of clean tracking data, I noticed one of my salaried engineers was averaging 14 pages per month — triple the team average. That wasn't a tracking problem. It was a system design problem. But I only saw it because the on-call log was actually being maintained. The data pointed me to the issue; the issue wasn't the data.
That's the real value of tracking on-call hours without mandatory software registration. You don't need a platform. You need a habit, a template, and someone willing to spend 15 minutes a week keeping the numbers honest. The rest takes care of itself.