It is a Saturday, or a public holiday, or the one weekday someone has managed to take off. Before the kettle has boiled, the phone is out. The website is still up. The card machine at the shop processed sales this morning. The overnight backup email arrived. The online orders are coming through. Nothing is wrong. The phone goes back on the counter and the day can begin.
Many people who run or look after a business will recognise some version of that ritual. It is quick, often under five minutes, and it is easy to dismiss as habit. This piece takes it seriously, because the check usually exists for a reason: the person doing it has no other way of knowing whether everything is fine. Until they look, silence could mean that all is well, or it could mean that something failed quietly at three in the morning.
The difference between rest and standby
South Africa's Basic Conditions of Employment Act requires employers to give employees a daily rest period of at least twelve consecutive hours and a weekly rest period of at least 36 consecutive hours which, unless otherwise agreed, must include Sunday. The law sets a floor for time off. It says nothing about the owner, the founder or the person who has quietly become the one who "keeps an eye on things", and it cannot reach the habit of checking.
A rest day with a status check at the start of it is not quite a rest day. It is a day on standby that happens to have no work scheduled. The person is available to the business by default, and only off duty once they have confirmed that they are not needed. That ordering matters. It means the day begins with the business rather than with the person.
It would be wrong to say that everyone experiences this as a burden. Some owners like the quick look and find it reassuring. Others never check and are untroubled. The claim here is narrower and is offered as a reasoned hypothesis rather than a measured finding: when a person is the only means by which a failure would be noticed, a check on a day off is a rational response to how the business is set up, not a personal weakness.
Why silence cannot be trusted
Consider an illustrative case: a Durban online homeware retailer with about fifteen staff, a web shop, a courier integration and a small warehouse. Orders come in all weekend. The systems mostly work. When they have failed in the past, the owner found out on Monday, from customers.
That history teaches a lesson the owner did not set out to learn. If a failure can happen without anyone being told, then the absence of bad news tells you nothing. The only safe assumption is that something might be wrong, and the only way to clear that assumption is to look. The check is the business's monitoring system, and it runs on a human being.
Three conditions tend to produce this:
- Failures are silent. A scheduled job that does not run, an integration that stops passing orders, or a payment gateway that rejects cards will often produce no message at all. The work simply does not happen.
- Alerts go to everyone or no one. Where alerts exist, they may arrive in a shared mailbox that nobody watches at weekends, or in so many people's inboxes that each assumes someone else will act.
- Nobody is on duty. Without a named person responsible for the weekend, responsibility drifts to whoever cares most, which is usually the owner.
Mellorca has looked at the same anxiety in the specific case of backups in the stress of not knowing if the backup worked, and at the evening version in the notification you check before you sleep. The rest-day check is the broader pattern: a whole business whose health can only be confirmed by looking.
What good alerting is meant to do
The discipline of site reliability engineering has thought carefully about when a human should be interrupted. Google's chapter on monitoring distributed systems argues that a page should only go to a person when a condition is urgent, actionable and visible to users, or about to be. It also notes the cost of getting this wrong: when alerts arrive too often, people start to skim or ignore them, and a real problem can be masked by the noise.
The same principle works in reverse for a small business. If alerting is designed well, then no alert is meaningful. Silence becomes evidence that things are fine, because a failure would have produced a message to a specific person. That is the shift that makes the morning check unnecessary.
The tools to do this are not exotic. Cloud monitoring services such as Azure Monitor separate an alert rule, which watches a signal, from an action group, which decides who is notified and how. Alerts can be suppressed on a schedule, for example during planned maintenance. For scheduled jobs, services such as Healthchecks.io work as a dead man's switch: the job sends a small signal each time it runs, and if the signal does not arrive within the expected period plus a grace time, an alert goes out. A missing run stops being silent.
What could change
For the illustrative retailer, the useful changes are mostly organisational, with a little technology in support.
- List what would actually hurt. Orders not arriving, payments failing, the site being down, the courier integration stopping. Usually a handful of things, not dozens.
- Make each one speak when it fails. A check on the web shop, a heartbeat on the order export, a failed-payment threshold. Each produces a message when something is wrong and nothing when it is right.
- Send alerts to one named person. A weekend rota, even if it is two people alternating, means each alert has an owner. Everyone else can stop watching.
- Agree what the alert means. Some alerts mean act now; others can wait for Monday with a note. Writing that down prevents every alert from feeling like an emergency.
- Test it. Deliberately stop a job once and confirm that the alert arrives. A monitoring setup that has never been seen to work does not earn trust.
The aim is not to make anyone permanently reachable. It is the opposite: to narrow the set of people who need to be reachable, and the set of occasions when they do. For the owner who is not on the rota, the day off can begin with the kettle.
For a wider view of how this fits with automated work, see how to know whether an automation actually ran and why every automation needs a failure path.
Trade-offs
- Someone is still on call. Alerting moves the burden to a named person rather than removing it. That person's rest days now have a defined interruption risk, which may need recognition, compensation or rotation.
- Bad alerting is worse than none. A system that sends frequent false alarms can make rest days more anxious, not less. Tuning takes time and attention in the first weeks.
- Trust is slow. An owner who has been caught out before may keep checking for months even when the alerts work. That is understandable, and the habit may simply fade rather than stop.
- Some failures stay silent. No monitoring catches everything. A sensible setup reduces the uncertainty; it does not remove it.
Why it matters
The business case is straightforward: problems found on Saturday morning by an alert are cheaper than problems found on Monday by customers. The human case is less obvious and arguably more important. A rest day is valuable partly because it can begin on the person's own terms. When silence can be trusted, the person is free to be wherever they are, without first confirming that they are not needed somewhere else.
That is the dividend: presence from the first hour of the day, and the predictability of knowing that if something does go wrong, the right person will be told. What is done with the day is, of course, entirely up to them.
Sources and further reading
- Google SRE monitoring ditributed system - sre golden signals (last verified 10 October 2026)
- Overview of Azure Monitor alerts - Azure Monitor (last verified 10 October 2026)
- Healthchecks.io Documentation - Healthchecks.io (last verified 10 October 2026)
- https://www.labour.gov.za/DocumentCenter/Acts/Basic%20Conditions%20of%20Employment/Act%20-%20Basic%20Conditions%20of%20Employment.pdf (last verified 10 October 2026)
Related Mellorca reading
- The Lunch Break Eaten by Approval Requests
- When Every Day Starts by Rebuilding Yesterday's Context
- When Travel Days Become Catch-Up Days