Mac पर automatic time tracking, समझाया — और क्यों manual timers काम नहीं करते

मैंने smart, organized लोगों को manual time trackers इस्तेमाल करते देखा है, और failure का तरीका हमेशा एक जैसा होता है।

Monday सुबह वे timer start करना याद रखते हैं। Monday दोपहर तक वे छह बार context switch कर चुके होते हैं और timer को साथ switch करना भूल जाते हैं। Tuesday को वे ध्यान देते हैं और memory से Monday की entries update करते हैं। Wednesday तक timer चार घंटे "Email" पर होता है क्योंकि वही project खुला था जब वे distract हुए।

Data गलत है, और जो इसे track कर रहा है उसे पता है कि यह गलत है, जिसका मतलब है कि वह इस पर कम भरोसा करता है, जिसका मतलब है कि वह इसे कम update करता है, जिसका मतलब है कि यह और बुरा होता जाता है। Manual time tracking एक slow-motion collapse है।

मैंने सालों तक disciplined exception बनने की कोशिश की। नहीं बन पाया। मेरे जानने वाले कोई नहीं बन पाए। तो सवाल यह बनता है: अगर manual tracking एक fantasy है, तो automatic tracking actually क्या capture करती है, और क्या वह काफ़ी अच्छी है?

"Automatic" का असल मतलब

Mac किसी भी दिए गए moment में बिना तुम्हारी उँगली हिलाए लगभग तीन चीज़ें जान सकता है:

1. कौन सी app foreground में है। macOS एक NSWorkspace notification publish करता है हर बार जब frontmost application बदलती है। यह एक hard signal है — यह जानता है कि Slack या Xcode ऊपर है।

2. Focused window क्या कह रही है। ज़्यादातर apps अपनी windows को useful तरीके से name करती हैं। Xcode project बताता है। Slack channel बताता है। Chrome tab title बताता है। यह एक soft signal है — जब titles descriptive होते हैं तो useful, जब नहीं होते तो बेकार (Finder, यह तुम पर है)।

3. Active browser tab कौन सी है। इसके लिए ज़रूरी है कि browser अपना tab title एक accessibility client को expose करे, जिसका macOS पर मतलब है user से explicit Accessibility permission माँगना। सिर्फ़ opt-in।

एक अच्छा automatic Mac time tracker तीनों को सुनता है। Timex तीनों को सुनता है। जो store होता है वह rows का एक stream है जो कुछ इस तरह दिखता है:

2026-05-21 14:32:01 | Xcode    | timex/AppDelegate.swift
2026-05-21 14:32:02 | Xcode    | timex/AppDelegate.swift
2026-05-21 14:32:03 | Xcode    | timex/AppDelegate.swift
2026-05-21 14:32:04 | Slack    | #engineering
2026-05-21 14:32:05 | Slack    | #engineering
2026-05-21 14:32:06 | Chrome   | github.com — pull request #482

बस। तीन columns, एक row प्रति second। Today view में रंग की strip बस वही rows हैं जो contiguous blocks में roll up होकर 24-hour line पर render हुई हैं।

1 Hz का फ़ैसला

लोग पूछते हैं कि हम प्रति second एक बार sample क्यों करते हैं, हर पाँच seconds, या हर minute, या हर दसवें second की बजाय।

1 Hz से धीमा छोटे context switches खो देता है। अगर तुम नौ seconds के लिए Slack notification check करते हो और Xcode पर वापस आते हो, तो 60-second sampler उस minute को या तो all-Xcode या all-Slack record करेगा इस बात पर निर्भर करके कि capture के moment पर कौन सा ऊपर था। दोनों गलत हैं। तुम नौ-second का Slack blip देखना चाहते हो।

1 Hz से तेज़ कुछ नया नहीं बताता — इंसान एक second में 10 बार focus नहीं switch करते — और SQLite file को बिना किसी informational gain के bloat करता है। 1 Hz पर एक workday लगभग 30,000 rows है। 10 Hz पर वही insight के लिए 3,00,000 rows होंगी। हमने छोटे number के लिए optimize किया।

1 Hz का एक और फ़ायदा है honest idle detection। macOS last user input के बाद का time expose करता है। अगर gap एक threshold से अधिक हो जाए (Timex का default 90 seconds है), तो row को idle mark किया जाता है। दो consecutive idle rows एक idle block बन जाती हैं। Idle blocks तुम्हारे break timer में count नहीं होते, इसलिए एक deep focus session coffee run की वजह से unfairly नहीं कटती।

