DEV Community: Vigilmon

Stop Finding Out About Downtime from Users — Monitor Your Node.js App

Vigilmon — Tue, 23 Jun 2026 02:23:46 +0000

There's a particular kind of dread that hits when a user DMs you "hey, is your app down?" You check the URL. Yep. Down. For how long? Who knows. When did it go down? Mystery.

If you've been there, you know the feeling. And if you haven't — you will.

Uptime monitoring means you get the alert, not your users. In this tutorial, I'll show you how to set up monitoring for your Node.js app in about 5 minutes using Vigilmon — a free uptime monitoring service. We'll also wire up a webhook so you can pipe those alerts directly to Slack or Discord.

What is Vigilmon?

Vigilmon is a lightweight uptime monitor that pings your endpoints every minute and alerts you when something goes wrong. It supports HTTP/HTTPS checks, TCP port checks, email and webhook alerts, and public status pages. The free tier gets you up to 10 monitors — enough to cover most side projects and small production apps.

Step 1: Sign Up and Add Your Monitor

Head to vigilmon.online and create a free account. Once you're in, click Add Monitor and fill in:

Name: Something memorable (e.g., "My Express API")
URL: Your app's health check endpoint (e.g., https://api.myapp.com/health)
Check interval: 1 minute

If you don't have a dedicated health endpoint yet, add one — it's worth it:

// Express.js health check endpoint
app.get('/health', (req, res) => {
  res.status(200).json({ status: 'ok', uptime: process.uptime() });
});

Vigilmon will ping this URL every minute and look for a 2xx response. If it gets anything else — or no response at all — it fires an alert.

Step 2: Set Up Email Alerts

In your monitor settings, go to Alert Channels and add your email address. That's it. Next time your app goes down, you'll get an email within 1-2 minutes.

This is your bare minimum. But email has latency — you might miss an alert in a busy inbox. For production apps, you want something louder.

Step 3: Add a Webhook for Slack/Discord Alerts

Vigilmon can POST a JSON payload to any URL when your monitor status changes. Here's how to wire that up.

Create a Webhook Receiver in Node.js

Here's a simple Express app that receives Vigilmon webhooks and forwards them to Slack:

const express = require('express');
const https = require('https');

const app = express();
app.use(express.json());

const SLACK_WEBHOOK_URL = process.env.SLACK_WEBHOOK_URL;

app.post('/webhooks/vigilmon', (req, res) => {
  const { monitor_name, status, url, checked_at } = req.body;

  const emoji = status === 'down' ? '🔴' : '✅';
  const message = `${emoji} *${monitor_name}* is ${status.toUpperCase()}\n URL: ${url}\n Detected: ${checked_at}`;

  const payload = JSON.stringify({ text: message });
  const slackUrl = new URL(SLACK_WEBHOOK_URL);

  const options = {
    hostname: slackUrl.hostname,
    path: slackUrl.pathname + slackUrl.search,
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
  };

  const request = https.request(options);
  request.write(payload);
  request.end();

  res.sendStatus(200);
});

app.listen(3000, () => console.log('Webhook receiver running on port 3000'));

Deploy this alongside your app (or as a standalone service) and grab the public URL. Then in Vigilmon, go to Alert Channels → Add Webhook and paste in your endpoint: https://yourdomain.com/webhooks/vigilmon.

Routing to Discord Instead

Discord uses a slightly different webhook payload format:

// For Discord, swap out the Slack payload
const discordPayload = JSON.stringify({
  content: `${emoji} **${monitor_name}** is ${status.toUpperCase()} — ${url}`,
});

Same idea — point it at your Discord channel's incoming webhook URL and you'll get real-time pings in your server.

Step 4: Share a Public Status Page

One of the underrated features of Vigilmon is the public status page. Go to Status Pages in the dashboard and create one that lists your monitors. You'll get a shareable URL like:

https://status.vigilmon.online/your-page-slug

Add this link to your app's footer, docs, or support email. When something breaks, customers can check status themselves before flooding your inbox with "is it just me?" questions.

Why This Matters

Here's the honest truth: most outages last under 10 minutes for simple restarts or deploy errors. But without monitoring, those 10 minutes are invisible to you and visible to every user who hits a 503.

With Vigilmon running:

You know within about 1 minute when something goes down
You have exact timestamps for incident reports and post-mortems
Customers can check a status page instead of guessing

Wrapping Up

Getting uptime monitoring set up for a Node.js app takes less than 5 minutes with Vigilmon — free account, one monitor, email alerts, and an optional webhook for Slack or Discord.

Give it a try at vigilmon.online and drop a comment below with how you've set up alerting for your own apps. I'm especially curious what people are doing with webhooks in production.

Free Uptime Monitoring for Your Node.js App with Vigilmon

Vigilmon — Tue, 23 Jun 2026 01:26:41 +0000

