The setting I missed that broke every tracker silently
1. Toggl Track breaks when multiple timers run simultaneously
Toggl’s hover-friendly dashboard makes it easy to start logging time. Too easy, sometimes. If you have the Chrome extension enabled and the desktop app installed, starting a timer in two places can conflict, but not obviously. I only noticed the issue when I exported a report and saw two projects logging the same stretch of time. Zero warnings, zero UI red flags. Just overlapping strings of timestamps.
There’s no setting to enforce a strict single-timer mode either. Toggl silently allows double-tracking and just leaves it up to you to notice. Their own help forum hints at this, but it’s vague — the system lets overlapping timers exist across devices.
I now run a daily cron job that pulls my Toggl data via API, checks project overlaps, and sends a Notion comment to myself when two timers are active within the same minute. Yes, I built a Notion zap to ping myself because the UI wouldn’t offer validation in-app. That’s the level of patchwork needed for reliability.
2. Harvest gaps data during paused times but shows no visual warning
Harvest is the one I wanted to love. Clean billing, client categories, solid integrations. But when working through segmented chunks of client work across the day, I noticed my hours weren’t lining up with what I remembered doing. Turns out, their timer pauses if your session is idle — unless you manually override that behavior. But it doesn’t warn you. It acts like it logged time, then quietly subtracts from it later.
Harvest’s journal data will show a placeholder for a block that *was* active, but the true gap isn’t intuitive. If you’re multitasking — say, screen sharing a Notion doc while checking Discord — the inactivity timer can falsely trigger. That’s what happened to me on a call with a client. I shared my screen, demonstrated a build, and Harvest nixed 30 minutes because I didn’t move my mouse.
After poking around long enough, I found the setting hidden under Preferences → Timer Behavior in the desktop app. You have to uncheck auto-pause — it’s opt-out. Honestly, it should prompt during install or first launch.
3. Clockify API misreports start times during bulk uploads
I use Clockify mostly for import-heavy logging due to the decent CSV-to-time-entry pipelines. But the API has a weird behavior: if you’re backfilling time entries from a script and two entries are less than ten minutes apart, the `start` time of one of them may be rounded up by a few seconds.
That throws off daily totals if you use downstream tools to add it all up. I only spotted this when comparing the JSON API output against the visual dashboard. The numbers didn’t match — like 7h 58m in the JSON, but 8h 00m rendered. That’s when I realized their web UI glosses over milliseconds quietly.
For freelance invoicing, that error margin was enough to affect the final payout. I had to adjust my import script to buffer a minimum of sixty seconds between logged entries just to prevent rounding effects. The platform doesn’t document this, and customer support confirmed it’s “expected.” Which is wild — expected rounding via undocumented floor functions?
4. Timely’s AI auto-tag causes billing mismatches during multitasking
I gave Timely a spin because of its “memory tracker AI” that auto-tags activity. It’s kind of magical how it knows which tab, window, or app you’re working in. Except… then you work across two things at once. You’re in Figma, exporting a frame, while writing in a doc. It guesses wrong. And the guesses stick, unless you manually override.
One week I shipped four design pages, did copy, and ran the client call — and Timely matched all of it to the wrong project. It remembered the last *clicked* calendar item, not the current window. There’s no re-train button. No feedback mechanism. Just retroactive tag correction, one by one. You can’t batch tag or select multiple entries unless you export, delete, and re-upload.
If you export a CSV and try to re-import it with corrected tags, Timely flags duplicates based on internal UUIDs — not user-visible timestamps. The fix? Strip the UUIDs in your CSV, act like it’s a fresh import, then manually delete the wrong versions.
Wildly inefficient, but the only workaround I could find without waiting for support.
5. Tracking across Notion databases using third party toggles
Notion doesn’t actually have a native time tracking feature — no start-stop, no durations beyond calculated properties. So I built a pseudo-tracker by combining a few toggles, a checkbox, and a timestamp formula. Here’s how the flow ran:
- Toggled “Active” to True in a Task DB
- Checkbox triggered a Make scenario
- Make pulled timestamp from now and wrote to “Start Time”
- Second toggle flipped at task end, triggering duration calc
- Zapier wrote the result into a log database
The illusion worked — if you clicked everything in the right order. But if someone toggled start twice (or the webhook failed — which it did on slow internet), you ended up with ghost start times and zero durations.
Edge case: if two users in a shared Notion Workspace updated the same toggle field within a five-second window, Make saw both and fired two webhooks. The durations doubled. The fix was to enforce a `modified_by == current_user.email` logic inside the Make parser, but Notion’s webhook payload doesn’t always expose that cleanly. Sometimes the modified_by gets cached across users in rapid edits.
The more brutal fix was adding a delay block in the automation, so only one webhook would fire per unique page per 10 seconds. Dirty, but it worked.
6. Manual CSV tracking in Airtable introduced decimal hour errors
I only fell back to Airtable because I needed to merge campaign logs with cost fields that only lived in Google Sheets. I created a table with human timestamps (Start, End) and a formula to calculate Decimal Hours. Fine for simple math, until you start exporting and importing across regions where decimal delimiters shift (looking at you, German system settings).
I got an angry email from a client because an invoice said 3,75 hours instead of 3.75. What happened was an Excel import in the client’s system interpreted the field as text, not number, because of that comma. My local export (using German macOS defaults) turned periods into commas. Airtable doesn’t sanitize that on export. Learned the hard way.
A quick workaround was to export in CSV from Airtable, import into Google Sheets, run a global find-replace on commas-to-points only in specific columns, then export again. Fragile, but saved the downstream math from exploding.
7. RescueTime logs browser activity but fails during incognito usage
I don’t use RescueTime all the time, but during focused freelance binging, I turn it on to see where the day went. But I also jump into incognito windows constantly — especially when testing site flows or using multiple accounts. RescueTime doesn’t log incognito activity at all, unless you manually allow its browser extension in incognito mode. Which sounds fine until you realize that feature is off by default, and RescueTime never tells you.
So I lost full days of activity without knowing it. Chrome showed me toggling between Webflow, Github, and Stripe test environments — all incognito. RescueTime showed “low activity.” I opened the extension settings and saw the checkbox. After enabling incognito, everything worked — but it made me retroactively distrust all the past data.
8. Timing for macOS ignores Terminal sessions unless scripted manually
Timing.app is hardcore. It reads every app window and tracks durations per file. For writing code, I expected it to log editing in VSCode, CLI tests in Terminal, maybe some docs. Problem is, Terminal sessions don’t log clearly — unless you give Timing a shell script wrapper that echoes sessions into their Activity database.
I found this workaround on a GitHub issue thread, not in their docs. You write a shell script that uses `osascript` to tell Timing which project you’re working under. Then you alias it in your `.zshrc` or `.bash_profile`.
function startProjectTiming() {
projectName="$1"
osascript -e 'tell application "TimingHelper" to start task "'$projectName'" project "'$projectName'" identifier "custom-id"'
}
Run startProjectTiming "My Client Task"
before your dev session. That’s what actually logs the session to their UI. Otherwise, they don’t know what terminal activity maps to. There’s no automatic label you can set in settings.
Bonus quirk: if your shell script has dashes in the name (like `dev-build-helper.sh`), their internal parser sometimes fails to assign the project. Stick to underscores or camelCase filenames and it works better.