Start with the public promise
Before creating monitors, write down what the system must reliably do. A restaurant ordering site must accept orders. A SaaS app must let users log in and load the dashboard. A developer API must return predictable responses and documentation. A static company site must load its high-value pages and contact paths.
That promise becomes your monitoring surface. If the promise is not checked, the dashboard may stay green while customers are already blocked.
Core checks every web property should have
- Homepage HTTPS check, including SSL validation and final status code.
- Primary conversion page such as pricing, contact, order, checkout, or registration.
- Login or account entry page if users depend on authenticated access.
- Public documentation or help center if customers need it during incidents.
- Robots and sitemap availability for sites that rely on search traffic.
- Public status page, ideally watched from outside the same infrastructure.
API checks need more than a 200 response
An API route can return 200 while returning the wrong payload. It can also return cached success while a downstream dependency is broken. Monitor at least one lightweight endpoint that proves the API process, database, and required external dependency state when appropriate.
GET /health
Expected status: 200
Expected body: {"status":"ok","database":"ok","queue":"ok"}
Do not put secrets in a public health endpoint. If deeper dependency checks are sensitive, expose a safe summary or use authenticated monitoring from a trusted environment.
Ecommerce and order systems
For ecommerce, the homepage is rarely enough. A store can look healthy while add-to-cart, payment handoff, shipping calculation, or confirmation emails are broken. At minimum, monitor category pages, product pages, cart entry, checkout entry, and the payment provider status URL if the provider exposes one.
If the business receives orders from third-party marketplaces, monitor webhook receiver availability and queue processing. Failed webhooks often create quiet data loss, which is more dangerous than a visible outage.
SaaS applications
For a SaaS product, create separate monitors for marketing pages and application routes. The marketing site can be up while the app is down, and the app can be up while billing, signup, or an API endpoint is broken.
| Area | Monitor | Signal |
|---|---|---|
| Acquisition | Homepage, pricing, signup | Search and paid visitors can convert. |
| Retention | Login, dashboard, account settings | Existing customers can use the product. |
| Integration | API health, webhook receiver, docs | External systems can still rely on the service. |
| Trust | Status page, support page, SSL expiry | Customers can understand what is happening during incidents. |
Infrastructure checks that support recovery
TCP checks for SSH, database listeners, cache ports, queue services, and internal APIs help separate network failure from application failure. They are not always public checks, and they should not expose private systems unnecessarily. Use them where the monitoring location is allowed to reach the service.
Keep the set small enough to maintain
A noisy monitor set becomes ignored. Name each monitor clearly, assign an owner, and retire checks that no longer map to a real service. The first version can be simple: homepage, login, API health, SSL, and status page. Add more only when the new signal would change incident response.