Still working? Reminder

[Giorgio-Germani]

there is a idle timeout in the timer settings but i dont think it has a purpose.
if you are idle for the defined time period an active timer should stop. i tracked my time with the browser extension and mobile app but neither stopped my timer. i forgot it and when i started working today i saw i had 22h on the clock running already.

if you set an idle timer for 30min it would be great to get a notification on the desktop, phone and browser extension that asks you "Still working?" You then have 5 minutes to press Yes or No, if you fail to answer within 5 minues the timer would automatically stop and save your work task with a duration of 30min.

i cant think of any alternatives to get a correct time tracking but im open to suggestions. its easy to forget a running timer, thats why i think being able to set such reminders would be great.

[evilguy4000]

@Giorgio-Germani can you validate with the latest version?

[Giorgio-Germani]

not working. i treid with v5.11.3 no reminder asking me anything, nor is the timer stopping after reachine the idle time

[evilguy4000]

@Giorgio-Germani Fixed in v5.11.4.

What changed

• Timers now track last_heartbeat_at; a scheduled job auto-stops forgotten timers when clients go offline.
• “Still working?” prompts are wired across web, browser extension, mobile, and desktop, with Socket.IO broadcast (not just web push).
• If you don’t answer within the grace window, the timer stops automatically (as you suggested).

Please upgrade to 5.11.4 on server + clients and confirm idle timeout + reminders behave as expected on your setup.

[Giorgio-Germani]

tested with version 5.13
you start a timer, it runs, you do nothing on the timetracker page, a notification comes that you are idle since you started the task.
if you dont react it will close the task with 0 min recorded with the starting time.

i think thats not really useful, since we cant measure idle time in reality. how would the browser know what i do. also the idle notification needs to be pushed via browser notifications so you really notice it in case you are in a differnt tab, and for better visibility this notification should be happening on the mobile app or desktop app as well. when you are not confirming you should at least get the idle time threshold depending on the settings. so a 30min idle time should result in 30min worktime. you cant be idle right from the moment on that you started to work on something :) only after 30min the reminder should ask you if you are still working, and if you dont answer it, then it closes the job with 30 min of work recorded. i didnt notice any notification on the mobile app.

i work in a corporation enviroment, meaning the desktop app cant be installed, just the browser extension. so either this can remind me properly or we need to use the mobile app since this is definitely possible to install on your phone. i think the phone should become the main reminder here since its the most reliable tool for the job, and the next best thing compared to the desktop app.

[Giorgio-Germani]

Rethinking the idle mechanism: server-scheduled "Still working?" checks instead of activity detection / heartbeats

I've been testing the current implementation and I don't think activity detection can ever deliver what this issue needs. I'd like to propose a different architecture. Context for the problem: I start a timer, then get pulled into a call and leave my desk. The goal is simply that the timer stops instead of running for hours — I don't care about detecting idleness precisely, I care about not billing unattended time.

Why the heartbeat / activity-detection approach can't work

1. Activity is the wrong signal. Heartbeats and idle detection measure "is a human near a device", not "is that human working on the task this timer is tracking". Moving the mouse proves presence, not work — I can be in a video call in another window while the timer keeps getting confirmed. Conversely, on mobile the signal is useless in the other direction: while the app is in the foreground it heartbeats every 60s regardless of whether I touched the phone, so a phone-based timer never goes idle and the notification never fires. That's the exact bug I hit: 2 hours of real work, zero prompts.

2. Each client decides alone, so devices contradict each other. The desktop sees OS idle time, the extension sees browser idle, the web tab sees DOM events, the phone sees app lifecycle. They fire at different moments or never, they can't see each other's prompts, and they can't share an answer. There's no way to implement "ask me everywhere, first answer counts" on top of independent client-side detection.

3. Heartbeats defeat the safety net. The server can only judge idleness from heartbeat staleness, which requires clients to heartbeat correctly — the thing that doesn't work per (1). Kill the app and the heartbeat state is stale but meaningless.

Proposed design: the server schedules a check; the user answers on any device

