What our logs keep, and where

When your data moved onto an encrypted disk, one thing stayed behind: logs. Some of them can't live on the encrypted disk, because they have to be readable while the machine is still starting up. So we looked at the problem from the other side. If a log has to sit on a plain disk, it shouldn't hold anything about your work.

What changed

The request log lives in memory. The web server's record of requests used to be written to the server's ordinary disk. It's now kept in memory only, so it's gone whenever the machine restarts, and it's small enough that it only ever covers recent traffic. The tool that blocks abusive traffic still reads it, and that tool keeps none of the lines it matches.

Logs no longer carry your data. We went through everything the application, the background worker, the backups and the database write to their logs, and removed anything that identifies your work or your people:

• issue and merge request titles, label names and branch names
• names, usernames and email addresses
• repository and project paths, including inside the addresses of calls we make to GitHub and GitLab
• the text of error messages that quote any of the above

What's left is what we need to keep the service running: internal IDs, counts, timings and which step failed. The database now logs errors briefly too, so a failed query doesn't copy its values into the log.

Webhooks keep less. A webhook from GitHub or GitLab waiting to be processed no longer stores the repository's path. GitGumbo only needs its ID.

What this is not

Logs are how we find and fix problems, so we still keep them. What changed is what they contain. A copy of our logs now tells someone that a sync ran and how long it took. It doesn't tell them what your team is working on.