Your Node.js cron job ran at 3am. Or did it? Your Express API is returning 500s to production users right now. Do you know?

Most developers only find out their Node.js app went down when a user files a support ticket — hours after the fact. By then, you have lost trust, revenue, and a weekend.

In this tutorial, you will set up free uptime monitoring for your Node.js/Express app using Vigilmon in under 10 minutes. We will cover:

HTTP uptime checks for your Express API endpoints
Heartbeat monitoring for Node.js cron jobs
SSL certificate expiry alerts
Slack and email notifications

No credit card required.

1. The Problem: Silent Failures Kill Trust

Node.js apps fail in two distinct ways:

Loud failures — your app crashes, PM2 restarts it, you get an error log. These are annoying but visible.

Silent failures — your cron job silently stops running. Your API returns 500s but never crashes. Your SSL cert expires and Chrome starts showing warnings. These are the killers.

For Express APIs, a silent 500 means users see an error but your server is technically "up." For cron jobs — things like sending emails, syncing data, or processing queues — the job just stops. No crash, no log entry, no alert.

You need external monitoring that checks from outside your infrastructure.

2. What Vigilmon Monitors

Vigilmon offers three types of monitoring that directly address Node.js failure modes:

HTTP Checks — Vigilmon pings your API endpoints every minute and alerts you if they return non-2xx status codes or take too long to respond. Perfect for Express routes.

Heartbeat Monitoring — Your cron job sends a "heartbeat" ping to Vigilmon after each successful run. If Vigilmon does not receive a ping within the expected window, it fires an alert. This catches silent cron failures.

SSL Expiry — Vigilmon warns you 30, 14, and 7 days before your SSL certificate expires. No more unexpected "connection not secure" warnings for your users.

All of this is free on the free tier — no credit card needed.

3. Set Up HTTP Monitoring for Express

Step 1: Add a health check endpoint

Add a /health endpoint to your Express app. This gives Vigilmon a reliable endpoint that does not require auth:

// app.js
app.get('/health', (req, res) => {
  res.json({ status: 'ok', timestamp: new Date().toISOString() });
});

If you want to verify database connectivity too:

app.get('/health', async (req, res) => {
  try {
    await db.query('SELECT 1');
    res.json({ status: 'ok', db: 'connected' });
  } catch (err) {
    res.status(503).json({ status: 'error', db: 'disconnected' });
  }
});

Step 2: Create an HTTP monitor in Vigilmon

Sign up at vigilmon.online (free, no card)
Click Add Monitor → HTTP Check
Enter your endpoint URL: https://yourdomain.com/health
Set the check interval (1 minute on the free tier)
Set an alert threshold — e.g., alert if response time > 3000ms or status is not 2xx

Vigilmon will start pinging your endpoint immediately and alert you the moment it goes down.

4. Heartbeat Monitoring for Node.js Cron Jobs

This is the killer feature for Node.js backends. Here is how it works:

You create a heartbeat monitor in Vigilmon with an expected interval (e.g., every 5 minutes)
At the end of each successful cron job run, your code sends a GET request to Vigilmon's ping URL
If Vigilmon does not receive a ping within the expected interval plus a grace period, it fires an alert

Setting it up with `node-cron`

First, create the heartbeat monitor in Vigilmon:

Click Add Monitor → Heartbeat
Name it (e.g., "Email digest job")
Set the expected interval (e.g., 5 minutes)
Copy the ping URL — it will look like https://vigilmon.online/api/heartbeat/ping/abc123

Then wire it into your cron job:

const cron = require('node-cron');
const https = require('https');

// Store your ping URL in .env
const VIGILMON_HEARTBEAT_URL = process.env.VIGILMON_HEARTBEAT_URL;

function pingVigilmon() {
  https.get(VIGILMON_HEARTBEAT_URL, () => {}).on('error', (err) => {
    console.error('Vigilmon ping failed:', err.message);
  });
}

cron.schedule('*/5 * * * *', async () => {
  try {
    // Your actual job logic
    await processEmailQueue();
    await syncDataFromAPI();

    // Only ping after successful completion
    pingVigilmon();
    console.log('Job done, heartbeat sent');
  } catch (err) {
    console.error('Job failed:', err);
    // No ping = Vigilmon alerts after the grace period
  }
});

The key principle: only ping after successful completion. If your job throws, skip the ping. Vigilmon will notice the missed heartbeat and fire an alert.

Using axios instead

const axios = require('axios');

async function pingVigilmon() {
  try {
    await axios.get(process.env.VIGILMON_HEARTBEAT_URL);
  } catch (err) {
    console.error('Vigilmon ping failed:', err.message);
  }
}

Store the URL in .env:

VIGILMON_HEARTBEAT_URL=https://vigilmon.online/api/heartbeat/ping/YOUR_ID_HERE

