Why monitor your website?
When your business depends on your website it is essential that it's functioning correctly. Downtime, slow pages or important functions, such as an add to cart button, not working can have serious consequences.
You can of course manually verify if these things are working but that's not an effective use of your time and you will probably find out when the damage is already done.
This is where monitoring your website comes in, it will automate these checks for you and notify you when something goes wrong.
Level 0 - No monitoring
At level 0 there is no automated monitoring at all. The only way you know if something is wrong is by manually checking your website or hope a user tells you.
This usually looks like:
Opening the homepage every now and then
Clicking around when you remember
The problem isn’t that manual checks don’t work. It’s that they are a waste of your valuable time and they’re not continuous.
Websites don’t break on your schedule. They break at 3 AM, during deployments, after dependency updates, or when traffic spikes. A quick check in the morning tells you nothing about what happened overnight.
Even worse, manual checks are reactive. You only notice issues after:
Customers complain
Orders fail
Search engines/users hit errors
For hobby projects or internal tools with zero impact, level 0 might be acceptable. For anything even remotely business-critical, it’s a risk you’re probably taking without realizing it.
Level 0 isn’t really a strategy. It’s just hope.
Level 1 - Uptime & Latency Monitoring
Level 1 is where monitoring actually begins.
At this level you automatically check whether your website is reachable and how long it takes to respond. A monitoring service such as Vigilant sends a request to your site at a fixed interval and verifies that it gets a successful response back.
This answers two fundamental questions:
Is my website up?
Is it responding within a reasonable time?
If the check fails or the response time crosses a threshold, you get notified.
This already removes a huge blind spot compared to level 0. Instead of finding out from users or random manual checks, you’re alerted as soon as your website becomes unreachable.
However, it’s important to understand what uptime monitoring really measures and what it doesn’t.
An uptime check usually:
Requests a single URL (often the homepage)
Verifies the HTTP status code (e.g. 200 OK)
Measures total response time
That means your server could be returning a 200 response while:
Critical pages are broken
The checkout flow is failing
APIs are erroring
Content is missing or incorrect
From the monitor’s perspective, everything looks fine.
Latency monitoring helps a bit by catching slow responses early. A site that takes 8 seconds to respond is technically “up”, but for users it might as well be broken.
Level 1 is essential. It gives you basic awareness and fast alerts when your site goes completely down or becomes very slow.
But it’s still a blunt instrument. It tells you that something is wrong, not what is wrong.
Level 1.5 - Worldwide Uptime & Latency Monitoring
Level 1.5 builds directly on basic uptime and latency monitoring, but fixes one of its biggest blind spots: location.
With standard uptime monitoring, all checks come from a single region. If your site works from that location, the monitor reports everything as healthy even if users elsewhere can’t reach your site at all. What's even worse is monitoring from the same datacenter or server that your website is running on, the monitoring service will then never go over the internet!
At this level, the same uptime and latency checks are executed from multiple geographic locations around the world.
This helps answer new, very real questions:
Is my website reachable globally?
Are users in certain regions experiencing slowness or outages?
Is this issue local or widespread?
This matters more often than people expect.
Problems that worldwide monitoring catches:
CDN misconfigurations serving bad content in one region
Regional cloud outages
DNS resolution failures in specific countries
Routing issues between ISPs
Firewalls or geo-blocking rules gone wrong
From your perspective everything might look fine. From a user in another continent, your site could be completely down.
Latency data becomes much more useful at this level as well. A response time of 300 ms in Europe might be 2.5 seconds in Asia. That’s not a backend issue, it’s an infrastructure and delivery problem you wouldn’t see from a single location.
Level 1.5 doesn’t add new types of checks, but it adds context. When an alert fires, you can immediately tell whether:
The problem is global
The problem is regional
The problem is likely infrastructure-related
For websites with an international audience, level 1.5 isn’t a luxury. It’s the difference between thinking your site is healthy and knowing that your users can actually reach it.
Level 2 - Certificate Monitoring
At level 2, monitoring goes beyond availability and speed and starts covering security basics specifically, SSL/TLS certificates.
Every website that uses HTTPS (which should be all of them) relies on a certificate to encrypt traffic and prove identity. When a certificate expires or is misconfigured, users get scary browser warnings, which can instantly erode trust and probably stop them from visiting your site.
Certificate monitoring automates the task of keeping an eye on:
Expiration dates
Validity of the certificate chain
Correct domains covered by the certificate
Without monitoring, you might only notice a certificate problem when a user reports a warning or your own browser blocks access. That’s reactive and by that time, your site’s reputation can already take a hit.
With certificate monitoring in place, you can:
Receive alerts weeks or days before a certificate expires
Detect certificates that have been replaced or revoked unexpectedly
Avoid downtime caused by HTTPS errors
Nowadays most renewals are automatic but automatic processes can fail causing your certificates to break. Better to prevent it.
Level 3 - Broken Link Monitoring
At level 3, monitoring starts to look inside your website instead of just at the front door.
Broken link monitoring works by crawling your website and following links, similar to how a search engine bot does. It checks whether the pages and resources your site points to actually return valid responses.
This helps you catch:
404 pages (page not found)
500 errors (server errors)
Broken internal links
Missing images, scripts, or stylesheets
From an uptime monitor’s point of view, your site can be perfectly healthy while large parts of it are effectively broken for users.
A few common ways broken links appear:
Pages are renamed or deleted without redirects
CMS changes update URLs
Old blog posts link to removed resources
External services shut down or change their URLs
Assets fail to load after deploys
For users, this creates friction and frustration. For search engines, it’s a quality signal. Too many broken links can hurt crawl efficiency and SEO performance.
Broken link monitoring turns this into a proactive process. Instead of stumbling upon issues months later, you get a report or alert when new errors appear.
This level shifts monitoring from “is my site up?” to “is my site usable?”
It’s also the first level where monitoring becomes comprehensive, because it touches many pages instead of a single URL.
Once you have this in place, the next logical step is not just whether pages load but how well they load.
Level 4 - Performance Monitoring
At level 4, monitoring focuses on how your website feels to users, not just whether pages return a response.
Performance monitoring measures things like:
Page load time
Time to first byte
Largest Contentful Paint (LCP)
Cumulative Layout Shift (CLS)
Total blocking time
A common way to do this is by running tools like Google Lighthouse on your pages at regular intervals.
This level catches issues that uptime and link checks completely miss:
A page that technically loads but takes 10 seconds to become usable
Heavy images or scripts slowing down critical pages
Performance regressions after deployments
Third-party scripts silently degrading load times
Performance problems are dangerous because they don’t feel like “downtime.” Your site is up, links work, nothing is broken but users bounce, conversions drop, and SEO rankings slowly decline.
By monitoring performance over time, you get:
Baselines you can compare against
Early warnings when scores or metrics degrade
Confidence that changes actually improved things
This also makes performance actionable. Instead of running Lighthouse once during development and forgetting about it, you treat performance as a living part of your site.
Level 5 - Synthetic Monitoring
Synthetic monitoring runs scripted user flows in real browsers. Instead of checking a single page, it simulates actions such as:
Logging in
Searching for a product
Adding an item to the cart
Completing a checkout
Submitting a form
These flows are executed on a schedule, from start to finish, and every step is verified.
This level catches problems that all previous levels miss:
JavaScript errors breaking interactions
Backend APIs returning unexpected data
Authentication failures
Third-party integrations timing out
“Everything loads, but nothing works” scenarios
From the outside, your site can look perfectly healthy:
Uptime is green
Pages load fast
Links aren’t broken
And yet, your core business flow is dead.
Synthetic monitoring gives you confidence in what actually matters: that users can complete the actions you depend on.
This used to be difficult for non technical people to setup as it required code to write the test cases. But with the rise of AI it is now possible to control a browser with English sentences. An example of that is Vigilant's Flows feature allowing everyone to easily write and understand these flows.
Level 6 - Application Health Monitoring
Level 6 focuses on the internal health of your application, not just what’s visible from the outside.
Application health monitoring relies on health checks: dedicated endpoints or signals that report whether critical parts of your system are functioning correctly. Instead of asking “does this page load?”, you ask “is the application actually healthy?”
A proper health check can verify things like:
Database connectivity
Cache availability
Queue consumers running
Background jobs processing correctly
Dependency services responding
From the outside, your site might still return a 200 OK, while internally it’s already in trouble. For example:
The database connection pool is exhausted
Background workers have crashed
A queue is backing up silently
A third-party dependency is timing out
Uptime monitors won’t catch this. Synthetic flows might not hit the affected path. Health checks surface these issues before they turn into user-facing failures.
Level 7 represents a mindset shift. Monitoring is no longer just observing outcomes, it’s observing system state. You gain confidence not only that your application works right now, but that it’s operating within safe boundaries.
With this level in place, monitoring becomes deeply tied to how your application is built and operated.
Level 7 - Security Monitoring
At level 7, monitoring shifts from availability and functionality to risk.
Security monitoring continuously checks your website and its dependencies for known vulnerabilities, misconfigurations, and exposures. This often includes scanning for:
Known CVEs in frameworks and libraries
Outdated software versions
Common security misconfigurations
Exposed services or endpoints
Weak headers or insecure defaults
The key difference at this level is intent. Everything before this level focuses on “is my site working?”
Security monitoring asks: “Is my site safe from attackers?”
Security issues rarely announce themselves. There’s no downtime, no broken page, no failed request. Your site keeps working until it doesn’t, or until data is leaked, defaced, or abused.
Without monitoring, you’re relying on:
Manual audits
Occasional dependency updates
Hoping nothing critical was missed
With security monitoring, you get:
Early warnings when new vulnerabilities affect your stack
Visibility into risks introduced by updates or new dependencies
Time to patch before issues are exploited
This level doesn’t replace proper security practices, but it adds a crucial feedback loop. It helps you move from reactive patching to proactive risk management.
Bonus: DNS Monitoring
DNS monitoring sits slightly outside the main levels, but it plays a critical supporting role.
DNS is the entry point to your website. If it breaks, nothing else matters, uptime checks, health checks, and synthetic tests all fail at once.
DNS monitoring focuses on observing your DNS records and detecting unexpected changes or resolution issues.
This includes:
Monitoring A, AAAA, CNAME, MX, and TXT records
Detecting record changes or deletions
Alerting on propagation or resolution failures
DNS issues are surprisingly common and often hard to diagnose:
Records accidentally modified
Unauthorized or malicious changes
Without DNS monitoring, you usually find out the hard way when your entire site is unreachable for hours.
What makes DNS monitoring especially valuable is how quiet DNS failures are. There’s no error page from your application. There’s just… nothing. And if you're unsure, it's always DNS.
By monitoring DNS, you get:
Early warnings before outages fully propagate
Clear visibility into what changed and when
DNS monitoring doesn’t replace other levels, but it reinforces all of them. It ensures that users can even reach the infrastructure you’ve worked so hard to protect.
Conclusion
Website monitoring isn’t a single tool or a checkbox you tick once. It’s a progression.
Each level adds a new layer of visibility: from basic uptime, to global reach, to performance, functionality, system health, and security. You don’t need to start at the highest level on day one, but you do need to be intentional about what you don’t see yet. Software like Vigilant do make it easy for you to reach all levels with minimal effort.
Monitoring turns unknown failures into known signals. It replaces guesswork with insight and reaction with prevention.
Great websites don’t just work - they’re observed, understood, and cared for. Monitoring is how you get there.