Tockler builds a work timeline from window titles and idle time

No timer, the window title is the clock

Tockler is described as a free application that tracks your time by monitoring your active window title and idle time. The project description puts it as an application that automatically tracks your computer usage and working time, and the homepage is tockler.trimatech.dev.

The mechanism is what makes it different from a stopwatch. There is no start button and no project to select, because the application is reading the operating system's notion of which window has focus and what its title is, and it is watching whether the machine has gone idle. Your work is the window titles, in order, with gaps where you stepped away.

That has an obvious appeal. Manual time tracking is the part of project administration people give up on, and a tool that requires nothing from you until you look at the report removes the failure mode. The cost is that the data is derived from your activity rather than your intent, so the report shows what you were doing rather than what you were working on.

The application is built with Electron, and the primary language of the repository is TypeScript. It runs on Windows, macOS and Linux, which the project lists as a feature rather than an afterthought, and the topic list carries both `osx` and `windows` alongside `electron`.

The audience is an individual who wants visibility into their own working day, and the licence is GPL-2.0, with the project stating plainly that it is free and open-source software.

What gets recorded, and where it goes

The overview section lists what the application gives insight into, and it is worth reading the list as a data inventory.

There is application usage and window titles. There is computer state, described as idle, offline and online. There is an interactive timeline visualisation. There are daily, weekly and monthly usage statistics. And there are calendar views and charts.

The features section repeats the same material in user-facing terms. Time tracking is described as going back in time and seeing what you were working on. Application monitoring tracks which apps were used and their window titles. Usage analytics gives total online time, application usage patterns and trends. And the interactive timeline visualises computer usage with an interactive chart.

Two things in that list are worth pausing on. The first is that window titles are captured, not just application names, and a window title frequently contains the name of a document, a customer, a ticket or a search term. The second is that the record is per application and per title over time, which is a detailed history of what you worked on, not a summary of it.

That is why the repository carries a `PrivacyPolicy.md` alongside the licence and a `BACKEND.md` describing the server side, and why a reader who wants to know where the data goes should read those two files before running it on a work machine. The repository also contains a `.sentryclirc`, which indicates error reporting is wired up through Sentry.

None of this is a criticism of the design. It is the design, and it is why the tool is most useful on a personal machine and most questionable on a shared one.

Downloads are per-platform binaries, portable builds included

The download section is a list of release links, and the shape of it tells you about the audience.

For Windows there are setup installers and portable packages, in four flavours each: Universal, x64, ARM64 and 32-bit. The Universal builds are the ones that run on both Intel and ARM hardware, and the 32-bit build is there for the older machines that people still use for older software.

For macOS there are two disk images, a Universal one and an Apple Silicon one. For Linux there is a single AppImage.

The presence of portable packages on Windows is the detail that matters most for an evaluation, because a portable build does not install anything, which means a developer can run Tockler from a USB stick or a folder without registering it, and can remove it by deleting the folder.

Everything comes from the GitHub releases page, and the project links the latest release and the full release history from the same place, with a downloads badge pointing at the total and another at the latest release's total.

The releases themselves are dense in the 4.0 line. Version 4.0.20 was published on 2025-04-07, 4.0.21 on 2025-04-10 and 4.0.22 on 2025-04-12, three patch releases in five days.

The project also runs several funding channels at once, with badges for GitHub Sponsors, Open Collective, Patreon, Ko-fi and PayPal, and a note asking people to support the development if they find it useful. It is a single developer project by the look of the repository, and the funding links are how that is sustained.

An Electron shell with a separate client and a backend

The repository layout shows a three part application rather than a single Electron blob.

There is an `electron/` directory for the desktop shell, a `client/` directory for the user interface, and the `BACKEND.md` document, which suggests the server side is documented separately from the desktop code. The `env.sample` file at the root is the environment configuration template, and `.sentryclirc` holds the Sentry configuration for the error reporting.