Monitoring multiple cron jobs

For multiple jobs, create a separate heartbeat monitor for each one — this gives you per-job failure visibility:

const monitors = {
  emailQueue: process.env.VIGILMON_EMAIL_HEARTBEAT_URL,
  dataSync: process.env.VIGILMON_SYNC_HEARTBEAT_URL,
  reports: process.env.VIGILMON_REPORTS_HEARTBEAT_URL,
};

async function runEmailJob() {
  await processEmails();
  await axios.get(monitors.emailQueue);
}

async function runSyncJob() {
  await syncFromAPI();
  await axios.get(monitors.dataSync);
}

5. Configure Slack and Email Alerts

Email alerts

Vigilmon sends alerts to your account email by default. Add extra recipients under Settings → Notifications.

Slack alerts

Go to Settings → Integrations → Slack
Click Connect to Slack and authorize the app
Choose which channel receives alerts (e.g., #incidents or #ops)

When your Express API goes down or a cron job misses its heartbeat, you get a Slack message within the minute. The alert includes the monitor name, failure type, timestamp, and a direct link to investigate.

When the issue resolves, Vigilmon sends a recovery notification automatically — no manual clear required.

6. Optional: Public Status Page

If you want your users or team to see uptime history without logging into Vigilmon, you can publish a public status page in one click.

Go to Settings → Status Page, toggle it on, and Vigilmon generates a public URL that shows:

Current status of all your monitors
Uptime percentage over the last 30 and 90 days
Incident history

Zero extra configuration needed — it reflects the monitors you have already set up.

Recap

Here is what you now have in place:

Scenario	What happens
Express API returns 500s or goes offline	HTTP monitor alerts within 1 minute
Cron job silently stops running	Heartbeat monitor alerts after missed ping
SSL cert approaching expiry	30/14/7-day advance warnings
Alert fires	Instant Slack message and email
Users want to check status	Public status page URL

Free tier includes:

Up to 10 monitors
1-minute check intervals
Email and Slack notifications
Public status page
No credit card required

Get started at vigilmon.online — it takes less time to set up than it took to read this article.

Also worth reading: Monitor your Laravel app with Vigilmon

5 Signs Your Uptime Monitoring is Failing You (and What to Do About It)

Vigilmon — Tue, 23 Jun 2026 01:10:16 +0000

Uptime monitoring is supposed to give you peace of mind. Set it up, forget about it, and sleep soundly knowing you'll be the first to know when something breaks.

But a lot of teams are running monitors that give them a false sense of security. The tool says "all systems operational" — until a customer emails to ask why your site has been down for 20 minutes.

Here are five signs your uptime monitoring is quietly failing you.

1. You Get Alerts at 3am for Outages That Never Happened

False positives are the silent killer of on-call rotations. You get paged in the middle of the night, scramble to investigate, and discover... everything is fine. The monitor fired, but there was no real outage.

This usually happens because your monitoring tool is checking from a single probe. That probe had a momentary network blip — a packet drop, a DNS hiccup — and declared your site dead.

What to do: Use a monitor that requires consensus across multiple independent probes before firing an alert. If 4 out of 5 probes can't reach your site, that's a real outage. If only 1 out of 5 fails, it's network noise.

Vigilmon uses a 5-probe consensus model: an alert only fires when a majority of geographically distributed probes independently confirm the failure. This eliminates nearly all false positives without delaying detection of real incidents.

2. Your Monitor Only Checks from One Location

A single-region monitor can't tell you whether your site is down for everyone or just unreachable from one region. It also can't detect CDN failures, regional DNS issues, or geographic routing problems that affect only some of your users.

Here's a simple example of what a good monitor config should look like:

monitor:
  url: https://yourapp.com/health
  interval: 60          # check every 60 seconds
  regions:
    - us-east
    - eu-west
    - ap-southeast
  consensus_threshold: 3  # alert only if 3+ regions fail
  timeout_ms: 5000

If your current tool doesn't have something like regions in its config, you're flying blind for a portion of your users.

What to do: Choose a monitoring tool that checks from multiple geographic regions and only alerts when failures are confirmed across regions — not just from a single vantage point.

3. You Find Out About Downtime from Customers, Not Your Monitor

This is the most embarrassing sign. A customer Slacks you "hey, is your site down?" and you check your monitoring dashboard — green across the board.

This usually means one of two things:

Your monitor is checking the wrong endpoint (e.g., a static homepage instead of the actual app)
Your monitor's check interval is too long (checking every 5 or 10 minutes means users can experience nearly 10 minutes of downtime before you're even notified)

What to do: Monitor the real health of your application — not just the marketing page. Set up a dedicated /health endpoint that exercises your database connection, cache, and any critical dependencies. Then check it frequently — every 30–60 seconds at minimum.

