How timer policies work — and what a pending switch means for you
What timer policies are
Admins can set three policies that shape how time is tracked. Timer concurrency decides whether you can run several timers at once, one per workspace, or only one in total. Overlap policy decides what happens when two saved entries cover the same minutes. Time-entry classification decides whether an entry needs a project (and task) before it can be saved.
Concurrency is set for the whole organization; each workspace can override it and also sets its own overlap and classification rules.
Why a change can wait — “pending” switches
Tightening a policy while people are mid-work could strand them — for example, refusing overlaps while your running timer already clashes with a finished entry would make that timer impossible to stop. So instead of failing, the change is stored as pending: the old policy stays fully in force, and the switch applies by itself the moment the last affected member is in the clear.
How long a concurrency switch waits depends on how strict it is. A switch to one timer per workspace waits until nobody has two timers running in the same affected workspace; a switch to one timer at a time waits until every affected member is down to one running timer overall. An overlap switch waits until no running timer overlaps an entry its owner already finished. Loosening a policy — including going from one timer at a time to one per workspace — and classification changes never wait: they apply instantly.
What it means for you
If you see an amber notice, your timers are the ones holding a switch back. Nothing is stopped for you and nothing expires — stop or adjust the flagged timers whenever suits you, and the new policy applies on its own. Stopping an overlapping timer while the switch is still waiting is always allowed: the overlap is recorded and kept (“grandfathered”).
When a policy actually changes, a blue notice tells everyone what is now in force. After a concurrency switch, starting a timer the policy does not allow asks to stop the conflicting one first — only that one; after an overlap switch, saving time that clashes with an existing entry is refused. Existing entries are never deleted or edited by a policy change.
Privacy
Admins only ever see how many members a switch is waiting on — never who, or what the blocking timer is. A blocking timer may live in another organization, and Keepr never reveals it exists.