Ask a founder what their engineering team needs and you'll usually get an answer about outages.

Faster detection. Better alerting. Something that helps when things go wrong at two in the morning.

That's fair. Outages are visible, they're expensive, and they're the thing you remember. But if you count the days, most teams have a serious incident a handful of times a year.

So what's happening on the other three hundred and sixty-odd?

The ordinary questions

Here's a sample of what your engineers are actually asking, on a normal Tuesday, with nothing on fire.

Which service handles payments?

What happens if I change this load balancer?

Which of our systems depend on this database?

Why can't this service reach that one?

Who deployed on Thursday, and what was in it?

None of those are incidents. Nobody is paged. There's no dashboard turning red. They're just questions somebody needs answered before they can carry on with what they were doing.

And every one of them requires going and looking. Opening a cloud console, then a repository, then a monitoring tool, then asking in a channel because the first three didn't quite answer it.

Where the time actually goes

This is the part that doesn't show up anywhere in your reporting.

Research on how developers spend their time consistently puts more than half of it on understanding existing systems rather than writing anything new. A study of debugging sessions specifically found that 74% of the time went on activity other than looking at code, meaning navigating tools, opening things, finding where stuff lives.

Not thinking. Fetching.

And there's a well-established cost attached to every interruption. The often-cited figure from research at UC Irvine is around 23 minutes to fully return to a task after being pulled away.

Now consider that a lot of those Tuesday questions get answered by interrupting the one person who knows. That's two people's time, and the second one loses more than they spent answering.

None of this appears on a status page. Everything is green. It's just slower than it looks.

Why the outage framing misleads you

Buying tools for incidents is buying for the exception.

It's understandable, because incidents are the only time this cost becomes visible. When a service is down, everybody can see people scrambling between systems trying to piece together what happened. That scrambling is dramatic and it gets attention.

The same scrambling happens on ordinary days. It's just spread thin enough that nobody notices, and it's called normal engineering work.

If you only think about this during incidents, you'll evaluate everything on how it performs during your worst hour and miss that the same underlying gap is quietly taxing every hour.

What the gap actually is

The thing missing isn't monitoring. You almost certainly have monitoring.

What's missing is anything that holds the relationships between your systems in one place. Which service runs where. What it depends on. What deploys it. Who owns it. Where its errors go. How critical it is.

Every one of those facts exists somewhere in your company. They're just in six different systems, and the work of joining them up gets done in someone's head, repeatedly, by whoever's available.

That's what makes it invisible. There's no tool failing. There's no line item. It's a small tax on every question your team asks, paid in people's attention.

Where our product sits

Frigga builds Vörr, so treat this as an interested view.

It connects to what a team already runs, the code, the cloud accounts, the pipelines, the monitoring, and keeps track of how those things relate to each other. Then it answers questions about them in plain language.

The reason I think the everyday framing matters more than the incident one is what it means for who benefits.

If you buy something for outages, it helps a handful of people a handful of times a year. If what you have is a way for anyone to ask questions about your systems and get real answers, it helps everyone, constantly, including the new engineer who doesn't want to interrupt anybody and the senior one who is tired of being interrupted.

Incidents are then just the hardest version of the same question, asked faster.

What I'd actually look at

If you want to know whether this is costing you anything, don't look at your incident metrics. Look at ordinary weeks.

Ask an engineer how long it took to answer the last question they had about a system they didn't build. Not a hard technical problem. Just finding something out.

Ask who gets interrupted most. There's always a name, everyone knows it, and it's usually one of the people whose time is worth the most.

Ask how long a new joiner takes to become genuinely independent. Not their first commit, which mostly proves their laptop works. The point at which they stop needing to ask where things are.

All three are questions about ordinary days, and all three are measuring the same thing.

The worst day matters. It's just not where most of the cost is.

Author note

Ayesha Siddiqua, Business Growth Strategist at Frigga Cloud Labs.

What changed my thinking here was realising how much of engineering work is looking things up rather than solving things. I'd assumed the hard part was the hard part. Mostly the hard part is finding out where everything is so you can start.

That's oddly reassuring, because it's a much more fixable problem than the one I thought it was.

If you run an engineering team and see this differently, I'd like to hear it. LinkedIn.

Your Team Isn't Slow. They're Looking for Things.