System monitoring: catch the error before your customer does

Every company with a live system has been through this. WhatsApp buzzes, it's a customer, and the message says the site won't load, the payment won't go through or the app freezes at login. You call whoever runs the system, and the person on the other end is just finding out too.

The problem isn't the error. Every system will have errors at some point. The problem is hearing about it from the customer, after they've already lost time, abandoned the purchase or complained in public. In this guide I show what real monitoring needs to measure, what it costs not to have it, and what to ask the vendor who runs your product.

Customers still find the failure first

It sounds like a problem for small, disorganized companies. It isn't. In the 2025 New Relic survey of 1,700 IT and engineering professionals in 23 countries, 41% of leaders said they still learn about outages through inefficient means: customer complaints, support tickets or manual checks.

The same survey shows what this does to the team. Engineers spend 33% of their time firefighting or dealing with outages. A third of what you pay for development goes to chasing problems instead of building what the business needs.

And delay costs money. Even teams with full monitoring take an average of 28 minutes to detect an outage, according to New Relic. The rest take 7 minutes longer. In a system that sells, books or serves, every one of those minutes has a customer on the other side.

What an outage costs

The numbers in global surveys come from large companies, but the proportions hold at any size. The annual outage report from the Uptime Institute, released in May 2026, shows that 57% of companies said their last major outage cost more than US$100k. For the second year in a row, one in five topped US$1 million.

The same report has a finding that matters if your system runs in the cloud. Across nine years of publicly recorded outages, about two thirds came from third-party providers: cloud, internet, telecom and leased data centers. New Relic points the same way. The three most common causes of major outages are network failures, cloud provider or third-party service failures, and new code deployments.

In your terms: much of what will break your system isn't in the code you paid for. It's in the payment gateway, the email service, the login service, the hosting. The rest comes from the update your own team shipped on Friday afternoon. Monitoring means covering both.

What to measure: the four basic signals

In its reliability engineering book, Site Reliability Engineering, Google lists four signals every user-facing system should measure. In business terms:

1. Response time. How long the system takes to respond. A page that loads in 8 seconds is up, but the customer is already gone.
2. Traffic. How many people or requests the system is receiving. A sudden drop in visits at 10 a.m. on a Tuesday signals a problem, even with no visible error.
3. Errors. The share of requests that fail. That includes the error shown on screen and the one that isn't, like a sign-up that looks saved but wasn't.
4. Saturation. How close the system is to its limit: disk, memory, database, a third-party service quota. It's the signal that warns you before things break.

The same book sums up the point of all this in one line: monitoring exists so the system can “tell us what's broken, or perhaps what's about to break.” And it sets a rule that's gold for whoever pays the bill: every alert must require action. An alert nobody needs to handle becomes noise, and noise makes the team ignore the alert that matters.

What the four signals miss

There's a kind of failure none of these charts show: the system is up, fast, error free, and the data is wrong. The report double counts. Inventory goes negative. The discount applies twice. The calendar books two customers in the same slot.

This is the most expensive error, because it takes time to surface. By the time someone notices, the business has spent weeks making decisions on wrong numbers. To catch this kind of failure, monitoring has to look at the data too: totals that don't add up, records outside the pattern, jobs that should have run and didn't.

That's why I split monitoring into three layers:

• Is it up? Outside-in checks every few minutes on the pages and routes that matter most: home, login, payment, contact form.
• Is it working? Response time, error rate and saturation, from inside the system, with every failure logged.
• Is it right? Checks on the data and the processes that keep the business moving.

Many live systems only have the first layer. It tells you when everything goes down, but not when the system works wrong.

What to ask the vendor who runs your system

Monitoring isn't a tool you buy and switch on. It's a routine with an owner. Before you sign or renew a maintenance contract, check that it answers these questions in writing:

• What gets checked, and how often. Which pages, which routes, which processes. “The whole system” isn't an answer.
• Who gets the alert. A named person, not an inbox nobody reads.
• How fast someone starts fixing it. Broken down by severity: a stalled payment flow can't wait until Monday.
• How you find out. The technical alert goes to whoever fixes it. You get what happened, how long it lasted, who was affected and what was done.
• What goes in the monthly report. Uptime, most frequent errors, response time and what was improved.
• Whose name the accounts are in. The monitoring tools and the alert history are part of your system too.

If you're putting that budget together now, I wrote about what it costs to keep a system or app live, including the lines monitoring needs to take up. And if the product was built with AI tools, the risk of silent errors is usually higher. I explained why in the maintenance cost of vibe coding.

How we do it at the Studio

At the Studio, every system we deliver ships with an AI agent that runs every day. It flags failures, suggests improvements and checks that the data makes sense. That's the third layer, the “is it right?”, which almost nobody covers and which is usually the most expensive when it fails.

Everything else follows the same principle we use on the project. Fixed price after discovery, and the deadline written into the contract. The code, files and access stay in the client's name, including the tool accounts. Our in-house dev team does the work, and we use Claude Code and Figma for design and build.

Fewer parts also means fewer places for a failure to hide. At LCX, a travel company operating in more than 10 South American countries, one system per country became a single system, live in 29 days. One system to monitor instead of one per country.

If today it's your customer who tells you your system is down, that's the first job of our system maintenance and evolution service: putting someone, and something, on watch before they notice.