Browser tab का सवाल

यह automatic tracking का वह हिस्सा है जो लोगों को nervous करता है, और सही भी है।

अगर एक Mac time tracker तुम्हारे browser tab का title देख सकता है, तो theoretically वह तुम्हारी history में "Bank of America" या "MyChart Patient Portal" देख सकता है। सबसे साफ़ जवाब है कि कुछ भी होने से पहले user से पूछा जाए। macOS हमें मजबूर करता है। पहली बार जब तुम Timex launch करते हो, browser-tab feature off होती है। तुम्हें explicitly Accessibility permission देनी होगी, और तुम System Settings में कभी भी इसे revoke कर सकते हो।

जब तुम grant करते हो, जो store होता है वह window title string है जो browser उस moment की current tab के लिए publish करता है — बस। हम URL नहीं पढ़ते। Page content नहीं पढ़ते। Browsing history नहीं पढ़ते। हम वही string store करते हैं जो उस exact moment पर तुम्हारे browser के title bar में दिखती है।

अगर तुम नहीं चाहते, तो permission off रहने दो और tracker फिर भी काम करेगा — तुम बस browser को एक single block के रूप में देखोगे ("Chrome — 41m") per-tab breakdown की बजाय।

SQLite में data model

Storage layer के बारे में curious लोगों के लिए: Timex एक single SQLite file use करता है कुछ tables के साथ। जो shape matter करती है वह activity log है, जो roughly इस तरह है:

CREATE TABLE activity_samples (
  ts          INTEGER NOT NULL,   -- unix seconds
  app_bundle  TEXT,               -- e.g. "com.apple.dt.Xcode"
  app_name    TEXT,               -- e.g. "Xcode"
  window_title TEXT,              -- e.g. "AppDelegate.swift"
  browser_tab TEXT,               -- nullable, only when permission granted
  is_idle     INTEGER NOT NULL    -- 0 or 1
);
CREATE INDEX idx_samples_ts ON activity_samples(ts);

यही है "आज तुमने क्या किया" की पूरी shape। File को किसी भी SQLite client से खोलो। Query चलाओ। जवाब कुछ rows दूर है।

मैंने यह schema पहले Your data, your file में share किया है — storage layer क्यों product है उसका deeper argument। Short version: एक tool जिसका एकमात्र output एक proprietary cloud dashboard है वह बुरी तरह age करता है। एक tool जिसका एकमात्र output एक SQLite file है वह तुम्हारे साथ age करता है।

Automatic tracking जिन सवालों का जवाब दे सकती है

ये वो queries हैं जो हम actually अपने data पर चलाते हैं:

• सुबह कहाँ गई? Strip के 09:00–12:00 slice पर drag करो। Totals उस window पर filter हो जाएंगे। Top app tap करो। देखो किन windows ने slice खाई।

• क्या मैंने इस हफ़्ते सही चीज़ पर progress किया? Xcode rows में बिताया गया time sum करो जिनके window titles active project name से match करते हों। अगर वह expected से कम है, तो यह calendar problem है, tracker problem नहीं।

• मैं last आखिर कब actually deeply thinking कर रहा था? एक single app पर सबसे लंबा contiguous block of is_idle=0 देखो। अगर सबसे लंबा 28 minutes है, तो जवाब है "इस हफ़्ते कभी नहीं" — और यह वो data है जिस पर act किया जा सकता है।

• Chrome ने क्या खाया? Rows filter करो जहाँ app_name='Google Chrome' हो। browser_tab से group करो। Count से sort करो। List का top, depressingly, अक्सर Reddit होता है। या Hacker News। या उन दो AI vendors में से एक जिनके नाम rhyme करते हैं।

वो सवाल जो यह नहीं कर सकती

मैं limits के बारे में honest रहना चाहता हूँ।

यह नहीं बता सकती कि तुम क्या करना चाहते थे। यह सिर्फ़ देखती है कि तुम्हारी foreground app क्या थी। अगर तुमने Hacker News पर चालीस minutes काम के लिए research करते हुए बिताए, तो tracker Hacker News देखता है। "क्या यह worth it था" का classifier तुम्हारे दिमाग़ में है, data में नहीं। हम उसे automate करने की कोशिश नहीं करते। हमें नहीं लगता तुम कर सकते हो।