There is also a `design.sketch` file, which is a small and revealing artefact. It means the interface was designed in a dedicated tool rather than sketched directly in code, and it tells you the visual work was done outside the repository.

The `screenshots/` directory is organised into light and dark themes, and the README shows the same set of views in both: a timeline, a settings screen, a summary calendar, a summary chart, a search screen and a tray window. The presence of light and dark variants across every screen, rather than a dark mode added later, suggests theming was part of the design from the start rather than an afterthought.

The tray window is worth a note, because it is the part of the interface that has to be invisible until it is wanted. A tracker that demands attention is a tracker nobody keeps running, and a system tray presence is the minimum for an application whose job is to run all day without being in the way.

The `badges/` directory at the root holds the badge images used in the README, and there is an `appveyor-tockler.cer` certificate file, which is a Windows code signing certificate and the artefact needed to sign the Windows installers.

The timeline is the product, not the timer

What Tockler produces is a picture rather than a total, and the screenshots make the hierarchy clear.

The timeline is the centre of it. The feature list calls it an interactive chart, and the screenshot set leads with it in both themes. The set also shows the summary in two forms, a calendar and a chart, for the daily, weekly and monthly views, plus a search screen, a settings screen and a tray window.

The ordering says something about the intended workflow. You are not asked to file time into projects, and there is no project field in the feature list. The unit of information is the window title and the period of time, and the aggregate views are the layer that turns that into something you can read.

For most people the useful question is not which project did I bill for, it is where did the day go, and this answers the second question without the ceremony of the first. The usage analytics view of total online time, application usage patterns and trends is the version that is meant to be looked at over weeks rather than minutes, and the calendar view is the one that sits in a workflow of looking at the week.

There is also the framing in the project description that it provides detailed insights into your computer usage and working time, and the phrase go back in time and see what you were working on. That is a retrospective tool, and it works best for someone who has already stopped worrying about what they are doing and wants the pattern instead.

None of that removes the need for judgement. A title that is the same for an hour of reading and an hour of editing is one number, and the tool cannot tell the difference. The accuracy of the report is the accuracy of your titles.

Where automatic tracking is the wrong tool

The limits here are not about the software, they are about what window title monitoring means in different settings.

The first is shared machines. On a machine with more than one user, or a machine that an employer monitors, an application that records every window title in order is a record of what everyone who used the machine did. On your own laptop it is a diary. In an office it is something else, and a project cannot tell you which it will be, because it has no way to know whose machine it is on.

The second is precision. A title is a string, and the same title can mean reading, editing, copying and a phone call. For a personal review, that is a good enough signal. For billing, for a payroll record, or for anything an employee disputes, it is not evidence of anything, and the application offers no way to attach a note to an interval or to correct a title. The distinction is the same one that separates an activity log from a timesheet.

The third is coverage. What the operating system reports as an active window is only part of the picture. Work in a terminal, in a full screen editor, or in a virtual machine may not surface the title you would want recorded, and the application is working from what the OS gives it.

The alternative approach, and the difference in approach is real, is manual tracking with a timer or a timesheet, which costs attention but produces a record that reflects intent rather than activity, and which can be corrected afterwards. A third option is a server-side or team time tracker where the data comes from people rather than from the machine, which also changes who the data belongs to.

Tockler's position between those is the interesting one, and it is only safe where the person running it already has the right to look at the machine, which on a personal device is you.

Editorial conclusion

Tockler suits a person who wants to see where their working day actually went without keeping a stopwatch running, and who is comfortable with a desktop application that reads window titles to do it. It is the wrong tool for shared or monitored machines, where the same feature becomes surveillance of other people, and the wrong tool if you need to record time against billable clients with the precision and audit trail that implies. Check first the privacy policy in the repository, since window titles are the source data here, and note that the last push was on 2026-04-08 with the newest release from April 2025.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. MayGo/tockler on GitHub
3. Project website
4. README
5. Releases