Make application state understandable
Users should be able to tell whether work is saved, pending, published or rejected. Ambiguous state produces duplicate actions and difficult support conversations.
Use specific language and retain stable identifiers that a user can safely share with support. Avoid exposing raw stack traces or internal database details.
Log decisions, not noise
A useful event explains the operation, outcome and correlation identifier. High-volume debug output without context makes an incident harder to investigate.
Choose structured fields deliberately, redact secrets and set retention according to operational need. Logs need access controls because they often contain sensitive context.
Separate recovery from diagnosis
A user may need a simple retry or correction, while an engineer needs the underlying failure category. Design both experiences without making the public message frightening or vague.
Runbooks should connect known symptoms to checks, owners and safe recovery actions. When the same incident repeats, improve the product or automation rather than extending the runbook forever.
Related projects
See how these ideas shape the FuelOps Rota Planning case study.