Broken links are one of those problems that feel minor until they aren't. A client's top landing page quietly 404s after a migration. A product link in a three-year-old blog post points to a deleted SKU. Googlebot wastes crawl budget chasing dead ends across your websites. It just accumulates, silently eroding SEO performance, user trust, and your credibility as the agency responsible for keeping these sites healthy.

Picking an uptime monitoring tool sounds simple until you're staring at a comparison table with twelve vendors, three pricing models, and a handful of "free forever" plans with strings attached. I've been through this process more times than I'd like so let me cut through the noise and give you a straight comparison you can actually use.

Running a Lighthouse audit feels productive. You open DevTools, hit Analyse, watch the spinner, and get a score. Green numbers look good. You move on. Six weeks later, a client emails asking why their site feels slow. When you run the audit again, the score has quietly collapsed from 84 to 61. Something changed. You just don't know what, or when.

Picking a Lighthouse monitoring tool in 2026 is harder than it should be. The market has fragmented into pure-lab tools, pure-field tools, and blended platforms each with its own quota model, diagnostic depth, and pricing. Let's look at eight options across the criteria that actually matter: data sources, diagnostics, alerting, and cost.

Synthetic monitoring has moved from "nice to have" to a core reliability practice for most teams. Browser-based checks catch what uptime pings miss: broken checkout flows, failed logins, JavaScript errors that only surface under real navigation. The problem is the tooling landscape is fragmented, pricing is hard to compare, and the wrong choice means either drowning in flaky alerts or paying enterprise rates for features you don't need.

Broken links are the slow leak in your agency's SEO hull. They don't announce themselves, they don't trigger alerts, and your clients almost certainly don't know they exist, until a customer hits a 404 on a product page, or until rankings quietly slide over a quarter and nobody can explain why. By then, the damage is done and the conversation is uncomfortable.

DNS is the foundation everything else sits on. When it breaks, your client's site goes offline, their email stops working, and their SEO starts bleeding. And when you find out it can take hours to fix because DNS is slow. DNS incidents can be caught in minutes with the right monitoring in place.

Synthetic monitoring has a broken reputation and honestly, it deserves it. Teams set up Selenium or Playwright flows, spend a week wiring everything together, and then watch the whole suite collapse three weeks later because a developer renamed a CSS class. The monitors get disabled, the alerts get ignored, and the checkout flow breaks on a Friday evening with nobody noticing until Monday morning.

AI-powered synthetic monitoring changes that equation.

Unmonitored Lighthouse scores drift. They drift silently, incrementally, and usually in ways that don't trigger any of your existing alerts because uptime is still green, SSL is still valid, and the site is technically "up". By the time a client flags a slowdown or an SEO audit surfaces the damage, you're looking at months of compounded regressions. If you're managing 20+ client sites, that's not a hypothetical risk but something that will happen.

When developing a package for a Laravel or Statamic based application you usually need to add it to a project to run it.
Sometimes it's nice to have a clean application for this so you know that it works with a clean install.

In this article I'll share how I've setup a quick Docker based environment that can be used to develop and test a package without requiring it in an existing project.

With many CVE's being released each week it's hard to keep up, especially since most of them don't even affect you. But a missed CVE that does affect you can have serious consequences.
In this article I'm sharing which methods are effective to keep track of new CVE's so you can patch quickly.

Website downtime is more than an inconvenience. When your site is unavailable, users leave, trust is damaged, and revenue can disappear in minutes. For businesses that rely on their website, even short outages can have long-term consequences.

Website monitoring is more than just pinging your site and checking if your homepage loads. In this article I will share what you can monitor on your website to ensure it's running smoothly. Great websites don't just work, they are cared for and monitoring helps you get insight in that.

Marketing isn't easy, especially at the beginning. In this article I'll share how I prepared for launching a Google Ads campaign and the results of the first week including the tweaks I made based on that.

The weather is getting colder which makes the perfect time to make the uptime monitoring of my open source monitoring tool more reliable. In this article, I’ll walk you through how I designed the architecture for multi-location monitoring, how I implemented it and how to host it yourself.

As a backend developer my strongest point really isn't design and UX. I always envy people who are good at this as it's an amazing thing to be good at. The last few months I've had feedback, learned a lot and redesigned Vigilant's homepage a few times.

Vim gives developers an extra dimension when editing and navigating code. It's another way of thinking when writing code. I've been using Vim for the past 2.5 years and the experience of using Vim makes programming a lot more fun.

If you run a serious website, you need to know when it’s down. Uptime monitoring helps with that, but it only tells part of the story. Just because your homepage returns a 200 OK doesn’t mean your users can log in, check out, or even access critical features. There are many tools that monitor uptime but when you are just monitoring uptime there can still be other issues present.

A while ago I saw a message in a Slack channel that I'm in about someone that is building a tool to do security / code quality checks on PHP projects. He wanted a codebase to test his tool so I offered Vigilant.
I've received a detailed report on the code quality and security of Vigilant, in this post I'll share the report.

In this article I'd like to share how I've setup the codebase for Vigilant, an open source web monitoring application. Vigilant is designed to be an all-in-one solution for monitoring a website, that means from uptime to certificates to CVE's. I wanted to keep the codebase clean and split each of these parts so that it does not become one big mess.

Vigilant has reached 100 stars after 15 months on Github 🎉
In this article I share the road towards 100 stars.

When working with Laravel Horizon, it’s easy to get started, run php artisan horizon, dispatch some jobs, monitor them in the dashboard, and you’re good to go. But as your application scales and the amount of jobs grow more complex, subtle issues begin to surface. The design of your jobs and configuration of Horizon and Redis must be correct in order to run Horizon without issues.

Unique jobs are great for ensuring that a job is never dispatched twice, but when misconfigured it can cause strange issues such as your job not dispatching. Most jobs in Vigilant are unique, for example, the uptime monitor dispatches a job at a specified interval but if for any reason the job hasn't executed within that interval I do not want another job on the queue.

But they can be tricky, there are a few things that can cause them to break.

When your SSL certificate expires, things break.

Browsers throw up scary warnings. APIs stop talking to each other. Your users bounce. And unless you’re actively tracking expiration dates, it’s easy to miss.

Certificate Monitoring is a new Vigilant feature that makes sure that never happens.

I've recently tagged the first version of Vigilant, 2025.4. As you can see it is not a traditional SemVer number like 0.1 or 1.0.
In this article I'd like to share the reason why I've chosen calendar versioning instead of the more traditional semver.

It's been more than a year since I made the first commit for Vigilant and today I'm tagging the first release.
Vigilant is an open source web monitoring application that strives to monitor all aspect of a modern website.
By all aspects I mean from uptime to DNS to Lighthouse scores. At the current state of the project Vigilant contains about half of the features that I'd like in it. Some missing features are status pages, sitemap monitoring and a CRON monitor.

In this article I will talk about the steps I took to get from an idea to the first version.

Singletons are a great feature of Laravel's service container but users of the framework must be aware that context aware singletons can lead to unexpected behaviour in an application when using long living processes.

Deploying a Laravel application can be difficult for those who don't have experience with PHP applications. Docker is the solution to easily publish and let other people deploy your application without them needing to learn how it is exactly setup. In this article I will show how I've Dockerized Vigilant.

The past few months I've worked on getting Vigilant stable and self-hostable. The application now has three monitoring features and is ready to be self hosted using Docker. This means that everyone can start playing with Vigilant!

Vigilant is an open source technical monitoring application for websites and web applications.
It will monitor different aspects of your website in order to ensure that your site is running great.
When any of these monitors detect a change it will notify you through a flexible notification system.