MELLORCATalk to Mellorca
Patterns

Security, Access & Risk

When Infrastructure Problems First Appear as Customer Complaints

If customers tell you the system is down before your own tools do, complaints are acting as your monitoring. Here is what that costs and how to catch faults sooner.

Mellorca Patterns2026-10-11

Observable condition

The first sign that something is wrong is not an alert. It is a customer. A client phones to say the portal is slow, a branch says the card machines keep dropping, a salesperson reports that the quoting tool "has been weird since lunch". The support team logs each call as a separate incident. Only when the fifth one arrives does someone connect them and ask whether something underneath is failing.

By then the problem has been running for hours. The infrastructure team, if there is one, was never told, because nothing on their side turned red. The complaint is the monitoring.

An illustrative example: a Cape Town logistics company runs its booking system on a single hosted server and a fixed-line connection with a mobile backup. After a firmware update, the backup link silently stops taking over when the line drops. For three weeks, short outages go unnoticed by IT and are experienced by dispatchers as the system freezing. Complaints reach the operations manager as scattered remarks, and each is treated as a one-off.

Realisation

The realisation is that customer complaints are being used as the early warning system for infrastructure. They are an expensive one. A complaint tells you that damage has already reached someone who matters, it describes the symptom rather than the fault, and it arrives long after the fault began.

Google's site reliability engineering guidance on monitoring distributed systems makes a related point. It argues that a monitoring system should tell you what is broken and why, and that the symptoms users feel and the causes engineers can fix are different things that both need watching. A business with no monitoring of its own infrastructure has outsourced the symptom side to its customers and has no cause side at all.

Realisation prompt: think of the last time a system problem affected customers. Who found out first, and how many minutes or hours passed before anyone responsible for fixing it knew?

Identification

This is a pattern of reactive infrastructure awareness. The visible symptom is a cluster of unrelated-looking complaints that later turn out to share a cause. The common assumption is that the technology is flaky or that the supplier is poor. The structural cause is that nobody is watching the health of the underlying services, such as connectivity, power, servers, storage and licences, in a way that would raise a hand before the customer does.

The Pattern the hidden commercial cost of fragile infrastructure describes the wider cost of systems that depend on luck. This Pattern concentrates on how the problem becomes visible, and why it is so often through the wrong people at the wrong time.

Diagnosis

  • There is no baseline. Nobody knows what normal looks like for response times, uptime or error rates, so "slow" is an opinion rather than a measurement.
  • Monitoring covers servers but not the experience. A machine can be switched on and answering pings while the application on it is unusable. Observability, as IBM's overview describes it, is about understanding the internal state of a system from its outputs, not just whether it is alive.
  • Complaints are logged by person, not by pattern. Support records who called, but nobody looks at what was reported across the day.
  • Redundancy is assumed rather than tested. Backup connections, generators, UPS units and failover settings are installed once and never exercised, so their failure is only discovered during the next outage.
  • Ownership is blurred. The internet provider, the hosting company, the software vendor and the in-house IT person each own a piece, and none owns the customer's experience of the whole.
  • Load-shedding hides real faults. When power cuts are routine, staff expect equipment to misbehave and stop reporting it, so a genuine fault looks like another bad day.

Commercial impact

The commercial value at stake is service continuity, customer trust, staff productivity and the cost of incident recovery.

The first cost is time to detect. Every hour between the start of a fault and its discovery is an hour of lost orders, stalled staff and unhappy customers. A fault that an alert would have flagged in five minutes can run for half a day if it has to be found through complaints.

The second cost is diagnosis. When the only evidence is a handful of vague descriptions, the technician starts from scratch. Without logs and history, the question "when did this start?" cannot be answered, so the fix is a guess and the same fault returns.

The third cost is trust. Customers forgive a fault that was caught and explained quickly. They are less forgiving when they have to tell you your own system is down. The Pattern when customers know their order is late before your team does describes the same loss of credibility in the delivery context.

The fourth cost is hidden drag. Many faults are partial: a slow printer queue, a flaky Wi-Fi access point, a database that needs restarting each Monday. None triggers an emergency, so each is absorbed into daily work as lost minutes for every employee who meets it. In a business paying salaries in Rand, those minutes are a real line item that never appears on a report.

Common misidentification

The first mistake is treating each complaint as an isolated support ticket and closing it when the user says it works again. Closing the ticket is not the same as understanding the cause. The second is blaming users, who are told to restart, clear their cache or try another browser while the real fault continues. The third is buying more capacity, such as a faster line or a bigger server, before knowing what the bottleneck is.

A fourth, subtler mistake is assuming a managed service provider is watching everything. Some are, some monitor only what the contract lists, and many reports show uptime for a server without showing whether the application customers use was actually reachable.

Possibility

In a better state, the business learns about a degradation before a customer does. A small set of checks runs continuously against the things customers depend on: can the website load, can an order be placed, is the backup link ready, is disk space running out, is the licence about to expire. When one fails, a named person is told, and complaints that do arrive can be matched against a timeline of known events. The Pattern why decision-makers keep asking for status updates shows how the same absence of visible status drives constant interruption.

This does not require an enterprise toolset. The Microsoft Azure Well-Architected guidance on observability frames the practical goal as collecting enough signals to detect, diagnose and respond to problems, which scales down as well as up. For a small firm, a handful of external uptime checks, a simple status log and an agreed escalation routine deliver most of the benefit.

Intervention

  1. List what customers actually depend on. Name the five or six services, such as the website, payments, booking or ordering, phones and email, whose failure customers notice within minutes.
  2. Monitor those from outside. Set up simple checks that behave like a customer and alert a named person by message when they fail.
  3. Record complaints in one log. Capture time, location, symptom and customer for every call, and review the log daily for clusters.
  4. Test redundancy on purpose. Pull the primary line, switch to backup power and restore a backup in a controlled window, and record what actually happens.
  5. Assign one owner for the experience. Someone, internal or at the provider, must be accountable for the end-to-end service rather than a single component.
  6. Write a short incident note after each event. Capture start, detection, cause and fix, so patterns can be seen over months.

Diagnostic questions

  • Who told you the last time a core system was down: your tools or your customers?
  • Can you say how long your main system was unavailable last quarter?
  • When did you last test that your backup connection and backup power actually work?
  • Are customer complaints about performance reviewed together or closed one by one?
  • Who is accountable for the whole service a customer sees, not just a single server or line?

Bottom line

Customers should not be the first line of detection. When infrastructure problems first appear as complaints, the business is paying for faults in lost trade and lost goodwill, and diagnosing them with the least information possible. A small, deliberate habit of watching what customers depend on turns those surprises into routine maintenance.

Sources and further reading

Related Mellorca reading

Article summaryIf customers tell you the system is down before your own tools do, complaints are acting as your monitoring. Here is what that costs and how to catch faults sooner.
Explore our solutionsStart a conversation