My Uptime Monitoring Setup

I was asked a few times recently how I monitor the systems I run, so I decided to write it down. There is no single tool for everything in my setup. I use four tools, and I'll go through them one by one.

Barkme as an independent observer

I start from outside, because I think a monitor should never live on the same infrastructure it watches. If the server goes down, any check running on that server goes down together with it. And if DNS or an SSL certificate breaks, the application can look completely fine from the inside while nobody can actually open the site.

So I want an independent observer, something that checks my sites from the outside, the same way a real visitor reaches them. For that I use Barkme, our uptime monitoring service. We built it at Well Digit, and honestly this idea of an independent observer was the main reason we built it.

It checks websites and APIs by their public URL, as often as every 30 seconds. It also keeps an eye on SSL certificates and domain expiry and warns me 30, 14, 7 and 1 days before something lapses, and once a day it checks the domain reputation against Spamhaus, SURBL and URIBL. Alerts come to me in Slack, Telegram, email or a webhook, and if Linear or Trello is connected, an outage also opens a ticket there. Every project can have its own public status page as well.

Some parts of Barkme we published as open-source Laravel packages, in case you need them in your own app: SSL Keeper, Domain Keeper, Domain Verifier, and clients for Slack, Telegram, Linear and Trello.

Laravel Forge for the servers

My servers are managed with Laravel Forge, so for the server level I simply use its built-in monitoring. Forge watches CPU load, used memory and used disk space, and sends me an email when one of them crosses the threshold I set. CPU and memory are checked every minute, disk every hour.

You set it up in the server's Observe tab. Just keep in mind that server monitoring is part of the Business plan, and each monitor sends to one email address, so it makes sense to use a team address there.

Laravel Nightwatch for the applications

The site can be reachable and the server can be healthy, and the application can still have problems. For that part I use Laravel Nightwatch.

It is made for Laravel, and it records pretty much everything that happens in the app: requests, outgoing requests, queries, jobs, mail, notifications, commands, cache and scheduled tasks. In practice I mostly look at three things there: exceptions (Nightwatch groups them into issues), slow routes, and scheduled tasks that failed or didn't run. You install it as a package with an agent, and there is a guide in the Nightwatch docs for running it on Forge.

Telegram for important events

The last part is not about errors at all. In some systems there are events that I want to know about right away, like a new lead, a new customer or a failed payment. For these I have small custom triggers that send a message to a private Telegram chat.

It is very simple: a listener on an event that sends a short message with the Laravel Telegram client.

use App\Events\SubscriptionPaymentFailed;
use Labrodev\Telegram\Services\TelegramClient;

final class NotifyTeamOfFailedPayment
{
    public function __construct(private TelegramClient $telegramClient) {}

    public function handle(SubscriptionPaymentFailed $event): void
    {
        $this->telegramClient->sendMessage(
            chatId: config('services.telegram.headlines_chat_id'),
            text: "Payment failed: {$event->subscription->customer->name}",
        );
    }
}

I run these listeners on the queue and keep a separate chat for each system. Errors stay in Nightwatch, so in Telegram I only get the things I really want to read.

To sum up

With these four in place, I usually find out about a problem before a client does.