Privacy policy

What logtop records, and what it never gets to see.

Version 1.0 · effective 17 September 2026

The short version. The desktop app watches which application is in front of you and whether you have touched the machine recently. It turns that into daily totals on your own computer and sends the totals. The detail stays behind.

No screenshots are taken. No screen is recorded. Window titles, page titles and URLs are never uploaded. Keystrokes are counted and never read.

If you are an employee: your employer decided to run this, chose the settings, and can see your numbers. So can you, on the same page, from the same rows. Ask them first about anything to do with why it is installed; ask us about anything to do with how it works.

1Who you are dealing with

logtop is built and run by one person, not a company. There is no registered entity behind it yet, and this page will say so until there is.

Operator: Aravind, Manjeri PO, Kerala, India. Contact: hello@logtop.org.

If that matters to you before you put logtop on a team's laptops, it should. A one-person operation can be reached directly and can change something the same afternoon. It also has no second engineer and no support rota. Both of those are true at once.

2Two different jobs, two different roles

Under the GDPR and laws written like it, logtop does two separate things, and the answer to “who is responsible for this data?” is different for each.

For the account itself (the address a company signs up with, what they are billed, the mail we send them), logtop is the controller. We decided to collect that, and we answer for it.

For everything the desktop app measures (hours, apps, sites, projects, typing rate), the employer is the controller and logtop is their processor. They decided to track their staff; we hold the result on their instructions. That distinction is not a technicality. It is why an employee asking us to delete their hours gets sent back to their employer: the data is not ours to delete, and a processor that quietly honours deletion requests behind the controller's back is a processor nobody can rely on.

The contract for that relationship is the data processing agreement.

3What the app measures

Every few seconds, on the employee's own machine, the app asks the operating system three questions:

It writes the answers into a database in the employee's own user profile: %LOCALAPPDATA%\logtop on Windows, ~/.local/share/logtop on Linux. Nothing is uploaded at this stage. Once every five minutes the app folds the raw rows into daily totals, and it is the totals that travel.

4What leaves the machine

Six kinds of row are sent to app.logtop.org, and this is all of them:

RowWhat it says
roll_day For one person on one day: seconds tracked, seconds active, and a keystroke count.
roll_app Seconds per application name. “Figma, 4h 20m.”
roll_site Seconds per domain, where one could be worked out from the window title. github.com, never a path.
roll_project Seconds per project name, where the employee picked one.
roll_bucket Active and idle seconds per fifteen minutes of the day. This is the timeline strip on the dashboard.
shifts A clock-in time and a clock-out time.

Each row carries the employee's user id and the date. That is the whole upload. A busy day is a few hundred rows and well under a hundred kilobytes.

5What never leaves it

The strongest thing we can say about this is not a promise. The database on the server has no column to put a window title in, so there is nowhere for one to arrive even by accident: a bug could not leak what there is no field to store.

That schema is one file. Ask for it at hello@logtop.org and we will send it, in full, whether or not you are a customer. Read the CREATE TABLE statements and search them for the word title.

6Keystrokes, precisely

The dashboard shows a typing rate in words per minute, and getting that number means noticing key presses. Here is exactly how far that goes, because “we don't log keystrokes” is what a keylogger's privacy policy also says.

The app registers for key-press events and adds one to a counter. It looks at the key's code to decide two things and nothing else: whether the press is a genuinely new one or the auto-repeat of a key being held down, and whether it is a modifier such as Shift, which does not count. The set of keys currently held exists in memory for as long as your fingers are on them, and is discarded on release.

There is no sequence, no buffer, no history. The only value that leaves that part of the program is an integer. It is not written to disk, to the network, or to a log, and there is no code path by which it could be.

We used to say the app never read keystrokes at all, which was true back when activity was inferred purely from the system idle clock. Adding the typing rate changed what the app observes, and this paragraph changed with it. On Linux the counter is not implemented and always reports zero.

7Websites, and why the list is imperfect

The app never sees a URL. What it sees is a window title, and browsers tend to put a site's name in it, as in “Pull requests · logtop - Chrome”. A domain is guessed out of that string and the guess is what gets uploaded.

This is worth being blunt about in both directions. It means the detailed address of the page you were on is genuinely not available to anyone, including us. It also means the site list is a best effort: a tab whose title mentions no site produces nothing, and a title that mentions the wrong one produces the wrong one. If a report says you spent an hour somewhere you did not, that is why.

8Account and billing data

To have an account at all, the server holds: a company name, and for each person an email address, a display name, a password hash, a role, a timezone, whether the account is active, and which team they are in. An administrator may also record an hourly rate, a contracted weekly hours figure, and booked leave.