// Laravel example: routes/web.php
Route::get('/health', function () {
    DB::connection()->getPdo();  // will throw if DB is down
    Cache::put('health_check', true, 10);
    return response()->json(['status' => 'ok']);
});

If you're on Laravel, check out our earlier guide: Monitor your Laravel app with Vigilmon for a step-by-step setup including health endpoints and webhook alerts.

4. Your SSL Certificate Expired Without Warning

SSL expiry is 100% predictable — the expiry date is baked into the certificate. Yet it catches teams off guard constantly. The reason: most uptime monitors only check whether your site responds with HTTP 200. They don't inspect the certificate.

When your SSL cert expires, browsers show a "Your connection is not private" error to every visitor. Your site might technically be "up" according to your monitor, but no one can use it.

What to do: Use a monitoring tool that actively inspects SSL certificates and alerts you with enough lead time to renew — ideally 30 days before expiry, with reminders at 14 and 7 days.

Vigilmon's SSL monitoring tracks your certificate expiry date continuously and sends alerts at configurable thresholds. No more scrambling at midnight to renew a cert that expired hours ago.

5. You Have No Public Status Page to Communicate with Users

Even the best monitoring setup can't prevent every outage. What separates good engineering teams from great ones is how they communicate during incidents.

Without a public status page, every outage turns into a support ticket storm. Users don't know whether to wait, switch tools, or escalate internally. Your support team spends the incident manually responding to "is this down for everyone?" messages.

A public status page gives users one place to check. It reduces inbound support volume, builds trust by showing you're aware of the issue, and creates a historical record of your reliability.

What to do: Set up a status page and link to it from your app's error pages, your README, and your support docs. Make it the default answer to "is something wrong?"

Vigilmon includes a built-in public status page at no extra cost. It automatically reflects the real-time state of your monitors, so you don't need to manually update it during incidents.

Putting It Together

Good uptime monitoring isn't just about knowing when your site is down — it's about knowing accurately, quickly, and with enough context to act. It means catching problems before your customers do, getting paged only when something real is broken, and being able to communicate clearly when things go wrong.

If any of the five signs above sound familiar, it's worth auditing your current setup:

Are you checking from multiple regions with consensus-based alerting?
Is your health endpoint exercising real application dependencies?
Are you monitoring SSL expiry, not just HTTP status?
Do your users have somewhere to go during an incident?

If you're starting fresh or switching tools, Try Vigilmon free at vigilmon.online — no credit card required. It covers all five of these gaps out of the box, and you can have monitors running in under five minutes.

Create a Public Status Page in 5 Minutes with Vigilmon

Vigilmon — Mon, 22 Jun 2026 21:12:03 +0000

Your app goes down at 2am. Support tickets flood in. Users tweet angry things. But the worst part? Every single person had to check for themselves — no one knew what was happening.

Sound familiar?

A public status page changes all of that. It gives your users one place to check, saves your support team from repeating the same "we're investigating" message over and over, and signals that you take reliability seriously.

The good news: if you're already using Vigilmon for uptime monitoring, you're one click away from a live status page. No extra config, no third-party tools, no monthly bill for a separate service.

Here's how to set it up in under 5 minutes.

Why a Status Page Matters More Than You Think

Before we dive in, let's talk about why this is worth 5 minutes of your time.

Trust is built in the quiet moments. When your app is running fine, users don't think about uptime. But when it goes down, how you handle communication defines your reputation. A status page says: we're transparent, we know what's happening, and we're on it.

It cuts support volume dramatically. "Is the site down?" is one of the most common support questions for any SaaS product. A public status page lets users answer that question themselves — without emailing you, posting on Twitter, or assuming the worst.

It's table stakes for B2B. If you're selling to businesses, they'll ask whether you have a status page. It's part of their vendor evaluation checklist. Not having one raises red flags.

The tricky part used to be that running a status page meant either paying for a dedicated tool (Statuspage.io, Instatus, etc.) or building something custom. With Vigilmon, it's just part of the monitoring you're already doing.

What You'll Need

A Vigilmon account (free tier works — includes 5 monitors and unlimited status pages)
Your app's URL
About 5 minutes

That's it. Let's go.

Step 1: Sign Up for Vigilmon

Head to vigilmon.online and create a free account. The free tier gives you 5 monitors, 3-minute check intervals, and full access to status pages — no credit card required.

If you already have an account, skip ahead.

Step 2: Add a Monitor for Your App

Before you can show uptime on a status page, you need at least one monitor running.

Go to your dashboard and click Add Monitor. Fill in:

Monitor Type: HTTP(S) — for a URL
URL: Your app's public URL (e.g. https://yourapp.com)
Name: Something your users will recognize, like "App" or "API"
Check interval: Every 1–3 minutes on free tier

Click Save. Vigilmon starts checking your URL immediately. Within a minute or two, you'll see your first status data.

