Announcing watchlog

Posted on 2021-04-21

Here I would like to make a short announcement about a simple command-line tool I wrote, watchlog.

The Problem

I am frequently watching some log while I am working. Whether they is access logs, error logs or just build logs I often run across the same issue. I don’t know if the most recent logs on the screen are from just now, or ten minutes ago. Are they from that action I just performed, or from a previous attempt? Countless minutes have been wasted because I fixed an error, but thought that it was still occurring because after a re-run the previous error was still last item in the log.

Previous Hacks

My most common “solution” was just focusing the window and mashing enter a couple of times before running a new test. This worked, as I knew that any logs at the bottom of the window were new, but was tedious. One day I realized that a solution could be as simple as a command that outputs a newline every couple of seconds. This would not be too intrusive, but you can easily estimate an upper bound on log age based on how close the line is to the bottom of the terminal.

The Solution

When I realized how simple the solution could be I decided to polish the idea and create watchlog. This works on the similar concept but is just a bit more refined.

This is a demo at 6x speed. For the most part it just passes stdin to stdout. However if there is a break it inserts a ticking timer displaying how long it was since the last output. This gives a quick indication when the last output occurred, without needing to look at your clock and subtract timestamps.

HTTP/1.1 GET /api/books/1 500
HTTP/1.1 GET /api/books/2 500
HTTP/1.1 GET /api/books/1 500
HTTP/1.1 GET /api/books/1 200
Last output 48s ago.

If you watched carefully you may have noticed that watchlog will also group bursts of output by inserting permanent timestamps into the log after longer breaks. This both helps to timestamp the log (if it doesn’t have its own timestamps) and helps you quickly identify what logs happened close together. For example I have often wonder if two errors are from the same event or they occurred at separate times.

HTTP/1.1 GET /api/books/1 500
HTTP/1.1 GET /api/books/1 500
	2021-04-21 07:50:16
HTTP/1.1 GET /api/books/1 200
HTTP/1.1 PUT /api/books/1 200
HTTP/1.1 GET /api/books/1 200

The above looks like I took a break to fix the issue, then when I tried again my requests were all successful!

I hope that watchlog is useful to others as well. If you have questions, comments or patches just open a ticket and I’d be happy to chat.