That gap is expensive, because quiet failures last longer than loud ones. You learn about a server that is down within fifteen minutes, because half the company calls you. That the payment gateway rejects one transaction in three you learn a week later, at month end, when somebody asks why conversion dropped. Below is a breakdown of what needs watching, what it costs to do yourself, and where that setup runs out.
The page responds and the store still does not sell
The list of quiet failures that slip past ordinary monitoring without a single alert is shorter than you would expect, and it repeats from store to store.
The certificate has expired on some devices only, because an intermediate certificate is missing. A desktop browser swallows it without blinking, an older Android warns about an insecure connection. Monitoring checks from one location and sees no problem.
The payment integration rejects one transaction in three after a change on the provider side. The payment page opens, so formally everything works. The customer sees an error, leaves, and does not come back.
On-site search returns zero results, because the index stopped rebuilding. The catalogue is full, but the half of your traffic that starts by typing a product name lands on an empty page.
Stock levels have been frozen since yesterday, because the wholesaler sync stopped finishing cleanly. You are selling goods you do not have, and not selling the ones that just arrived.
The order form does not send the email, because the mailbox hit its sending limit. Orders come in, customers get no confirmation, and support finds out from complaints.
None of those situations changes the homepage response code. Every one of them costs real money, which you can add up with the rest of the losses in our post on the cost of store downtime.
Seven layers of monitoring, from cheapest to most complete
Treat monitoring as layers rather than as a single yes or no decision. Each layer costs more configuration work and catches a different class of problem.
- Homepage and response code. The cheapest layer, and usually the only one anybody has. It catches a dead server, an expired domain and a 500 on startup, and nothing that happens deeper.
- Product page and category page. You add two or three addresses further inside the store, ideally ones that use both the database and the cache. Template errors, an empty category and a product that stopped rendering show up here.
- The purchase path as a scenario. A robot walks the same route as a customer: adds a product to the cart, goes to checkout, tries to initiate payment. This is the layer at which you start measuring sales at all, rather than the server. It costs the most to configure and breaks fastest after store changes, but it catches failures nothing else sees.
- Response time and its trend. Not the bare fact of a response, but how long it takes and how that has moved over the last few days. A store that used to answer in 400 ms and has answered in 3 seconds since Tuesday is not down yet, but it is already losing customers and is close to the point where campaign traffic puts it down.
- Expiry dates. The SSL certificate, the domain, module licences, API keys for integrations, the card attached to hosting and to the cloud account. This is the only class of failure you can predict a month ahead, and it still happens most often, because nobody keeps the calendar.
- Background processes. Job queues, cron jobs, ERP and wholesaler synchronisation, transactional email. The rule is simple: if a process has not reported in within the expected window, that is an alert. Without it you find out about a stalled queue when a customer asks for an invoice.
- Integrity and security. Unexpected file changes, new administrator accounts, unusual log entries, login attempts from a series of addresses. This is the least frequently implemented layer and the one that hurts most when it was missing.
The first two layers you can set up yourself in fifteen minutes. From the third one up the work starts, and somebody has to keep it alive, because the purchase scenario needs fixing after every change in checkout.
What it costs if you do it yourself
The honest answer: almost nothing. A free account with an uptime monitoring service checks a handful of addresses every minute and notifies your phone and your inbox. Configuring the homepage, two subpages and a certificate reminder takes fifteen minutes. If you have nothing today, do it today, before you read the rest of this text.
It is just as honest to say what that setup does not give you. Nobody will pick up an alert at two in the morning, because the phone is on silent next to the bed. Nobody will tell a real outage apart from a momentary connection drop at the checking service. Nobody will start a diagnosis, so in the morning you learn the store was down for six hours, and only then does the search for the cause begin. Free monitoring tells you that something happened. It does not tell you what, and it does nothing about it.
False alarms and why people switch monitoring off
The most common reason monitoring does not work in a store is not technical. Somebody turned it on once, got fourteen notifications in the first week, thirteen of them nothing, and muted the channel within a month. A notification nobody trusts is worse than no notification, because it creates the illusion of control.
False alarms are reduced by three things. First, confirmation from a second location: if the store does not respond from London but does respond from Frankfurt, you suspect the network route first, not the store. Second, a threshold of several consecutive failed checks instead of reacting to the first one. Third, verification by a human before the notification goes any further. Those three filters together cut the noise enough that an alert starts to mean something again.
What supervised monitoring with an on-call adds
This is where the part you cannot buy for nothing begins, because its cost is somebody's time. In our contracts, availability supervision means specifically: checking the store every 60 seconds, human verification of the alert within 15 minutes, classification of the event and a notification to you with a ticket number, diagnostics within 60 minutes for a critical event, and a post-incident note with the cause and how to prevent a repeat.
Supervision pricing: Standard 240 USD net per month, Extended 650 USD, Continuous 24/7 from 2,600 USD. The difference between them is above all the on-call window and the scope of response, not the check frequency itself.
What we do not promise, and what nobody should promise: a time to resolve a failure. We guarantee response time, because that is the only thing we control fully. The fix depends on whether the problem sits in the code, in an external integration, or on the hosting side, which we do not run. We also do not quote availability in percentages, because that number costs nothing in a proposal and changes nothing. We cover that distinction in our post on the SLA agreement.
The question worth asking your current provider
One sentence that says more about a contract than its entire technical annex: will I find out about an outage at the same moment you do.
In the entry level packages the answer is no, and that is not a flaw. The alert reaches the on-call engineer first, a human verifies it, rejects the false one, and only a confirmed event goes to the client with a ticket number. That way you do not get three notifications about nothing in the middle of the night. In the higher packages the notification goes to you in parallel with the on-call engineer, because for some stores the decision to pause a campaign or hold a shipment belongs to you and cannot wait fifteen minutes. That is a real difference in the service and it belongs in the contract, not in a conversation improvised during the first outage.
An exercise to finish
Switch one thing off in a test store: stop the queue, disconnect the payment gateway key, or break the search index. With no test environment, look into the logs or your inbox and find the last production failure.
Then answer one question: how did you find out about it. If it was from an alert, check how many minutes passed between the event and the notification. If the answer is "from a customer", you already have the answer to whether you need supervision, and you do not have to count anything else.
We provide store availability supervision from 240 USD net per month, package details are on the /en/sla-help-desk page. If you would rather first see what looks wrong in your store today, enter its address in Tester eCommerce and get a free diagnosis. It requires no admin access and no sales call.