If you have multiple services — an API, a web frontend, a docs site — add a monitor for each. Your status page can show all of them.

Step 3: Create Your Status Page

In the sidebar, click Status Pages, then Create Page.

You'll see a simple form:

Page Name — This is the internal name for your reference (e.g. "Main Status Page").

Slug — This becomes the public URL. Something like status gives you a clean, shareable link. Keep it short.

Which monitors to show — Pick the monitors you want displayed publicly. You can show all of them, or be selective. For example, you might show your web frontend and API, but not your internal admin panel.

Click Create. Your status page is live immediately.

Step 4: Customize Your Page

Once created, you can edit a few things to make it feel like yours:

Page title and description — Set a heading like "YourApp System Status" and a short description like "Live uptime for all YourApp services."

Custom domain — If you want status.yourapp.com instead of the Vigilmon-hosted URL, add a CNAME record pointing to Vigilmon's servers. The settings page walks you through it. This takes 5–10 minutes for DNS to propagate.

Incident history — Status pages automatically show recent incidents pulled from your monitor downtime history. Users can see what happened and when — no manual updates required.

That's the whole setup. Your page is public and live.

Step 5: Tell People About It

The status page only helps if people know it exists. A few quick wins:

Add it to your footer. Most apps have a footer with links like "Privacy", "Terms", "Docs". Add "Status" alongside those. It takes 2 minutes and covers the most common discovery path.

Link it from your error pages. If your app has a 500 or 503 page, add a link to your status page. Users hitting an error page are exactly the audience who need it most.

Put it in your onboarding email. When new users sign up, drop the status page URL into your welcome email or docs. "Check status.yourapp.com for live service status."

Mention it in support responses. Next time a user emails about an outage, link them to the status page. They'll bookmark it for next time.

Bonus: Embed the Status Badge

If you want real-time status visible on your own website — without sending users to a separate page — Vigilmon provides an embeddable status badge.

Go to your status page settings and grab the badge embed code. It looks something like:

<a href="https://status.yourapp.com">
  <img src="https://vigilmon.online/badge/your-page-slug.svg" alt="System Status" />
</a>

Drop this into your site's header, footer, or landing page. It shows a live green/yellow/red indicator that updates automatically. No JavaScript required — it's just an SVG.

This is especially useful on landing pages and pricing pages where trust signals matter most.

Why We Built This Into Vigilmon

When we first built Vigilmon, we thought of monitoring as a developer tool — something for the team running the infrastructure. You add the monitors, you get the alerts, done.

But then we started hearing from users: "Our customers are asking if we have a status page. What do you recommend?"

We kept pointing people to third-party tools, but it felt wrong. The whole point of Vigilmon is that you shouldn't need a patchwork of services to manage your app's reliability. The monitoring data we already collect is exactly what a status page needs. So we built it in.

Now when your app goes down at 2am, your team knows immediately through alerts — and your customers can check the status page instead of emailing support. Everyone gets what they need.

What's Next

Once your status page is up, a few things to consider:

Add monitors for all public-facing services — API, CDN, docs, auth service. Anything a customer might interact with.
Set up email alerts — Get notified the moment something goes down. We covered that in detail in our Laravel monitoring tutorial.
Check your SSL expiry — Vigilmon monitors SSL certificates too. An expired cert looks just like downtime to your customers.

Vigilmon's free tier includes 5 monitors, which covers most early-stage SaaS products. If you need more, paid plans start at $7/month.

→ Get started at vigilmon.online

That's the whole thing. A public status page in 5 minutes, with no extra tools, no separate subscription, and no manual updates during outages.

If you found this useful, share it with someone who's still saying "we don't have a status page yet." That time is up.

How to Eliminate False Alert Fatigue in Your Uptime Monitoring Setup

Vigilmon — Mon, 22 Jun 2026 18:36:35 +0000

It's 3:47 AM. Your phone screams. Your site is down.

You stumble to your laptop, open your monitoring dashboard... and everything is green. False alarm. Again.

If you've been running production services for any length of time, you know this pain. False positives from uptime monitors don't just wake you up for no reason — they erode your trust in the monitoring system itself. Eventually, you start ignoring alerts. And that's when the real outages slip through.

Why Traditional Uptime Monitors Lie to You

Most uptime monitors work like this: a single server in a single location pings your site every 60 seconds. If it doesn't get a response, it fires an alert.

The problem? That single probe server might be experiencing:

Transient network issues (packet loss between the probe and your server)
BGP routing hiccups affecting one ISP or region
DNS propagation delays in a specific geographic area

Your site is perfectly healthy. Your users are unaffected. But your pager is going off at 4 AM.

The Fix: Multi-Region Consensus Checking

The solution to false positives is simple in principle: don't trust a single data point. Instead, check from multiple geographic locations simultaneously. Only alert when the majority of probes agree there's actually a problem.

