Observability in business language

I am starting this journal with the first tool I built with AI, because almost everything else came from it. I made it because I was tired, without a plan.

Almost every software company pays for an observability platform. Its services write millions of log lines a day, everything is stored and there is a dashboard full of charts. Even so, when something goes down, the first to find out is often a customer, or support once the complaints start coming in. It has happened to me many times, and the information was always there and nobody saw it in time.

There is plenty of data. The problem is that it is written in a language few people on the team understand, and there is so much of it that nobody can read it all.

Logs few people understand

For whoever built the service, a log like «Queue full (max 50), rejecting publish to orders.confirm» says everything. For someone in support, in product or running the area it says nothing, and they are the ones who need to know quickly whether a customer is affected. So operations end up in the hands of a few people, and when they are away, nobody really knows what is going on.

On top of that, the most expensive failures usually leave no trace. A process that stops does not log errors, it just stops writing. An integration that fails and answers «all good» does not trigger any alarm either. Tools that look for errors find nothing, and the problem is discovered once it has already done damage.

If you try to solve it with alerts, the opposite happens. Everything triggers an alert, the team gets overwhelmed and two weeks later nobody looks at the channel. The system looks covered, but it is not.

What monitor-log does

monitor-log reads the logs the company already has, without copying or storing them, and translates them into what they mean for the business: what happened, who it affects and what needs to be done.

2026-08-20T14:02:11Z ERROR orders-api
[a3f9c2] Queue full (max 50), rejecting
publish to orders.confirm

The translation is written by whoever knows the business, in a dictionary edited on screen and tested against real lines before it is saved. That way anyone on the team can open the dashboard and understand the state of the services without asking for help.

Using it, I realised the most useful parts were three other features:

• It prioritises. Of the thousands of critical lines each day, it says which ones need attention today and why.
• It warns when a flow stops. Each flow learns its normal pace and warns if it stops, even when no error was logged.
• It follows a case. With an order or invoice number, it shows its whole path through the services, which is what support needs when a customer asks what happened to theirs.

What changes for a team

Problems show up on the dashboard as soon as they happen and get fixed before they arrive as complaints. And a diagnosis that used to need someone who could read logs can be done by anyone on the team.

Operations also stop depending on a few people. When what each failure means is written in a shared dictionary, it is no longer known only by whoever has been at the company longest, and that person can go on holiday without worrying.

The dashboard also says what it does not know: which lines it could not explain and which services gave no signal. That is more useful than a dashboard where everything is green. And since it works on top of the platform the company already pays for, there is no need to replace it or duplicate its data.

Its limits

monitor-log does not replace the people who run the services or the observability platform. The translation rules are written and validated by the team, and if a rule has not been tested, the dashboard says so.

It helps more people see what is already in the logs, so that nobody hears from a customer about something the logs already said. If you want to try it with your team, it is at monitor-log.com.

Building it taught me something I used in everything that came after: what is not written down depends on one person, and that person gets tired. The same was happening with AI, because everyone used it their own way and what they learned was lost when the conversation closed. The next entries tell what I did to change that, and how lonely that role can be.