# ActivityWatch: a local-first time tracker you can extend with your own watchers

> ActivityWatch records the active window, browser tab and keyboard activity into a local SQLite store you control. It is a good fit for people who want raw event data and a REST API rather than a hosted dashboard, and a poor fit for anyone who needs a managed sync service today.

**ActivityWatch/activitywatch** — The best free and open-source automated time tracker. Cross-platform, extensible, privacy-focused.

- Repository: https://github.com/ActivityWatch/activitywatch
- Website: https://activitywatch.net/
- Stars: 19,016 · Forks: 1,022
- Language: Python
- License: MPL-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/activitywatch-activitywatch

## What ActivityWatch records, and who the raw data is for

ActivityWatch is an automated time tracker. The README states the goal plainly: enable collection of as much valuable lifedata as possible without compromising user privacy. It does that by keeping storage on the user's local machine and by splitting collection into separate programs called watchers, each responsible for one kind of signal.

The bundled watchers cover three things. aw-watcher-window records the currently active application and the title of its window. A browser extension records the active tab, its title and its URL. aw-watcher-afk uses keyboard and mouse activity to decide whether you are away from keyboard. There is also aw-watcher-input, which the Makefile places behind an AW_EXTRAS flag rather than in the default build.

That split is the whole design argument. A single daemon that guesses at your day gives you a summary. Separate watchers give you raw, timestamped events that you can re-query later, after you have changed your mind about what you wanted to measure. The target user is someone who wants the second thing: a quantified-self hobbyist, a researcher who needs per-event granularity, or an engineer who intends to write a watcher for a signal the project does not cover yet. The README explicitly invites that last group, saying it hopes some users will help write watchers so more data can be collected.

If you only want a weekly pie chart of hours per project, this is more machinery than you need.

## How the server, watchers and aw-qt launcher fit together

The repository is a bundle of submodules rather than one program. The top level contains aw-core (shared models and the datastore layer), aw-client (the HTTP client library), aw-server (the Python server), aw-server-rust (a second server implementation in Rust), aw-qt (the desktop launcher), the three watchers, and aw-tauri, a newer desktop shell.

The data flow is a loop. A watcher samples its signal, wraps each sample into an event with a timestamp and a duration, and posts it over HTTP to the local server. The server persists events and answers queries. The web UI, served by the server, reads those queries back. Because every watcher talks to the same HTTP interface, writing a new one does not require touching the server. That is the extensibility claim in the README made concrete.

The Makefile shows how the pieces are assembled for a release. Its default SUBMODULES list is aw-core, aw-client, aw-qt, aw-server, aw-server-rust, aw-watcher-afk and aw-watcher-window. Setting TAURI_BUILD=true swaps aw-qt for aw-tauri, and on Linux that path also pulls in awatcher, described in the Makefile as a Wayland-compatible window watcher. Two flags trim or extend the set: SKIP_SERVER_RUST=true removes aw-server-rust, and AW_EXTRAS=true adds aw-notify and aw-watcher-input.

The presence of two server implementations is worth noting. aw-server-rust exists alongside the Python server, and the Makefile treats the Rust one as optional. The README does not explain when to prefer one over the other, so a user choosing between them is working without guidance from the project's front page.

## Installing ActivityWatch on Linux, Windows or macOS

The README does not list package manager commands. It points to the releases page for downloads and to the getting-started guide in the documentation for setup instructions. That is the honest starting point: check the releases page for your platform, and read the getting-started guide before running anything.

If you want to build from source, the Makefile header links to the installing-from-source guide and recommends creating and activating a Python virtualenv first. The root pyproject.toml pins python = "^3.9" and declares package-mode = false, which means the root project is a build orchestrator, not an installable package. The commented-out path dependencies for aw-core, aw-client and the watchers carry the note that installing them from the root will not work.

Once a build or download is in place, the Makefile exposes the usual targets:

```bash
make build
make install
make test
```

The bundle is normally started through aw-qt, the launcher that the default SUBMODULES list includes. In day-to-day use you start aw-qt rather than the server and each watcher separately. The README does not document what aw-qt does when a watcher fails to start, so treat the launcher as convenient rather than as a supervisor with defined failure semantics.

After the first run, open the web UI the server serves and confirm that events are arriving. The README's screenshots are labelled with older versions (v0.9.3 for the activity view, v0.8.0b9 for the timeline) and it directs readers to the website for newer ones, so expect the current interface to differ from what the README shows.

## Where ActivityWatch gets in the way

The README is candid that synchronization is unfinished. Under common dealbreakers it lists lack of synchronization, and then qualifies even the partial answer: when sync is available, it is centralized and the sync server knows everything. The feature comparison table begins with a Basics section whose Sync column is cut off in the README text. Nothing in the repository documentation describes a working, self-hostable sync server. If your requirement is one timeline across a laptop, a desktop and a phone, ActivityWatch does not currently meet it.