यह automatically projects tag नहीं कर सकती। कुछ apps इसे आसान बनाती हैं (Xcode का window title file path है, जो project पर map होती है)। कुछ नहीं करतीं (Chrome का window title page title है, जो काम के बारे में कुछ नहीं कहता)। v1 का जवाब है strip खुद पढ़ो और आँखों का इस्तेमाल करो। बाद का version rule-based tagging add कर सकता है ("अगर window title में X है, तो project Y के रूप में tag करो") उन लोगों के लिए जो lightweight project structure चाहते हैं।

यह उन sessions को reconstruct नहीं कर सकती जब तुमने इसे खुला नहीं रखा था। यह obvious है। आज install करो, तुम्हें आज से आगे का data मिलेगा। कोई magic backfill नहीं है।

Idle, sleep, और screen lock

तीन edge cases जो out loud कहने लायक हैं, क्योंकि ज़्यादातर automatic trackers इन्हें inconsistently handle करते हैं:

Idle — user input timeout। Default 90 seconds। Row में mark होता है, break-timer counts skip करने के लिए use होता है, लेकिन data फिर भी record होता है ताकि strip gap को honestly दिखाए।

Display sleep — जब macOS system idle के कारण screen dim करता है। हम sampler को completely pause कर देते हैं। कोई rows नहीं लिखी जातीं। Strip एक clean gap दिखाती है।

Screen lock — जब तुम Ctrl+Cmd+Q hit करते हो या लंबे समय के लिए lock engage करने के लिए away step करते हो। Display sleep की तरह: sampler pauses, कोई rows नहीं, clean gap।

Principle यह है: अगर तुम Mac पर नहीं हो, तो data को यह claim करने का मौका नहीं मिलता कि तुम थे।

"Projects के बारे में क्या?"

यह काफ़ी बार आता है कि explicit जवाब deserve करता है।

अगर तुम्हारी job है client को hours bill करना, तो तुम्हें genuinely एक project picker चाहिए। एक automatic tracker जो तुम्हारी project structure नहीं जानता वह invoice generate नहीं कर सकता। Toggl और Harvest इसी के लिए designed हैं। उनके पास project picker है, start/stop friction है, और वह export pipeline है जिस पर तुम्हारा accountant भरोसा करता है।

अगर तुम्हारी job है अपना हफ़्ता समझना, तो तुम्हें project picker की ज़रूरत नहीं है। तुम्हें strip देखनी है और notice करना है कि Tuesday दोपहर Slack के चार घंटे थे जिनके Cmd+Tab distance में codebase का कुछ नहीं था। यही insight है। कोई project label ज़रूरी नहीं।

जिन लोगों के लिए मैंने यह बनाया उनमें से ज़्यादातर दूसरे camp में हैं। वे already Claude Code और Cursor और उन Octomind agent runs में हैं जिन्होंने Wednesday सुबह खाई। वे देखना चाहते हैं घंटे कहाँ पड़े, उन्हें bill codes में bucket नहीं करना।

Wednesday test

यह test है जो मैं किसी भी time tracker के लिए run करता हूँ इससे पहले कि मैं उस पर rely करने पर विचार करूँ।

Wednesday सुबह है। Standup पूछता है Monday को क्या किया। तुम tracker खोलते हो।

• अगर data तुम्हारी Tuesday शाम की memory से reconstruct किया गया था, तो यह झूठ बोलता है। तुम Slack को Xcode और Xcode को Slack याद करते हो। Standup का जवाब confidently गलत होता है।
• अगर data automatic है, तो यह वही boring truth है जो strip ने Monday शाम को दिखाई थी। तुम इसे पढ़ते हो। तुम बोलते हो। तुम आगे बढ़ते हो।

यही वह gap है जो automatic tracking actually close करती है। Productivity नहीं। Focus नहीं। यहाँ तक कि memory भी नहीं। बस तुम्हारा tracker जो version of the day report करता है वह actually जो हुआ था उससे match करता है।

अगर तुम देखना चाहते हो यह तुम्हारे Mac पर कैसा दिखता है, 100-hour trial grab करो। तीन Macs, कोई account नहीं, कोई cloud नहीं। वही strip जो हम हर दिन अपने laptops पर use करते हैं।