Case Study 01 Writing Craft Operator-Facing

System Log Messages

Rewriting for clarity and action

Network operators monitor hundreds of system log messages in real time, often while managing an active incident. A message that buries its severity, omits context, or offers no next step forces the operator to stop and investigate before they can act. That delay has consequences.

These five rewrites apply a single governing principle: the message should do the triage work, not the operator. Each rewrite targets a specific failure mode in the original.

Concept work — applied to Juniper Networks syslog message library.

The Constraint

Every syslog message is prepended automatically with timestamp, hostname, process name, and severity level. By the time an operator sees the human-readable text, a line already looks like this:

Apr 17 14:32:11  spine-01  chassisd[1234]: error —

That's 40+ characters gone before the message begins. On a standard terminal, roughly 100 characters remain for the description. In practice, operators are tailing live logs across multiple sessions simultaneously — a message that wraps to a second line is a message that gets missed.

Every word in these rewrites was evaluated against that constraint.

The Through-Line

Good syslog messages share three properties: they lead with what happened, they name what's affected, and they point toward what to do next. The originals fail in different ways — buried severity, broken grammar, missing context, wrong consequence, wrong register — but all five failures have the same root cause: the message was written for the system that generates it, not the engineer who reads it.