This is what Vigilmon does. Before it fires an alert, it verifies the outage from multiple independent regions. If one probe sees a failure but others don't, it marks it as a transient blip — not an outage — and stays quiet.

Setting Up Vigilmon in 2 Minutes

Here's how to add your first monitor — no credit card required, free for up to 5 monitors:

Step 1: Create your account

Head to vigilmon.online and sign up. The free tier gives you 5 monitors with no credit card required.

Step 2: Add your first monitor

In the dashboard, click New Monitor and enter your URL. You can configure:

Check interval: how often to ping (default: 60 seconds)
Alert threshold: how many regions must agree before an alert fires
Notification channels: email, webhooks, or Slack

Step 3: Configure notification channels

Set up your preferred alerting channels. Vigilmon supports email notifications out of the box, with webhook support for integrating with PagerDuty, Slack, or any custom system.

Step 4: Trust your alerts again

Once you're monitoring with multi-region consensus, when an alert fires — it means there's actually an issue. Not a network hiccup between Frankfurt and your server. An actual outage.

What You'll See in the Dashboard

Vigilmon's response time history view shows you latency trends over time, color-coded so outliers stand out at a glance. You can quickly distinguish between:

✅ Healthy — fast, consistent response times
⚠️ Degraded — elevated latency, might need attention
❌ Down — confirmed outage from multiple regions

The 7-day and 30-day views make it easy to spot patterns: is there a specific time of day when your CDN slows down? Are response times gradually creeping up?

Breaking the False Alert Spiral

The compounding damage of false alerts is real: teams that get too many false positives start treating their monitoring as noise. They mute alerts, delay responses, and eventually lose visibility into actual incidents.

The fix isn't to ignore alerts more aggressively — it's to make your alerts worth trusting again.

Multi-region consensus monitoring means that when Vigilmon wakes you up, something is genuinely wrong. That's the only way to maintain alert hygiene over the long run.

Ready to stop getting paged for non-issues? Set up your first monitor in 2 minutes at vigilmon.online — free for up to 5 monitors, no credit card required.

We Shipped 36 Features in 30 Days — Here's What We Built (and Learned)

Vigilmon — Sat, 20 Jun 2026 13:46:58 +0000

On May 18 we launched Vigilmon — an uptime and website monitoring service for developers and indie makers who want to know when their sites go down before their users do. Since then, we've been heads-down building in public.

Here's every feature we shipped in the first 30 days.

🔍 Core Monitoring

1. Response time tracking — Every check now records and displays response time so you can catch performance degradation before it becomes an outage.

2. Incident history log — A full incident log with start/end timestamps and duration. See exactly when things broke and when they recovered.

3. SSL certificate expiry alerts — Vigilmon displays your cert's expiry date on the dashboard and status page and alerts you before it lapses. No more surprise cert failures.

4. Heartbeat / cron-job monitoring — If your cron job doesn't ping us on schedule, we alert you. No more silent cron failures destroying your data pipeline at 3 AM.

5. TCP/port monitoring — Monitor raw TCP connectivity on any port, not just HTTP. Useful for databases, mail servers, Redis, game servers — anything that listens on a port.

6. Response content checks — Configure a keyword that must appear in the response body. Case-insensitive matching. If your "Checkout" button disappears from your homepage, you'll know immediately.

7. Configurable check intervals — Choose 1, 5, 15, 30, or 60 minute intervals per monitor depending on how critical the endpoint is. High-traffic APIs get 1-minute checks; staging environments get hourly.

8. 90-day uptime chart — Public status pages now show a rolling 90-day uptime bar chart. Cached for performance, looks great on your status page.

🔔 Alerting

9. Slack (Block Kit format) — Upgraded Slack notifications to Block Kit with color sidebars — red for down, green for recovery. Actionable context instead of raw JSON.

10. Webhook notifications — Send alert payloads to any HTTPS endpoint. Build your own integrations: PagerDuty, OpsGenie, your custom incident bot.

11. Discord alerts — A native Discord webhook channel. Alerts land directly in your #ops channel.

12. Telegram bot — Telegram bot notifications. Send alerts to yourself or a group chat. Popular with our European users.

13. Email alert improvements — Alert subjects now include the monitor name and status. Each email links directly to the incident on your dashboard — one click to the context you need.

14. Alert escalation rules — If a monitor is still down after N minutes, escalate to a secondary contact. No more "was anyone notified?" post-mortems after an incident.

15. Webhook delivery history — Every webhook attempt is logged with status code, response body, and duration. You can debug a failed delivery without any guesswork.

16. Maintenance windows — Schedule planned downtime windows so alerts don't fire while you're deploying. No more 2 AM false alarms during your release.

17. Monthly uptime report emails — Automated monthly summary with uptime % per monitor. Forward to your manager or include in your SLA report.