Employees do not create these accounts. An administrator adds someone and hands them a one-time code; they set their own password when they redeem it. Nobody types another person's password into the product.

There is no payment processor. Invoices are worked out from the hours already on the dashboard and handled directly. No card number, bank detail or payment credential is entered into logtop, stored by it, or passed through it, because there is nothing in it that could take one.

9This website

logtop.org sets no cookies, runs no analytics, and loads nothing from a third party. The two fonts are served from this domain. There is no tracking pixel, no tag manager, no session recorder, and no consent banner, because there is nothing to consent to.

The dashboard at app.logtop.org also sets no cookies. Your sign-in token is kept in your browser's local storage, which is why signing out actually removes it rather than expiring something on a server.

Our host, Cloudflare, sees the ordinary things any web server sees: your IP address, the time, and which page you asked for. On the sign-in, password-reset and registration endpoints your IP address is used as a rate-limiting key, so that one machine cannot walk a list of addresses. That counter is Cloudflare's; the IP is not written into our database, and there is no column for it.

10Who can see what

An employee sees their own numbers, in full, on the same dashboard their manager uses. There is no quieter version of your activity that only one side is allowed to open.

An administrator or owner at your company sees everyone in that company: the same charts, per person, plus company totals.

Nobody at another company sees anything. Every row carries a company id, and the server derives that id from your sign-in token rather than from anything the browser asks for.

We can technically reach the database, because somebody has to be able to fix it. Accounts with that access are flagged in the database itself and cannot be granted over the web. Every cross-company action one of them takes is written to an audit table and kept permanently. We do not look at a customer's activity data except to investigate a fault they have reported to us, or where the law requires it.

11Where it is kept, and who else touches it

Two companies other than us are involved, and no others.

WhoWhat forWhat they hold
Cloudflare, Inc. Runs the server and stores the database (Workers and D1), and serves this website. Everything in section 4 and section 8, plus ordinary request logs.
Spacemail Sends the invitation, password and weekly summary emails. The recipient's address and name, and the contents of that message. A weekly summary contains employee names and their hours.

The database is Cloudflare D1 and is hosted on Cloudflare's infrastructure. logtop is operated from India. Where that country and our processors sit outside the EEA, a European customer's data reaches them under standard contractual clauses, which are part of the DPA.

The current list lives on this page. If another processor is ever added we will say so here before it starts handling anything.

12How long it is kept

WhatHow long
Raw samples on the employee's machine, including window titles 90 days, then deleted by the app itself. Configurable by whoever installs it.
Daily totals and shifts on the server 12 months rolling, then deleted. A scheduled job runs weekly and removes anything older.
Booked leave Kept while the account exists. It is a record your employer entered by hand, not something we observed, and deleting it would rewrite a leave balance.
Account details Kept while the company is a customer. Deleted within 30 days of the account closing.
Sign-in tokens Until you sign out, or until an administrator deactivates the account, which drops every token that account holds at once.
The cross-company audit trail Kept permanently, on purpose. An access log you can delete is not much of an access log.

Deactivating an employee keeps their recorded hours (a company's timesheets do not stop existing because somebody left), but the person can no longer sign in and no longer counts towards the bill.

13Security

Everything between the desktop app, your browser and the server goes over HTTPS. Passwords are stored as PBKDF2-HMAC-SHA256 hashes with a random 16-byte salt and 100,000 iterations, with the iteration count stored alongside each hash so it can be raised without locking anybody out. We never see a password: an invite code lets the employee set their own, and a reset issues a new one by mail rather than revealing the old.

Sign-in, password reset and registration are rate limited per account and per address.

No system is beyond reach, and a one-person operation is not going to claim otherwise. There is no SOC 2 report and no penetration test to show you. If you find something wrong, mail hello@logtop.org and it will be read by the person who can fix it.

14Your rights, and how to use them

Depending on where you live you may have the right to see a copy of your data, correct it, have it deleted, restrict or object to how it is used, and receive it in a portable form.

If you are an employee, the route runs through your employer for everything the app measured, because they are the controller for it. In practice you already have most of it without asking: your own dashboard shows every figure held about you, and Export gives you the same rows as a CSV. If your employer asks us to hand over or delete your data, we do it.

If you are a customer, write to us and we will deal with it directly. We aim to answer within 30 days.

If you think we have handled something badly, please tell us first: it is a short chain of command. You can also complain to your national data protection authority.

15Changes

If this page changes in a way that widens what is collected or who sees it, customers get an email before it takes effect, and the version number and date at the top change. Fixing a typo does not earn anybody an email.

16Contact

hello@logtop.org. One address, read by the person who wrote the code.