How to keep a work log you can search a year later.

Most work logs fail the same way. You keep one for six months, you write in it on most days, and then someone asks when a problem started and you spend twenty minutes scrolling without finding the answer. The notes were there the whole time. Nothing could read them back.

The failure is rarely discipline. People who keep a log are usually willing to keep it, and the writing habit is the part they already solved. The failure is that the log has no structure a machine can hold onto, so retrieval collapses into scrolling, and scrolling stops working somewhere around month three.

Start with one rule.

A line that contains nothing but a date starts a new entry. Everything below it, until the next line like it, belongs to that day. That is the entire format.

19/07/2026
Chased TICK-1842 with @dana. The vpn.internal.example tunnel into
prod is still dropping every few hours.
#checkout p95 sitting at 480ms, retested once INC-9021 closed.

20/07/2026
Rolled the tunnel config back to the previous revision. #checkout
p95 down to 210ms. Left TICK-1842 open until it holds for a week.

There is no front matter, no template to fill in, and no field you have to remember to populate. A date line, then prose, in whatever file you already write in.

Why the date carries so much.

A date turns a pile of text into a sequence, and sequence is what makes the useful questions answerable at all. When did this start. How often does it happen. Is it getting worse or better. What else was going on that week. None of those can be asked of an undated blob no matter how well it is written.

The date also gives every later piece of structure something to hang on. A reference that appears on the 19th of July and again on the 3rd of September is a pattern with a shape and an interval. The same reference in an undated file is a repeated string and nothing more.

Write the identifier, not the pronoun.

This is the one habit that decides whether the log is worth anything in a year, and it costs nothing once you notice you are doing it. Name the thing every time, including the times when the context makes it obvious to you as you type.

Two versions of the same afternoon, written by the same person:

The tunnel was dropping again so I retested after the other ticket closed. Still slow.

The vpn.internal.example tunnel was dropping again, so I retested TICK-1842 once INC-9021 closed. #checkout p95 still 480ms.

The first is honest and completely useless later. There is nothing in it to search for. Six months on, "the tunnel" is one of four tunnels, "the other ticket" is unrecoverable even by the person who wrote it, and "slow" is not a number anyone can plot. The second took about four extra seconds to type.

Each row costs a few more seconds than the one above it. The bottom row is not a different writing style, it is the same sentence with the names left in.

What one file turns into.

What is worth writing down.

• Anything with a name. Ticket references, hostnames, tags, the people you talked to. These are the handles you will pull on later.
• Numbers you measured. A latency, a queue depth, a row count, a duration. One number in an entry is worth more than a paragraph of "much slower than usual", because a series can be drawn from it.
• Decisions, with the reason. The decision is usually recoverable from the code. The reason almost never is.
• What you tried that did not work. This is the most valuable and the most commonly skipped. Nobody records dead ends, so everybody repeats them, including the person who hit them the first time.

And what to leave out. Do not restate the ticket description, because the ticket system already has it and your copy will drift out of date. Do not log anything a system already records for you accurately. Do not write a tidy summary at the end of the week, because a summary is a compression of the details you needed, written at the exact moment you have forgotten them.

What this costs.

The identifier habit is real work, and it fails in a predictable place. Entries written while you are tired, mid-incident, or annoyed are the ones with "the thing" and "that server" in them, and those are usually the days you most want back later. Nothing in the format saves you from that. It helps to reread the previous day's entry before writing a new one, which surfaces your own vague sentences while you still remember what they meant.

Structure derived after the fact can only see what is actually in the prose. If the words are not there, no amount of processing invents them. A log that says "broke again" stays unsearchable forever, and that limitation is worth understanding before you rely on the approach. It is the flip side of the thing that makes it work, which is that you never have to fill in a form.

The format is also poor at half-formed thinking. It is good at recording what happened and what you measured. Notes that are mostly speculation, with no nouns anyone else would recognise, come back out about as useful as they went in.

Where to start.

Open the file you already keep and put a date line above today's entry. That is enough to begin, and it is reversible, because a date line is still plain text and every tool you own still reads the file. The habit of naming things develops on its own once you have tried to retrieve one week from a log that did not do it.

The next question is what you can actually ask once a few months of this exists, which is the subject of the second article below.