ActivityWatch: a private ledger for reflection

Measurement is not memory

Most workdays leave two imperfect records: what we remember doing and what the computer happened to observe. ActivityWatch makes the second record inspectable. Its watchers capture events such as active windows and away periods, its local server stores them in buckets, and its interface combines those events into a timeline. The project's privacy policy says the standard application stores activity data locally and does not transmit it to the developers or third-party analytics services.

That architecture matters because activity logs can be unusually revealing. A window title may contain a client name, a medical subject, or the draft title of an unannounced project. Local storage removes one routine disclosure path; it does not make the data harmless. ActivityWatch's own security notes warn that the local API lacks strong authentication and that malware or another user on the same host may reach the database. Treat the timeline as sensitive source material, not a cheerful productivity score.

A decade-old quantified-self experiment

ActivityWatch is underexposed partly because its story is longer and stranger than a typical timer. The project's history traces its motivation to quantified-self experiments in 2013, a prototype begun in December 2014, and a 2016 rewrite that introduced the client-server model behind the current system. That lineage explains the modular design: a watcher produces observations, the server stores events, and clients query them.

The useful unit is not necessarily a raw event. ActivityWatch's data guide recommends canonical events that combine window tracking with away detection, categorization, and multi-device handling. It also supplies examples for working-hours analysis, category suggestions, redaction, and bucket merging. Users can export JSON or query the REST API, but the project's export guidance recommends aggregating and redacting locally before any data goes to an AI assistant or another service.

What actual use can establish

The strongest evidence for automatic tracking is not that it makes everyone more productive. It is that recollection and observation diverge. ActivityWatch documents a Research Edition used in academic studies; its research overview cites a validity study where self-report agreed with software registration for only 18 percent of participants. That result supports careful measurement, not a claim that recorded screen time equals meaningful work.

Outside research, workflows vary. In one recent community discussion, users described reviewing reports or feeding locally processed summaries into task workflows. Such accounts are anecdotal rather than adoption statistics, but they show the practical fork: some people inspect dashboards, while others use exports as input to their own systems. A useful weekly review might ask:

• Which project consumed more time than expected?
• Which interruptions recur at the same point in the day?
• Which categories are wrong because the rules need adjustment?
• What decision should survive after the raw timeline is forgotten?

Give conclusions a durable home

That last question is where Trilium Notes becomes a useful companion. Trilium is not an ActivityWatch integration; pairing them is an editorial workflow. Its project overview describes a local, offline-capable personal knowledge base with optional synchronization through a self-hosted server. Notes can be nested without a separate folder type, placed in multiple parts of the tree through cloning, and connected with labels and relations. The note model suits a project journal that needs both chronology and structure.

The tradeoff is explicit. Trilium stores its knowledge base in SQLite rather than exposing a directory of Markdown files. Its FAQ argues that transactions, note clones, ordering, attributes, and fast relations justify the database, while acknowledging that filesystem interoperability would be simpler. Synchronizing multiple devices requires its server. Users who prioritize ordinary files and Git should choose another notes system.

Community experiments also show why context needs care. In a Trilium discussion, users described dedicated note trees, context maps, incremental indexing, and the difficulty of preserving relationships when notes are copied into vector stores. Those are individual reports, not endorsements or benchmarks, but the failure mode is instructive: automation can retrieve text while flattening the structure that made it intelligible.

Keep observation, interpretation, and retention separate

A restrained workflow uses three layers. ActivityWatch records locally. A human reviews aggregates and checks whether categories reflect reality. Trilium keeps only the conclusions worth retaining: a project note, a decision, a recurring distraction, or a change to next week's plan. Raw events need not become permanent notes, and neither tool needs access to the other's database.

That separation limits damage and makes the process easier to audit. Back up both stores, redact before exporting, and periodically delete detail that no longer serves a purpose. Most importantly, resist turning a timeline into a verdict. ActivityWatch can tell you which application was foregrounded; only reflection can explain why it mattered.