Mobile is the same story. There is no Android or iOS component in the top-level repository listing, and the README does not describe one.

There is a second, quieter cost. Because watchers store raw events, the database grows with everything you do, and the value of the tool depends on queries you write yourself. The README does not document retention policies, database size limits or pruning. A user who wants a tool that quietly summarizes and forgets is fighting the design.

Finally, the release channel matters. The three most recent releases listed are v0.14.0b8, v0.14.0b7 and v0.14.0b6, all published within three days of each other in September 2026. The b suffix and the cadence say these are beta builds. The root pyproject.toml declares version 0.14.0, so the stable line and the beta line are close together, but anyone deploying this on a work machine should decide deliberately which of the two they are tracking.

## How ActivityWatch differs from RescueTime and Clockify

The obvious alternative category is hosted time trackers. RescueTime and Clockify both run in the cloud: the vendor's servers hold your activity records, the analysis happens there, and you get a dashboard in a browser without installing a database.

The difference is not just where the bytes sit, it is what you can ask. With a hosted tracker, the questions you can pose are the ones the vendor built into its reporting UI. ActivityWatch keeps events locally and exposes them over an HTTP API that any watcher or client can query, which means the question set is open. The README frames the trade the other way round, arguing that closed source solutions suffer from privacy issues and limited features, while open source ones target programmers and lack a proper API.

That framing is fair but incomplete. Hosted tools win on the things ActivityWatch has not finished: sync across devices, a mobile app, and a reporting layer that does not require you to know what you want to measure before you measure it. A user who wants a weekly report emailed to them on Monday should not pick ActivityWatch. A user who wants to correlate window titles with AFK state across six months of their own data, and is willing to write the query, should.

## Licence, upgrade cost and citations

ActivityWatch is licensed under MPL-2.0, stated in the README badge area, in the root pyproject.toml license field and in LICENSE.txt. MPL-2.0 is a file-level copyleft licence: modifications to covered files must be made available under the same licence, while larger works that combine it with other code can be distributed under other terms. If you plan to embed ActivityWatch components in a product, read the licence text and get your own advice; nothing here is legal advice.

The upgrade cost is dominated by the beta cadence. Three beta releases landed in three days in September 2026, which means the project is moving quickly and that pinning to a specific build is the only way to get reproducible behaviour. The root pyproject.toml also pins Python to ^3.9 and constrains setuptools to >=78.1.1,<81 with a comment explaining that PyInstaller still imports pkg_resources, which setuptools removed in version 81. That is a build-time constraint you inherit if you package the bundle yourself.

For research use, the README asks that you cite the project. The canonical reference is the Zenodo DOI 10.5281/zenodo.4957165, and the README provides ready-to-paste BibTeX. Note that the BibTeX entry lists version 0.13.2 and year 2024, which is older than the 0.14.0 version in pyproject.toml. If your methods section needs the exact build, cite the DOI and state the version you actually ran.

## Conclusion

Adopt ActivityWatch if you want raw, local, queryable activity data and are willing to run a Python service on your own machine; skip it if you need managed cross-device sync or a polished mobile client, neither of which the repository documents. Before committing, check the releases page for a build of v0.14.0b8 or later for your platform and confirm that aw-qt starts aw-server and the watchers together, since that launcher is what most users actually interact with.

## FAQ

### Is ActivityWatch safe to use?

The README states that data is stored on the user's local machine and that the user controls it. Watchers send events to a local server over HTTP. The README does not describe any telemetry upload, but it also does not document a security audit, so verify the network behaviour yourself if that matters to you.

### Is ActivityWatch free?

Yes. The repository is licensed under MPL-2.0 and the README describes it as the best free and open-source automated time tracker. The README links to a donation page, which is optional.

### What is ActivityWatch and what can it be used for?

It is an automated time tracker that records the active application and window title, the active browser tab with its title and URL, and keyboard and mouse activity to detect AFK periods. The data is stored locally and queried through the server's HTTP API, so it can be used for personal analysis or as a research dataset.

### How do I install ActivityWatch on Linux?

The README does not list Linux package commands. It directs users to the releases page for downloads and to the getting-started guide in the documentation for setup. Building from source is covered by the installing-from-source guide, and the Makefile recommends activating a Python virtualenv first.

### Is ActivityWatch legit?

It is a published open source project under MPL-2.0 with a documented release history and a Zenodo DOI for citation. The README does not describe any commercial backing, and the project's funding badge shows a small monthly budget from supporters.

## Sources

- [ActivityWatch/activitywatch on GitHub](https://github.com/ActivityWatch/activitywatch)
- [License: MPL-2.0](https://github.com/ActivityWatch/activitywatch/blob/master/LICENSE)
- [Project website](https://activitywatch.net/)
- [README](https://github.com/ActivityWatch/activitywatch/blob/master/README.md)
- [Releases](https://github.com/ActivityWatch/activitywatch/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/activitywatch-activitywatch