The Journal That Writes Itself

Every meaningful change in my homelab writes an event to a ledger — a deploy, a config change, an incident, a decision. That is useful for machines and nearly useless for me, because nobody reads an event stream.

So two scheduled jobs sit on top of it. The first turns the last twenty-four hours of events into a written Markdown summary in an outbox. The second, half an hour later, publishes that summary to my notes app as a single memo.

Small pipeline. Three details in it took real effort.

The idempotency key lives in the artifact

Each memo ends with a day marker tag. Before publishing, the job searches for that marker; if it finds one, it skips.

The naive alternative is a local state file recording what has been published. I have written that version before and it is wrong in a specific way: the state and the thing it describes live in different places, so they can disagree. Delete the memo and the state file still says published. Restore from a backup and you get a duplicate. Run from a second host and you get two of everything.

Putting the key inside the published artifact makes the destination the source of truth about what is in the destination. There is no second copy to drift.

It fails closed

If the duplicate check itself cannot complete — the notes API is down, the search errors, the response is unparseable — the job does not publish. It fails, loudly, having written nothing.

This is the branch that most such scripts get wrong, because the tempting behaviour is to assume no duplicate was found and carry on. That converts a transient outage into permanent duplicate content, and it does it at the exact moment you are least likely to be watching. If you cannot prove you have not already done a thing, you have not earned the right to do it.

The deploy is a git pull, which I forgot

This pipeline runs on a different host from the one I develop on, and deployment is a git pull on that host.

I spent a day debugging a failure that I had already fixed. The fix was on my workstation. The pipeline was running the previous commit, faithfully, exactly as instructed. Every log line I read was truthful and every one of them described code I no longer had.

The lesson is not "remember to deploy." It is that a pipeline should be able to tell you which version of itself it is. When the answer to "why is the fixed code still broken" is "it isn't the fixed code," you want that visible in the output rather than deducible after an afternoon.

Why bother

Because a homelab where the work is invisible is a homelab where the work stops. A written daily summary, in the same app as the rest of my notes, means the system reports to me in a place I already look — not in a dashboard I have to remember to open.