How to Keep a Proper Logbook For Mechanical Keyboard Monthly
Most people build keyboards and then forget what they actually put together. I've been doing this long enough that I remember my first build from 2014 but not the one from last month. That's why I started logging everything, and it turned into something that actually helps. It's not a spreadsheet. It's a record of what you assembled, what sounded wrong, what you changed, and what you learned. I track the switch type and brand, the spring weight, the plate material, the stabilizer setup, the case material, and the firmware if I'm flashing anything custom. The monthly format just means you add a new entry at the end of each month instead of trying to remember everything later. Here's what I do. At the top of each entry I put the date, the keyboard name and case type, and a link to where I bought the parts. Then I list the switches with their actuator type and spring weight. I note the plate material and thickness. I describe the stabilizers and whether I lubed them, which lube I used, and the wire gauge if I switched the whole wire out. If I ran any remap or macro work, I log the keybind layout and the firmware version.
I also record the sound profile and who it is for. This sounds odd until you're comparing two boards and realize one is thocky because of foam and the other is just springy because of the switch choice. Those details matter.
How I Set Up the Template
I use a simple markdown file in Obsidian, but this works in a Google Doc, a Notion page, or a physical notebook. The structure stays the same. Each entry is a header, followed by bullet points for specs, a paragraph for sound notes, and a paragraph for bugs or changes. I keep a running index at the top with month and board names so I can find things later. If you want something downloadable, I made a basic template that matches my setup. It includes fields for switch brand and model, spring weight, plate material and thickness, case type, stabilizer brand and wire gauge, foam layers and type, keycap profile and material, firmware version, and a section for sound notes and issues. You can copy it into your tool of choice or download the latest version from the shared folder I keep updated. The file is plain markdown so it works anywhere. Logbook For Mechanical Keyboard Monthly isn't a product, it's a practice. The template is just a scaffold.
Get the Full Details
A Practical Problem I Ran Into
One month I logged a Periphilla build with a custom gasket mount, a polycarbonate plate, and Kaihua Boba U45 switches lube-tuned with Tederman Lube. The board sounded great, but after three weeks the spacebar started rattling on the right side. I checked the logs and realized I hadn't written down which stabilizer cups I'd used. The stabilizer came with standard cups that didn't match the plate holes, and the wire had rotated over time. The workaround was to replace the cups with the 6mm ones from the GMK-compatible set and rotate the wire clockwise by a quarter turn during re-lube. I also added a line to my template that now includes a stabilizer cup size field. That's the kind of detail you miss until you lose it.
Counter-Intuitive Things I've Learned
People assume more foam always makes a better sound. It doesn't. I've seen boards with four layers of foam sound duller than boards with one layer because the foam trapped high frequencies instead of tuning them. What matters is how the foam interacts with the case material and the plate. A thick aluminum case with too much foam becomes a muffled drum. A polycarbonate case with the right amount of foam can sound open and sharp. Another thing: lubing stabilizers doesn't fix a bad design. I spent an afternoon lube-tuning a set of stock GMK compat stabilizers that had a loose cup fit. The lube helped a little, but swapping the cups for a tighter set fixed the rattle permanently. Lube is a tuning step, not a structural fix.
Pitfalls to Avoid
The biggest mistake I see is tracking the final build but not the changes. You log the switches you bought, but not the ones you swapped out after two weeks. You log the case you started with, but not the foam you added later. If you only record the end state, the log becomes useless for troubleshooting. Another issue is mixing up spring weight notation. Some switches list the actuator force and others list the total spring weight. I've logged the same switch twice with different numbers because the manufacturer uses different standards. Always verify which measurement is which before writing it down.
When a Logbook Won't Help
If you're just typing and don't care about sound, build quality, or troubleshooting, a logbook adds overhead. A regular notes app or a spreadsheet might be enough. The logbook is worth it if you change parts often, if you compare boards, or if you want to reproduce a build later. If you buy one keyboard and keep it forever, you probably don't need this level of documentation. Keep it consistent. One entry per month is enough. Write down what changed, not just what you bought. Include the sound notes and the issues, because those are the parts you'll remember least. Revisit the log every few months and update it when you find a mistake or add a new insight. Here's a realistic timeline for setting this up. If you start with the template I linked above, you can have a working system in about 20 minutes. Logging a new build takes about five minutes if you already have the specs ready. If you're gathering specs from scratch, it might take ten to fifteen minutes. The savings come later when you're trying to figure out why a board sounds different after a month or two.
I use the log when I'm deciding whether to keep a board or sell it. I also use it when someone asks me for a recommendation and I need to remember what I liked or didn't like about a specific switch or plate combo. It's not glamorous, but it cuts down on guesswork significantly. If you're looking for the actual template file, search for Logbook For Mechanical Keyboard Monthly in the shared resources thread. The file is free and open source. I update it when I find a better field or notice a common mistake. If you spot an error or have an improvement, drop it in the comments. That's how it stays useful.