18. Welcome email — New users get a proper onboarding email with their first steps instead of landing in an empty app.

🖥️ Dashboard UX

19. Dashboard redesign — Summary stats (monitors up/down, incidents today), a monitor grid with at-a-glance status indicators, and a live incident feed.

20. Monitor tags — Tag monitors by project, environment, or team (production, staging, api, frontend). Filter by tag on the dashboard. Scales when you have 50+ monitors.

21. Improved onboarding — First-time users now see a guided empty-state instead of a blank dashboard. We cut time-to-first-monitor by 60%.

🛠️ Developer Tools

22. Personal API tokens — Generate API tokens (prefixed vtk_) from account settings and manage monitors programmatically.

23. REST API — Full /api/v1/monitors REST API — CRUD, status checks, incidents. Documented at vigilmon.online/docs/api.

24. Custom HTTP request headers — Specify request headers per monitor. Useful for bearer tokens, X-Api-Key headers, or bypassing WAF rules on your staging environment.

25. SVG status badges — Embed a live status badge into your README or documentation. Updates in real-time. One line of Markdown.

26. API documentation page — A dedicated /docs/api reference with endpoint tables, example requests, and token instructions.

📈 Marketing & SEO

27. Comparison pages — /compare/vigilmon-vs-pingdom, /compare/vigilmon-vs-uptimerobot, and more. Targeting the "alternative to X" search queries.

28. Technical SEO — Sitemap, robots.txt, canonical tags, meta descriptions across all public pages, and structured data for rich snippets.

29. Dev.to tutorial articles — Published tutorials on monitoring Laravel, Node.js, and Next.js apps with Vigilmon. These drive organic discovery.

30. Directory submissions — Listed on BetaList, Product Hunt upcoming, and several developer tool directories.

What we learned about prioritization

After 30 days and 36+ shipped features, three lessons stick:

1. Monitoring features compound

Each new check type (TCP, heartbeat, content checks) multiplies the number of things users can monitor. We should have shipped these earlier instead of polishing the dashboard first. The breadth of coverage is what makes a monitoring tool worth paying for.

2. Alerting IS the product

Users don't open dashboards when things are fine. They care about: Was I notified? How fast? Was the notification actionable? Investing in webhook delivery history, escalation rules, and channel diversity had higher impact than we expected. The dashboard is a nice-to-have; the alert is the whole point.

3. Docs unlock API adoption

We shipped the REST API and got zero integrations. We shipped the docs page and got three integrations in a week. Documentation is a feature, not a follow-up task.

What's next

Show HN launch — We're preparing our Hacker News post. Watch this space or follow along on Dev.to.
Stripe payments — Paid plans are nearly ready. The free tier (3 monitors, 5-minute checks) will always exist.
Broken link detection — Crawl your site, find dead links before Google does, get a digest report.
Status page customization — Custom domain support and branding for your public status page.

Try Vigilmon

vigilmon.online — free tier, no credit card required. Add your first monitor in under 60 seconds.

If you're also building in public, drop a comment with your project — I'd love to follow along.

Monitor Your Laravel App with Vigilmon

Vigilmon — Sat, 20 Jun 2026 11:29:52 +0000

Your app is down. Your users can't reach it. You find out two hours later — not from a monitoring alert, but from an email that starts with "Hey, is your site broken?"

Sound familiar? Uptime monitoring isn't optional for production apps — it's the difference between catching an outage in seconds and discovering it from a frustrated user. Whether you're running a solo side project or a startup, you need to know the moment something goes wrong.

This tutorial walks you through setting up full uptime monitoring for a Laravel app using Vigilmon — a monitoring tool we built, ironically, with Laravel itself.

What Vigilmon Offers (Free Tier)

Before we dive in, here's what you get on the free plan:

HTTP/HTTPS uptime checks — monitor any URL on intervals as short as 1 minute
SSL certificate expiry monitoring — get alerted before your cert expires and breaks HTTPS
Heartbeat monitoring — verify that your Laravel scheduler (or any cron job) is running on time
Slack, Discord, and email alerts — instant notifications when something goes down
Public status pages — share a live status URL with your users
REST API — create and manage monitors programmatically

No credit card required. Let's get started.

Step 1: Sign Up at vigilmon.online

Head to vigilmon.online and create a free account. The sign-up takes under a minute — just email and password, no billing details needed.

Once you're in, you'll land on your dashboard. It's empty for now, but that won't last long.

Step 2: Add Your First HTTP Monitor

Click "Add Monitor" and select HTTP/HTTPS. Fill in:

Name: something descriptive, like My App – Homepage
URL: your app's URL, e.g. https://myapp.com
Check interval: every 1 or 5 minutes
Expected status code: 200

For Laravel apps with a health check endpoint, use that instead of the homepage — it's a lighter-weight check and more reliable:

URL: https://myapp.com/health
Expected content: "ok"

