A trader in metal and building materials supplies steel door frames, doors and metalwork to construction companies and tradespeople. Its promise to customers: express, faster than the market.
A promise like that hangs on many small things. An order has to arrive, a job has to be visible in the back office, a shipping label has to be printed. If one of them stalls, the customer on the building site notices first.
Where it breaks without anyone noticing
Outages of web applications go unnoticed as long as nobody uses them. For an express business that is the worst moment: the phone rings exactly when someone urgently needs something.
What is worth monitoring
- Website and order application: one HTTP monitor each on an address that only answers when the application really works, not just the home page.
- The interface that triggers shipping labels: an HTTP monitor on its status endpoint.
- The mail server for order confirmations: a port monitor on the SMTP port.
Alerts go by email to the people who can act, not to a shared inbox. Anyone with their own ticket system connects it by webhook.
The real gain
More important than the technology is a side effect: nobody has to check whether everything is running any more. If it stays quiet, it runs. And if Uptime speaks up, you know before the customer does.
Takeaways
- Do not monitor only the home page, but the paths your promise depends on.
- Pick the right monitor type for each path; for web applications that is usually HTTP.
- Decide who receives the alert before the emergency happens.
