Reachable does not always mean usable
The website responds, the server is running and monitoring shows green. Yet a customer cannot submit an order.
This fictional example shows why I would distinguish between availability and usability. An application can serve its homepage while sign-in, its database or an essential processing step is failing.
Monitoring is a valuable part of operation. It does not replace an appropriate check or a prepared response to an outage.
First define what “working” means
An information page may need a different check from a customer portal. For a portal, I would want to know whether a suitable test user can complete the intended workflow.
Google's SRE handbook distinguishes externally visible behaviour from measurements taken inside an application. The perspectives complement one another. It also recommends attention to response times, traffic, errors and saturation. [1]
I would not turn that into a requirement for a vast monitoring platform for every small service. I would start with its essential workflow, then add the internal information that would help explain a failure.
The check itself needs boundaries too. An automated test must not create real orders, incur charges or send customer notifications. Suitable test accounts and clearly separated test functions need deliberate preparation.
Monitoring should reveal its own gaps
“Last measurement successful” is of little value when that measurement is outdated. A failed collector should not leave the previous green result looking current.
I would display both the outcome and its time, alongside the expected update frequency. When a measurement is missing, the state should be visibly stale or unknown—not confirmed healthy.
Measurement location also affects interpretation. A failed check from an office computer might reflect the office connection, not establish a server failure. Conversely, a local server check may miss problems along the external access route.
For particularly important services, I would consider suitable independent measurement locations. The choice should follow risk and effort, not the number of attractive graphs available.
Logs should answer questions
To me, a useful error report identifies the time, workflow, deployed release and a meaningful error code. Across several processing steps, a shared request identifier helps locate related events.
OpenTelemetry describes metrics, logs and traces as different signals. A trace can represent a request's journey; a log records an event. [2]
Not every small application needs every capability. What matters is whether the practical question can be answered: Which step failed, and which observation supports that conclusion?
Passwords, access tokens and complete confidential content should not be written into logs merely in case they prove useful. I would collect the information needed for diagnosis and deliberately limit access and retention. More stored data does not automatically mean better understanding.
Do not change five things at once
When software fails, the desire for a quick restart is understandable. However, simultaneously changing the computer, router, database and application makes it difficult to identify which action helped.
Where circumstances allow, I would first record the observed state: when complaints began, the last successful check, the current error message and preceding changes. An urgent need to limit disruption should not be delayed unnecessarily by this recording.
The next action needs a reason. Safe restoration can take priority over immediately establishing the complete cause. The report should distinguish the two: “Reachable after a restart” is an observation, not proof of the cause.
Clear responsibilities rather than cascades of alerts
Google's incident guidance describes prepared roles, coordination, communication and an ongoing record of actions. [3]
A small business does not need three new positions for this. It still needs to know who coordinates the response, who makes technical changes and who informs affected people. Independent activity by everyone can make the situation harder to understand.
An alert should therefore identify the affected service, the observation and the intended first investigation step. Non-urgent issues may be better handled through a consolidated notification than constant interruption.
Reachable again is not necessarily fully recovered
After remediation, I would repeat the important workflow that failed. I would also establish whether processing was left unfinished or performed twice.
A restart can make a service reachable without clearing a queue or completing an interrupted export. Practical acceptance must match the task.
For the follow-up, start with a clear timeline, supported observations, actions taken and remaining questions. A possible cause remains a hypothesis until evidence supports it. Targeted improvements can then follow.
My conclusion: Monitoring needs a route to action
Good monitoring does more than display colours. It shows what was checked, how current the result is and where further information can be found.
Reliable operation also involves people and procedures: someone receives the alert, narrows the problem, records changes and verifies recovery. A dashboard can detect some problems earlier. It does not remove our responsibility to respond sensibly.
Sources and context
Research checked on 11 October 2026. General technical guidance, not a report about a specific TNSystem outage or a guarantee of complete monitoring. The opening example is fictional. Practical operating recommendations are editorial judgement, not mandatory requirements for every system.
[1] Google SRE: Monitoring Distributed Systems
Read source ↗
[2] OpenTelemetry: Signals
Read source ↗
[3] Google SRE Workbook: Incident Response
Read source ↗