What an hour of downtime actually costs a Kenyan business
Ask a business owner what an hour of downtime costs and you usually get a shrug. Ask them what they spent on the last marketing campaign and they know the figure to the shilling. That asymmetry is why monitoring tends to arrive only after the first expensive outage.
Start with the obvious part
The direct cost is easy to estimate:
hourly revenue at risk = (daily online revenue ÷ trading hours) × share of traffic that is web or app-based
A business taking KES 200,000 a day in online orders, trading twelve hours online, is exposed to roughly KES 16,700 for every hour the site is unreachable during peak. That is the number before anything else goes wrong.
The part people forget: checkout is not "the website"
Most Kenyan e-commerce runs on hosted checkout — M-Pesa prompts, card redirects, callback URLs. These fail in ways a homepage uptime check never sees:
- The callback endpoint stops accepting POSTs. Customers pay, the order never confirms, and you get refund requests instead of orders.
- A third-party payment API changes behaviour and your handler returns 500. Your site is "up", your checkout is not.
- A single route breaks on a deploy — usually the one your highest-value customers use.
An uptime check that only requests the homepage marks all three as healthy. This is why content assertion and per-endpoint checks matter: a 200 response whose body says "service unavailable" is not a working service.
The costs that show up on Monday
- Support load. Every failed customer contacts you twice: once to complain, once to ask for a refund. One hour of downtime is a day of support.
- Paid acquisition wasted. Ad spend continues while the landing page 502s.
- Platform penalties. Deliverability and marketplace rankings often consider site availability, and some payment providers do too.
- Trust. A customer who sees an error page during checkout frequently does not retry. They do not tell you either; they simply pay someone else.
- Search visibility. Sustained outages and error responses can affect indexing for your most valuable pages.
The real cost is the unknown
The expensive part is not the hour. It is that nobody knows it happened until a customer complains, and nobody knows how long it lasted.
That is what monitoring fixes first: it converts "the site felt slow last Thursday" into "the checkout endpoint was down 14 minutes, 03:12–03:26, and it has happened three times this month". The second sentence is something you can take to your host.
What to monitor for a Kenyan business
| Endpoint | Why |
|---|---|
| Homepage | The headline check, and cheap |
| Checkout / payment callback | Where revenue actually breaks |
| Customer portal or app API | Where logged-in customers break |
| TLS certificate | The outage with no warning |
| A content assertion on the health page | Catches "200 but broken" |
Start with five checks at one-minute intervals and a certificate check twice a day. That is enough to catch the incidents that cost real money, and it costs less than a single hour of the outage it prevents.