• When a timer starts, the server arms next_idle_check_at = start_time + idle_timeout_minutes (the existing global setting). After every confirmation it re-arms: last_confirmation + idle_timeout_minutes. Pausing clears it; resuming re-arms it.
• When the deadline passes, a server job opens a check: it fans out "Still working?" to all of the user's platforms at once (browser push + Socket.IO, desktop OS notification, extension notification, mobile notification), and records that the check is pending with an expiry (idle_notified_at can serve as "check opened at"; expiry = that + a 5-minute grace).
• The user answers explicitly: Yes (still working → re-arm next check) or No (stop now). Answer endpoints must be idempotent and keyed to the pending check so that whichever device the user touches first wins and all other devices dismiss their prompt on their next poll — a shared idle_check_pending/idle_check_expires_at/idle_check_deadline in GET /api/v1/timer/status is enough for clients to converge.
• If nothing answers within the grace, the job stops the timer backdated to the check deadline, so the entry records exactly idle_timeout_minutes of unattended time and not a second more (and not zero, either).
• No client-side idle detection and no heartbeats at all. Clients only (a) poll status / receive the fan-out, (b) show the prompt, (c) relay the answer. This makes behavior identical on every platform by construction, works when the app is killed (the server job stops the timer regardless), and can't be defeated by mouse jitter.

Platform delivery notes

• Android: the reliable no-push path is an exact system alarm (setExactAndAllowWhileIdle, SCHEDULE_EXACT_ALARM, fall back to inexact) scheduled at the next deadline, posting a high-priority notification with Yes/Stop actions — fires even if the process was killed. While the timer runs, the foreground service is the primary path anyway.
• iOS: scheduled local notification at the deadline with an actionable category (no push infra needed; force-quit cancels it — acceptable, the server grace-stop covers it).
• Extension (MV3): chrome.alarms at the deadline + notification buttons; no chrome.idle needed.
• Desktop: prompt from the status payload; no powerMonitor polling.
• Web: Web Push + Socket.IO (already exists) + in-page toast.

[MacJediWizard]

I've been working in the idle-timer path recently (opened #752 for a related bug) and read through the current main, so here's a point-by-point validation against the two concrete problems reported on v5.13 — the idle machinery has been reworked since then, and both look addressed on main:

1. "Notification fires since you started the task." The sweep now only acts once a timer is genuinely past the window: cutoff = now - idle_timeout_minutes, and it selects a timer only when last_heartbeat_at < cutoff (or start_time < cutoff for a never-heartbeated timer). So the "Still working?" prompt fires after the full idle window, not from the moment the timer starts.

2. "No answer → task closed with 0 min at the start time." That behavior is gone. On main the default path after the 5-minute grace is to flag the timer needs_review (idle_flagged_at) and keep it running — it is never stopped at start_time and never truncated to 0. When a stop does happen (the opt-in safety cap, idle_auto_stop_hours > 0, or the user resolving via POST /api/v1/timer/review → trim), the credited end time is last_active + idle_timeout, i.e. it records the configured idle window as worktime — never 0, never past now. That matches the "a 30-min idle timeout should record 30 min" requirement.

3. Delivery to phone / desktop / extension. _send_idle_push fans the prompt out over Web Push + a Socket.IO broadcast to the user's room, and mobile/desktop pick up idle_notified from GET /api/v1/timer/status on their next poll — so it's no longer web-only.

Related hardening (#752): a paused timer used to get idle-swept (notified/flagged) even though it's intentionally accumulating no time. #752 adds a paused_at IS NULL guard so pause/resume no longer trips the idle safety net.

That leaves what I'd call a genuine design decision rather than a bug: the reporter wants no answer → auto-stop crediting the idle window by default, whereas main deliberately defaults to flag + keep running (auto-stop is opt-in via idle_auto_stop_hours) so a missed notification can never silently truncate real work. Both are reasonable; it's a maintainer call. If the goal is to give the reporter their exact behavior without removing the safety-first default for everyone else, one option is a per-user (or per-settings) "on no answer: stop vs. flag" preference, where "stop" reuses the existing last_active + idle_timeout credit path.

The larger proposal above (server-scheduled checks, first-answer-wins across devices, dropping heartbeats entirely) is a bigger change and probably deserves its own issue/discussion so it doesn't get lost in this thread.

[Giorgio-Germani]

The Still working reminder is frustrating to be honest. i tested it for quite a while but since the deliverability on different platforms just isnt working reliably without a push mechanism i think this feature should be reverted / removed. the only real solution is strict self discipline to never forget the tracker running. if it runs over night, yes there should be a popup to fix the issue right away next day, but the stopping mechnism can be removed, its not making things better to be honest, now instead of to much, i simply end up tracking to less.