ActivityWatch

Last reviewed Sep 13, 2026 · 827 words

Everything ActivityWatch records stays on the laptop that recorded it, because the whole program runs there: a tray application that logs which window has focus every few seconds and serves a dashboard on localhost:5600. That architecture is correct for the job, and it is why the "self-hosted" label needs a footnote. There is nothing to deploy on the homelab, the data never leaves the machine that produced it, and the interesting question for someone who runs their own services is how to fit a per-device desktop tool into a stack that lives on a server.

What the pieces are

The install is a bundle of small processes. aw-server stores events and serves the web UI; aw-watcher-window records the active application and window title; aw-watcher-afk decides whether you are present by watching keyboard and mouse input; aw-qt puts an icon in the tray and starts the others. Browser extensions for Firefox and Chromium add aw-watcher-web, which turns "Firefox" into the actual URL, and there are community watchers for editors, media players, and terminals. The whole set idles around 100 MB, inside the 128 MB rating, and the timeline updates within seconds. Download the release for your OS, run it, open the dashboard, and it is already recording. Easy is the correct difficulty label.

Where the data lives, and how to back it up

Everything sits in a per-user directory: ~/.local/share/activitywatch on Linux, the equivalent application-support folder on macOS and Windows. Inside is a single database per server instance. The own your data exports principle applies without any work on your part, because the export button in the settings writes the complete event history as JSON and the REST API on port 5600 hands it out to any script. If you want the history to survive a laptop dying, point your existing backup job at that directory; I include it in the same restic run that covers my dotfiles, and it has never been more than a few hundred MB after years of use.

Categorisation is the work nobody warns you about

Out of the box the dashboard tells you that you spent 4 hours in Firefox and 2 in a terminal. That is not the question you had. Answering "how much of this was actually work" requires categories, which are regular expressions over application names and window titles that you write yourself in the settings page. A rule like Work > Code matching code|nvim|Alacritty and Work > Docs matching docs\.google|confluence gets you 80% of the way in 20 minutes, and the remaining 20% is a slow tuning exercise over the first month as you notice uncategorised blocks. Nothing ships pre-trained, which is the honest price of the privacy model; the commercial tools categorise for you because they see everyone's data.

Multi-device is the weak spot

Each machine has its own server and its own database. The project has a sync mechanism that works by writing to a folder you replicate with something like Syncthing, and it is labelled experimental for good reason: it merges histories for viewing rather than giving you a single central server. Mobile is limited to an Android app that records app usage and nothing else; there is no iOS client, because iOS does not let a third-party app watch what other apps are doing. If your working life is split evenly across three devices, expect three dashboards, or expect to export from each and merge in a script.

What it is, and what it is not

ActivityWatch is a passive record of attention. It is not a timesheet. It does not know about clients, projects, or billing, and it will not produce an invoice. If what you actually need is "how many hours did I bill to client X", the tool that does that is a manual tracker like Kimai, which does run on your server and is built around projects and rates. If you want the coding-specific version of the same passive idea with a server component, Wakapi collects editor heartbeats from any machine into one self-hosted dashboard, which solves the multi-device problem for the one activity most self-hosters care about. The rest of the time tracking category splits along that same manual-versus-passive line.

What I'd do

Install ActivityWatch on the primary machine, add the browser extension, and spend the first evening writing categories. Add the data directory to the backup job that already exists. Leave sync alone unless a second machine is a genuine daily driver, and if you code on several machines, run Wakapi on the server alongside it instead of fighting the sync. Then check the dashboard weekly rather than daily; the value is in the trend, and the trend is what the RescueTime alternatives crowd came looking for in the first place.