Sleep, screensaver and lid close: what each one does to a day's record
· 6 min read
A day’s record says nine hours and you know it was six. Or it says four and you were at the desk all afternoon. Either way the discrepancy is usually about what the Mac was doing while you were not typing, and the states involved behave differently.
The four states, and what each means
Awake and in use. You are typing or moving the mouse. Everything records normally.
Awake and idle. The Mac is running, an application is frontmost, and no input has arrived for a while. This is the state that inflates a record, because nothing has changed from the system’s point of view: the same application is still in front, and it stays in front while you are at lunch.
Display asleep. The screen has turned off after the idle period set in Settings. The Mac is still running and the frontmost application is unchanged.
System asleep. The Mac has suspended. Nothing runs, so nothing records. Time passes with no entry, which is correct.
Closing the lid triggers system sleep on a laptop, unless something is preventing it. Locking the screen does not sleep the Mac; it keeps running with input blocked.
The state that causes the trouble
Awake and idle is the one that matters, and it is why a naive tracker over-reports.
If a tool records the frontmost application and nothing else, it counts the two hours you spent in a meeting away from the desk as two hours in whatever was open. Across a week that is not a rounding error.
The fix does not need any permission, because macOS exposes how long since the last input:
ioreg -c IOHIDSystem | grep HIDIdleTime
The number is nanoseconds since the last keyboard or mouse event. Divide by a billion for seconds. A tracker watching this can stop counting after a threshold, which is the difference between a record that says nine hours and one that says the six you actually spent working.
The threshold problem, which has no correct answer
Choosing how long to wait before treating you as absent is a genuine trade rather than a solved problem.
Too short, and reading a long document without touching anything is scored as absence. Anyone who reads on screen loses time they genuinely worked.
Too long, and short absences accumulate. Five minutes here and ten there adds up across a day.
Most tools settle somewhere between two and five minutes. Whatever the figure, it means the record is an estimate rather than a measurement, and it is worth knowing which direction it errs in. A tracker that trims aggressively under-reports for readers; one that trims gently over-reports for people who step away often.
Checking what your Mac actually did
If a record looks wrong, you can see the machine’s own history of sleeping and waking:
pmset -g log | grep -E "Sleep|Wake" | tail -20
That prints the recent sleep and wake events with timestamps and, usefully, the reason for each. A record that shows a gap you cannot explain is often a sleep you did not notice.
To see what is currently keeping the Mac awake:
pmset -g assertions
The summary shows entries such as PreventUserIdleDisplaySleep and PreventSystemSleep, with the processes holding them listed below. A video call, a media player or a download can all legitimately hold one. Something holding one permanently is worth investigating, since it means the Mac never rests.
To check your current sleep settings:
pmset -g custom
Deliberately keeping the Mac awake
If a long task needs to run without the machine sleeping:
caffeinate -i long-running-command
caffeinate -i prevents idle sleep for as long as the command it wraps is running. On its own, caffeinate -d -i keeps the display and system awake until you press Control-C.
Be aware of what this does to a time record: a Mac deliberately held awake with an application in front will keep looking active. The idle detection still applies, since that is based on input rather than on sleep state, but a tracker that uses sleep as its signal will over-report.
How Punchcard handles it
Punchcard counts the frontmost application by name and subtracts idle time based on input, so leaving the desk stops the count without the Mac needing to sleep. When the Mac does sleep, nothing runs and nothing is recorded, which is the correct outcome.
The consequence worth knowing: reading a long document without touching the keyboard or trackpad will eventually read as idle. That is a deliberate choice in the direction of under-reporting rather than over-reporting, on the grounds that a record which flatters you is worse than one that is slightly stingy. What automatic time tracking can and cannot know sets out the limits, and why your estimate of your own workday is wrong by hours covers why even an imperfect record beats memory.
Questions
Does closing the lid stop the record? On a laptop it triggers system sleep, so yes, unless the Mac is prevented from sleeping by something else or is connected to an external display in a configuration that keeps it awake.
What about a locked screen? Locking does not sleep the Mac. Input stops, so idle detection takes over and the count stops that way.
Why does my record show time during a meeting I attended on the Mac? Because you were using the Mac. A video call is legitimate work and is recorded as time in the call application. That is correct rather than a fault.
Can I see exactly when my Mac slept yesterday?
pmset -g log keeps a history. Grep it for Sleep and Wake and read the timestamps and reasons.