16/09/2026
Production screamed at half past nine. It was my own PC.
An alert said something was wrong in production. The file path in the error started with C:\Users. The real cost was not the minutes it took to work out — it was that I taught myself to ignore the alert next time.

Tuesday 15 September, 09:31. The tool that watches for errors on agertechai.no sent an alert: new error in production. Level: error. The page in question was the booking page — the one people use when they want to arrange a meeting with me.
That is an alert you are supposed to take seriously. So I opened it.
At the bottom of the error sat a file path: C:\Users\…
My site runs on Vercel, in Frankfurt. There is no C: drive there. And the machine name in the alert was not a server name at all — it was the name I gave the PC sitting two metres away from me.
The explanation was dull, the way explanations usually are. I had run a production build locally to test something else. The monitoring asked whether the code was built as production, got a yes, and reported as though it was production — the version customers actually use. It had no way of telling the difference.
The fix was a single condition: only report when the code is actually running on Vercel, not when it is merely built as if it were. That took a couple of minutes.
But the fix is not the interesting part.
The interesting part is the minutes before it. An alert that says "production" moves you. You put down what you were doing and start thinking about customers stuck halfway through a form.
And that is where the real cost sits. Not in the minutes, but in what I taught myself: next time this alert arrives, I already have an explanation ready. It's probably just me again.
That is how you stop listening. Not by switching the alarm off, but by letting it be wrong a couple of times first. The boy who cried wolf never needed the boy, incidentally — an alarm that is set up wrong does the job perfectly well on its own.
You have more of them than you think. The backup report that arrives every morning and nobody reads, because it always says the same thing. The new-sign-in alert from Microsoft 365, which also fires when you log in from the cabin yourself. The exception lists in your accounting system. The temperature warning on the cold room that goes off every time someone stands too long with the door open.
Each one is a small loan against your attention, and most companies are paying interest without knowing it.
Three questions are enough to sort it out:
Who responds? An alert without a named person is not an alert. It is a log file with ambitions.
Can it tell a drill from the real thing? Test from live, your own login from someone else's, a sample from a break-in. If it cannot, it will lie to you — it is only a question of when.
What happened the last time it went off? If you cannot remember, it is because nobody did anything. Then you already know what happens next time.
The last question is the important one, and it is also the uncomfortable one. An alarm is not worth anything because it exists. It is worth something on the day it goes off and you know what it means.
And you only know that once you have seen it be wrong at least once — and cleaned up afterwards.
Mine went off on a Tuesday morning and pointed straight at me. It was embarrassing, and it was the most useful error message I have had in a long time.

Roger Agerup
Founder and AI advisor