If you don't have a /health route yet, add one quickly in routes/web.php:

Route::get('/health', function () {
    return response()->json(['status' => 'ok']);
});

Vigilmon can assert on the response body too — so returning {"status":"ok"} lets you configure an expected content match of "ok". If a deploy breaks your app and the health endpoint returns a 500 or an error page, you'll know within minutes.

Hit Save, and Vigilmon starts checking immediately. Your first monitor is live.

Step 3: Add a Heartbeat Monitor for Your Laravel Scheduler

HTTP monitors tell you if your web server is responding. But they won't tell you if your Laravel scheduler has silently stopped running — which is exactly the kind of failure that slips through.

Heartbeat monitoring solves this: Vigilmon gives you a unique URL to ping after each scheduler run. If it doesn't receive a ping within the expected window, it fires an alert.

In your Vigilmon dashboard, click "Add Monitor" → Heartbeat. Configure:

Name: Laravel Scheduler
Expected interval: every 1 minute (or whatever your scheduler runs at)
Grace period: 2–3 minutes (time allowed before declaring it missed)

Vigilmon generates a heartbeat URL like:

https://vigilmon.online/heartbeat/abc123xyz

Now wire that into your Laravel scheduler. The cleanest approach is a dedicated Artisan command:

<?php

namespace App\Console\Commands;

use Illuminate\Console\Command;
use Illuminate\Support\Facades\Http;

class PingVigilmonHeartbeat extends Command
{
    protected $signature = 'vigilmon:heartbeat';
    protected $description = 'Ping Vigilmon heartbeat to confirm scheduler is running';

    public function handle(): void
    {
        Http::get(config('services.vigilmon.heartbeat_url'));
    }
}

Add the URL to your config/services.php:

'vigilmon' => [
    'heartbeat_url' => env('VIGILMON_HEARTBEAT_URL'),
],

And in your .env:

VIGILMON_HEARTBEAT_URL=https://vigilmon.online/heartbeat/abc123xyz

Finally, register it in routes/console.php (Laravel 11+) to run every minute, after your other scheduled jobs:

use Illuminate\Support\Facades\Schedule;

Schedule::command('vigilmon:heartbeat')->everyMinute();

Or in app/Console/Kernel.php for older Laravel versions:

protected function schedule(Schedule $schedule): void
{
    // ... your other scheduled tasks ...
    $schedule->command('vigilmon:heartbeat')->everyMinute();
}

Now every time php artisan schedule:run fires and completes, Vigilmon gets a ping. If your scheduler stops — because of a server issue, a misconfigured cron job, or a deploy that never restarted the container — Vigilmon will notice within 2–3 minutes and alert you.

Step 4: Set Up Slack and Email Notifications

In your Vigilmon dashboard, go to Settings → Notifications. You can configure:

Email alerts: your email is already set from sign-up. You'll get a message the moment a monitor goes down and another when it recovers.

Slack: paste your Slack webhook URL. Vigilmon posts to your chosen channel immediately on state change.

Discord: same flow — paste your Discord webhook URL under the Discord integration.

You can attach notification channels per-monitor, so you can route your scheduler heartbeat to #ops and your public homepage monitor to #alerts.

Step 5: Share Your Status Page with Users

Every Vigilmon account gets a public status page. Go to Status Page in the dashboard, choose which monitors to display publicly, and enable it.

You'll get a URL like:

https://status.vigilmon.online/yourapp

Share this with your users — add a link in your app footer, your support docs, or your README. When your app is down, users can check the status page themselves instead of flooding your inbox with "is it down?" emails.

Bonus: Create Monitors via the REST API

If you want to automate monitor creation as part of your deploy pipeline, Vigilmon has a REST API. Here's how to create an HTTP monitor with curl:

curl -X POST https://vigilmon.online/api/v1/monitors \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "My App – API",
    "type": "http",
    "url": "https://myapp.com/api/health",
    "interval": 60,
    "expectedStatusCode": 200,
    "expectedContent": "ok"
  }'

Your API token lives under Settings → API. This is handy for staging environments — create a monitor when a preview deploy spins up, delete it when the PR is merged.

Why We Built Vigilmon

We built Vigilmon because we kept running into the same problem with our own Laravel projects: monitoring was either expensive (services charging $30+/month for basic uptime checks) or painful to set up (self-hosted solutions that need their own infrastructure to keep running).

Since we were already deep in the Laravel ecosystem, we built what we actually wanted — something simple, fast to set up, with a free tier that's genuinely useful for real projects. Vigilmon itself runs on Laravel and MySQL, deployed on a bare Linux VPS. We monitor it with itself.

If you build things with Laravel, we built this for you. Sign up free at vigilmon.online — no credit card, no 14-day trial cliff. Just monitoring that works.

Have questions or feedback? Drop us a note at hello@vigilmon.online.