Nobody asks me about system uptime and reliability until after the outage. The pattern is always the same: a POS system goes down during a Saturday rush, or an order-management backend crashes mid-month-close, and suddenly the owner wants to know why nobody set up monitoring. The honest answer is that reliability is cheap to arrange in advance and expensive to regret afterward, but almost no one prices it until the bill arrives as lost revenue.
I've been the person called at 11pm when a client's system is down and every minute is a lost transaction. The fix in the moment is never fun. The fix that actually matters happens weeks earlier, when someone sits down and asks: what does an hour of downtime cost us, and what have we actually done about it?
Price downtime before you build reliability
Reliability work is not free, so don't buy more of it than your revenue justifies. The first step is arithmetic, not infrastructure.
Take your average revenue per hour during operating hours. A retail chain doing Rp 2 billion a month across normal trading hours is looking at roughly Rp 3-4 million per hour in a typical store during peak time. A finance company processing loan applications might lose less in direct revenue per hour but far more in compliance and reputational cost if disbursement systems freeze during month-end.
Once you know that number, your reliability budget writes itself. If an hour of downtime costs Rp 500,000, you don't need a multi-region failover architecture. If it costs Rp 20 million, you do. Most SMEs over-invest in features and under-invest in the boring stuff that prevents the expensive hour.
The minimum reliability kit
For the vast majority of businesses I work with, a small, unglamorous kit closes 90% of the risk:
- Uptime monitoring that alerts a human, not a dashboard nobody watches. A tool pinging your system every minute and texting or calling someone when it fails, not just logging to a page that gets checked once a week.
- Backups that are actually tested to restore. Not "we take backups." Tested: someone actually ran a restore in the last quarter and confirmed the data came back intact and complete.
- A written manual fallback. What does staff do when the system is down for two hours? Paper receipt books, a manual order log, a phone number to call. This document should exist before the outage, not get improvised during it.
- A clear escalation path with a named person. Not "call IT." A specific human, a specific phone number, and a defined response time.
The backup that doesn't restore
This is the single most common failure I see, and it deserves its own section because it's so avoidable. A business has "backups" running nightly. Nobody has ever tried to restore from one. Then the primary database corrupts, someone finally restores the backup, and it turns out the backup job had been silently failing for three months, or the backup only captured half the tables, or the restore process itself was never documented and takes eight hours to figure out under pressure.
Test your restore process quarterly. Actually spin up the backup in a test environment and confirm the data is complete and current. This takes an afternoon and it is the cheapest insurance policy available to you.
Monitoring is a management change, not just a tool
Buying a monitoring tool is the easy part. The harder part is deciding who gets the alert and what they're expected to do about it. I've seen companies pay for excellent monitoring software where alerts go to a shared inbox nobody checks after 6pm. The tool worked. The process around it didn't.
Set an explicit rule: alerts go to a named on-call person, with a backup person if the first doesn't respond in 15 minutes. Review the alert history monthly, not just when something breaks, so you catch systems that are flapping (going down and recovering repeatedly) before they fail completely. This connects to the same discipline covered in Own Your Customer Data or Someone Else Will: reliability and data ownership are both about not discovering the gap during a crisis.
Where reliability spending actually goes
| Investment | Typical cost | Who needs it |
|---|---|---|
| Uptime monitoring + alerting | Rp 500,000-2M/month | Any revenue-critical system |
| Tested backup + restore process | One-time setup, Rp 5-15M | Anyone storing transactional data |
| Written manual fallback procedure | A few hours of staff time | Retail, F&B, any customer-facing ops |
| Redundant infrastructure / failover | Rp 20M+/month | Only if downtime costs exceed that per hour |
Most businesses stop at row three and are correctly sized. Row four is for genuinely high-volume, high-revenue-per-hour operations, and paying for it below that threshold is money better spent elsewhere.
The takeaway
System uptime and reliability is not a technology purchase, it's an insurance decision, and like any insurance you size it to the actual cost of the bad outcome. Price your downtime hour first. Then buy monitoring that reaches a human, backups you've actually tested, and a written fallback your staff can execute without panicking. That kit handles the outage that would otherwise cost you a full day of sales and a very bad night.