What monitoring tracks
"The site loads" is only the most basic check. Full monitoring watches several layers at once:
- Availability. Whether the website, API, and payment page respond; whether the SSL certificate or domain registration is about to expire.
- Speed. How long key pages take to load and whether that's getting worse over time.
- Code errors. Failures users actually see: a button didn't work, a payment returned an error, an account page didn't load.
- Server resources. CPU, memory, disk, database connections, and background job queue length.
- Business metrics. For example, if no orders come in for an hour during business hours, that's a reason to check whether everything's OK.
Who needs monitoring
Any website that generates leads or sales needs at least basic uptime and certificate monitoring. It's inexpensive and already saves you from the nastiest surprises.
Deeper monitoring with error and resource tracking is needed for ecommerce stores, online services, portals with user accounts, and mobile apps with their own backend. For large systems, it's an essential part of high-load project support: without data, there's no way to tell what's slowing things down.
If you have a small brochure website, you don't need extra complexity. We won't push dozens of dashboards where a single check and an email or Slack alert will do.
Tools: from simple to advanced
- External uptime services such as UptimeRobot. They check the site from the outside, are quick to set up, and suit smaller projects. But they only see what a visitor sees, not the underlying cause.
- Error tracking with Sentry. Shows specific code errors in detail, so developers immediately see what to fix.
- Infrastructure monitoring with Prometheus and Grafana or Zabbix. Collects detailed server and application metrics, with charts and trends. It requires setup and maintenance, so it makes sense for mid-size and large projects.
- Centralized logging. When you have several servers, it's convenient to collect logs in one place, for example viewed in Kibana, so you can search for the cause of an outage instead of checking each server separately.
If the project runs in the cloud, some of these needs are covered by the provider's built-in tools, and we use them to avoid paying twice.
How not to drown in alerts
The most common monitoring problem isn't a lack of alerts — it's too many. When your phone buzzes twenty times a day over minor issues, people stop responding, and a real outage gets lost in the noise.
So we split alerts into levels. Critical ones — site down, payments failing — go out immediately, at any hour. Warnings — disk three-quarters full, a page starting to load slower — go to a work channel and are handled during the day. Minor items are rolled up into a digest that we review periodically.
What happens when an alert fires
An alert only matters if someone knows what to do with it. So along with the setup, we agree on:
- who gets the alert first and who steps in if the first person doesn't respond;
- what to check first for each type of failure;
- how and when to notify you, the business owner, and whether customers need to be informed;
- how to record the root cause after recovery and what to change so it doesn't happen again.
What to prepare on your side
- a list of pages and features your business can't run without: checkout, payments, lead forms, account login;
- access to the server, code, or cloud account if deeper monitoring is needed;
- a list of people who should receive alerts and their preferred channels;
- information about peak hours and planned maintenance so they don't trigger false alarms;
- a history of recent outages: what broke, for how long, and how you found out.
If some of this information is missing, that's fine: basic checks can start right away, and the rest can be added later.
How we measure results
Monitoring alone doesn't make a site more stable — it makes problems visible. So we judge results this way: the team learns about outages before customers do, the time from a problem starting to being fixed gets shorter, and the same failures stop recurring.
We don't promise your site will never go down. But with monitoring, you'll know exactly how long it ran without interruption and can make decisions based on numbers, not gut feeling.
Common mistakes
- Checking only the homepage when it's the payment step or the cart that may be broken.
- Sending all alerts to one person who might be on vacation.
- Hosting monitoring on the same server as the website: if the server goes down, so do the alerts.
- Setting up monitoring and never revisiting it, even though the site has changed significantly since.
What affects the cost
- Number of systems and checks: one website or several services, servers, and integrations.
- Depth: uptime only, or code errors, resources, logs, and business metrics too.
- Tools: subscription-based services or self-hosted monitoring systems that need to be deployed and maintained.
- Response: alert setup only, or our on-call coverage and incident resolution as well.
FAQ
Can monitoring be set up without server access? Partially. External uptime checks work without access, but to see errors and resources, we need access to the code or server.
Who will respond to alerts? That's up to you. We can set up monitoring for your team only, or respond ourselves as part of technical support.
Will monitoring slow down the site? No, not if it's set up correctly. Checks and metric collection create very little load compared to regular visitors.
Why track business metrics if the site loads? Because the site can load while orders fail to go through due to a payment or shipping issue. Orders dropping to zero during business hours is often the first and most reliable sign of such a problem.
Does monitoring work for mobile apps? Yes. We monitor the backend the app talks to and collect errors from the app itself to spot failures on specific devices.
Why Promodex
We don't just set up monitoring — we've been building and supporting websites since 2015, so we know which signals really matter to a business and which are noise. When our in-house team supports your site, alerts go to the same developers who then fix the issue, so nothing has to be handed off between contractors. Monitoring pairs well with website support and backups.
