DEV Community: Vigilmon

How to Monitor Your RabbitMQ Server with Vigilmon

Vigilmon — Thu, 06 Aug 2026 01:14:39 +0000

How to Monitor Your RabbitMQ Server with Vigilmon

RabbitMQ is a critical piece of infrastructure — it brokers messages between your services, handles background job queues, and keeps your microservices decoupled. When RabbitMQ goes down or degrades, the blast radius can be enormous: jobs stop processing, events get dropped, and your entire async processing pipeline freezes.

This guide shows you how to monitor RabbitMQ with Vigilmon using RabbitMQ's built-in management API.

RabbitMQ Management API — Your Best Monitoring Tool

The RabbitMQ Management Plugin ships with every RabbitMQ installation and provides a comprehensive REST API for monitoring:

# Enable management plugin (if not already enabled)
rabbitmq-plugins enable rabbitmq_management

Now you have access to:

GET /api/overview — Node overview (connections, queues, messages)
GET /api/nodes — Detailed node health
GET /api/queues — Queue depths and consumer counts
GET /api/healthchecks/node — Built-in health check

Using the Built-in Health Check

RabbitMQ 3.9+ includes a native health check endpoint:

curl -u guest:guest http://localhost:15672/api/healthchecks/node
# Returns: {"status":"ok"}

Important: The management API runs on port 15672 by default. Never expose this publicly. Proxy it through your application.

Creating an Application Health Proxy

Node.js / Express

const axios = require('axios');

const RABBITMQ_MGMT = process.env.RABBITMQ_MGMT_URL || 'http://localhost:15672';
const RABBITMQ_USER = process.env.RABBITMQ_USER;
const RABBITMQ_PASS = process.env.RABBITMQ_PASS;

app.get('/health/rabbitmq', async (req, res) => {
  try {
    const [nodeHealth, overview] = await Promise.all([
      axios.get(`${RABBITMQ_MGMT}/api/healthchecks/node`, {
        auth: { username: RABBITMQ_USER, password: RABBITMQ_PASS },
        timeout: 5000
      }),
      axios.get(`${RABBITMQ_MGMT}/api/overview`, {
        auth: { username: RABBITMQ_USER, password: RABBITMQ_PASS },
        timeout: 5000
      })
    ]);

    const stats = overview.data.queue_totals;
    const isHealthy = nodeHealth.data.status === 'ok';

    return res.status(isHealthy ? 200 : 503).json({
      status: nodeHealth.data.status,
      messages_ready: stats.messages_ready,
      messages_unacked: stats.messages_unacknowledged,
      consumers: overview.data.object_totals.consumers
    });
  } catch (err) {
    return res.status(503).json({ status: 'error', error: err.message });
  }
});

Python / Flask

import requests
from flask import Flask, jsonify
import os

app = Flask(__name__)

RABBITMQ_MGMT = os.environ.get('RABBITMQ_MGMT_URL', 'http://localhost:15672')
AUTH = (os.environ['RABBITMQ_USER'], os.environ['RABBITMQ_PASS'])

@app.route('/health/rabbitmq')
def health_rabbitmq():
    try:
        health = requests.get(
            f'{RABBITMQ_MGMT}/api/healthchecks/node',
            auth=AUTH, timeout=5
        )
        overview = requests.get(
            f'{RABBITMQ_MGMT}/api/overview',
            auth=AUTH, timeout=5
        )

        stats = overview.json().get('queue_totals', {})
        is_healthy = health.json().get('status') == 'ok'

        return jsonify({
            'status': 'ok' if is_healthy else 'error',
            'messages_ready': stats.get('messages_ready', 0),
            'messages_unacked': stats.get('messages_unacknowledged', 0)
        }), 200 if is_healthy else 503
    except Exception as e:
        return jsonify({'status': 'error', 'error': str(e)}), 503

Vigilmon Configuration for RabbitMQ

Sign up at vigilmon.online
Add HTTP Monitor → https://yourapp.com/health/rabbitmq
Check interval: 1 minute
Expected status: 200
Response time alert: 2000ms

TCP Port Monitor (Secondary)

RabbitMQ AMQP port is 5672. Add a TCP monitor:

Host: your RabbitMQ server
Port: 5672
This catches RabbitMQ process crashes when your app might also be down

Advanced: Monitor Queue Depths

Queue depth explosions are a common failure mode — jobs queue up faster than workers process them:

app.get('/health/rabbitmq/queues', async (req, res) => {
  try {
    const response = await axios.get(
      `${RABBITMQ_MGMT}/api/queues/%2F`,  // %2F = default vhost
      { auth: { username: RABBITMQ_USER, password: RABBITMQ_PASS }, timeout: 5000 }
    );

    const queues = response.data.map(q => ({
      name: q.name,
      messages: q.messages,
      consumers: q.consumers,
      state: q.state
    }));

    // Alert if any queue exceeds threshold with 0 consumers
    const backloggedQueues = queues.filter(
      q => q.messages > 1000 && q.consumers === 0
    );

    const isHealthy = backloggedQueues.length === 0;

    return res.status(isHealthy ? 200 : 503).json({
      status: isHealthy ? 'ok' : 'degraded',
      queues,
      backlogged: backloggedQueues
    });
  } catch (err) {
    return res.status(503).json({ status: 'error', error: err.message });
  }
});

Common RabbitMQ Failure Modes

Memory Alarm

When RabbitMQ memory usage exceeds the threshold (default: 40% of system RAM), it blocks all producers:

# Check memory alarm
curl -u user:pass http://localhost:15672/api/nodes | jq '.[].mem_alarm'
# false = healthy, true = alarm active

Disk Alarm

When disk space falls below the free disk limit, RabbitMQ blocks all producers:

# Check disk alarm
curl -u user:pass http://localhost:15672/api/nodes | jq '.[].disk_free_alarm'

Dead Letter Queue Build-up

Messages rejected by consumers accumulate in dead letter queues. Monitor DLQ size:

const dlqDepth = queues.find(q => q.name.includes('dead-letter'))?.messages || 0;
if (dlqDepth > 100) {
  // Alert: messages are failing processing
}

Split Brain (Mirrored Queues)

In clustered RabbitMQ, network partitions can cause split-brain. Check cluster health:

curl -u user:pass http://localhost:15672/api/nodes | jq '.[].partitions'
# Empty array = healthy, non-empty = partition detected

Alerting Matrix

Scenario	Severity	Response
TCP 5672 not responding	P0 Critical	RabbitMQ process down
Health check returns 503	P1 Critical	Node alarm or crash
Queue depth >10000 with 0 consumers	P1 Critical	Workers crashed
DLQ depth >1000	P2 Warning	Review rejected messages
Memory alarm active	P1 Critical	Scale up or reduce load

Production Checklist

[ ] RabbitMQ Management Plugin enabled
[ ] /health/rabbitmq application proxy endpoint
[ ] TCP monitor on port 5672
[ ] Queue depth monitor with consumer count check
[ ] Dead letter queue depth alert
[ ] Response time alert at 2000ms
[ ] Memory and disk alarm monitoring

Start monitoring RabbitMQ for free with Vigilmon →

Vigilmon is an uptime monitoring platform for developers. Free tier includes 10 monitors with 1-minute checks from multiple global regions.

How to Monitor Your Elasticsearch Cluster with Vigilmon

Vigilmon — Thu, 06 Aug 2026 01:13:53 +0000

How to Monitor Your Elasticsearch Cluster with Vigilmon

Elasticsearch is powerful but notoriously temperamental. Cluster health can degrade from green to red in minutes — shards go unassigned, nodes leave the cluster, memory fills up and the JVM garbage collector starts thrashing. When Elasticsearch goes down, your search functionality disappears and any service depending on it breaks.

This guide shows how to monitor Elasticsearch with Vigilmon using the built-in cluster health API.

Elasticsearch's Built-in Health API

One of Elasticsearch's best features for monitoring: it ships with a comprehensive health API that Vigilmon can poll directly.

# Cluster health
curl -X GET 'https://localhost:9200/_cluster/health?pretty'

Response:

{
  "cluster_name": "my-cluster",
  "status": "green",
  "timed_out": false,
  "number_of_nodes": 3,
  "number_of_data_nodes": 3,
  "active_primary_shards": 15,
  "active_shards": 30,
  "relocating_shards": 0,
  "initializing_shards": 0,
  "unassigned_shards": 0
}

Cluster status meanings:

green: All primary and replica shards are assigned
yellow: All primary shards assigned, but some replicas unassigned (cluster is functional, but not fully redundant)
red: Some primary shards unassigned (search and indexing failures)

Setting Up a Health Proxy Endpoint

If your Elasticsearch isn't publicly accessible (it shouldn't be!), expose it through your application:

Node.js / Express

const axios = require('axios');

app.get('/health/elasticsearch', async (req, res) => {
  try {
    const response = await axios.get(
      `${process.env.ES_URL}/_cluster/health`,
      {
        auth: {
          username: process.env.ES_USERNAME,
          password: process.env.ES_PASSWORD
        },
        timeout: 5000
      }
    );

    const health = response.data;
    const isHealthy = health.status === 'green' || health.status === 'yellow';

    return res.status(isHealthy ? 200 : 503).json({
      status: health.status,
      nodes: health.number_of_nodes,
      unassigned_shards: health.unassigned_shards,
      active_shards: health.active_shards
    });
  } catch (err) {
    return res.status(503).json({ status: 'error', error: err.message });
  }
});

Python / FastAPI

import httpx
from fastapi import FastAPI
from fastapi.responses import JSONResponse
import os

app = FastAPI()

@app.get('/health/elasticsearch')
async def health_elasticsearch():
    try:
        async with httpx.AsyncClient() as client:
            response = await client.get(
                f"{os.environ['ES_URL']}/_cluster/health",
                auth=(os.environ['ES_USERNAME'], os.environ['ES_PASSWORD']),
                timeout=5.0
            )
            health = response.json()

            is_healthy = health['status'] in ('green', 'yellow')
            status_code = 200 if is_healthy else 503

            return JSONResponse(
                content={
                    'status': health['status'],
                    'nodes': health['number_of_nodes'],
                    'unassigned_shards': health['unassigned_shards']
                },
                status_code=status_code
            )
    except Exception as e:
        return JSONResponse(
            content={'status': 'error', 'error': str(e)},
            status_code=503
        )

Vigilmon Configuration

Sign up at vigilmon.online
Add HTTP Monitor → https://yourapp.com/health/elasticsearch
Check interval: 1 minute
Expected status: 200
Alert threshold: 1 failure (Elasticsearch degradation is serious)

Alert on Yellow vs Red

Consider creating two monitors:

Green+Yellow check (returns 200 for green/yellow, 503 for red): Catches complete cluster failure
Green-only check (returns 503 for yellow): Catches replica issues before they become full outages

Common Elasticsearch Failure Modes

Unassigned Shards (Yellow)

This usually means:

A node left the cluster and its shards are waiting to be re-assigned
Disk space exceeded the watermark threshold
Not enough nodes to satisfy replica requirements

# Find unassigned shards
curl -X GET 'localhost:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason&s=state'

JVM Heap Pressure (Slowdown before crash)

When JVM heap fills up:

GC runs more frequently (latency spikes)
Circuit breakers trip (rejections start)
Elasticsearch becomes non-responsive
OOM kill

Vigilmon catches step 3-4 as a 503 or timeout.

# Check JVM heap usage
curl -X GET 'localhost:9200/_nodes/stats/jvm?pretty' | grep heap_used_percent

Index Too Large

When a single index gets too large, shard sizes grow beyond optimal (>50GB). Performance degrades before you hit a hard failure.

Vigilmon catches this through response time monitoring — set an alert at 3000ms for your search health endpoint.

Advanced Health Endpoints

// Check specific index health
app.get('/health/elasticsearch/search-index', async (req, res) => {
  try {
    const response = await axios.get(
      `${process.env.ES_URL}/_cat/indices/products?format=json`,
      { auth: { username: ES_USER, password: ES_PASS }, timeout: 5000 }
    );

    const index = response.data[0];
    if (!index) {
      return res.status(503).json({ status: 'error', reason: 'index not found' });
    }

    const isHealthy = index.health !== 'red';
    return res.status(isHealthy ? 200 : 503).json({
      status: index.health,
      docs_count: index['docs.count'],
      store_size: index['store.size']
    });
  } catch (err) {
    return res.status(503).json({ status: 'error', error: err.message });
  }
});

Monitoring Checklist for Elasticsearch

[ ] Cluster health endpoint exposed via app proxy
[ ] Vigilmon HTTP monitor at 1-minute intervals
[ ] Alert on cluster status = red (immediate)
[ ] Alert on cluster status = yellow (warning)
[ ] Response time alert at 3000ms
[ ] Separate monitor for critical indices
[ ] JVM heap monitoring via CloudWatch/Prometheus

Response Time Thresholds

Response Time	Elasticsearch State	Action
<100ms	Healthy	None
100-500ms	Under load	Monitor closely
500-2000ms	Degraded	Check JVM heap and slow logs
>2000ms	Critical	Likely JVM pressure or disk watermark

Monitor your Elasticsearch cluster for free with Vigilmon →

Vigilmon is an uptime monitoring platform for developers. Free tier includes 10 monitors with 1-minute checks from multiple global regions.

How to Monitor AWS Lambda Functions with Vigilmon

Vigilmon — Thu, 06 Aug 2026 01:13:07 +0000

How to Monitor AWS Lambda Functions with Vigilmon

AWS Lambda functions are invisible by default. They execute in response to events, leave no persistent processes to watch, and fail in ways that don't surface until downstream systems start breaking. Cold starts add latency spikes. Concurrency limits cause silent throttling. Memory limits trigger silent OOM kills.

This guide covers how to monitor Lambda functions using Vigilmon — both through Lambda URLs/API Gateway endpoints and through custom synthetic health checks.

The Challenge of Serverless Monitoring

Lambda monitoring is fundamentally different from monitoring a running server:

No persistent process to check TCP connections on
Cold starts cause response time spikes that look like outages
Silent throttling — Lambda returns 429 when concurrency limits hit, often without alerting anyone
Regional failures — Lambda in one AWS region can fail while others work fine
Downstream cascades — a Lambda failure in an event-driven architecture silently breaks other services

Approach 1: Monitor via Lambda Function URLs

Lambda Function URLs (introduced 2022) give your Lambda a permanent HTTPS endpoint. This is the cleanest way to monitor Lambda with Vigilmon.

Create a Health Check Lambda

// health-check/index.mjs
export const handler = async (event) => {
  const checks = {};
  let healthy = true;

  // Check DynamoDB connectivity
  try {
    const { DynamoDBClient, DescribeTableCommand } = await import('@aws-sdk/client-dynamodb');
    const client = new DynamoDBClient({ region: process.env.AWS_REGION });
    await client.send(new DescribeTableCommand({ TableName: process.env.TABLE_NAME }));
    checks.dynamodb = 'ok';
  } catch (err) {
    checks.dynamodb = `error: ${err.message}`;
    healthy = false;
  }

  // Check SQS queue accessibility
  try {
    const { SQSClient, GetQueueAttributesCommand } = await import('@aws-sdk/client-sqs');
    const client = new SQSClient({ region: process.env.AWS_REGION });
    await client.send(new GetQueueAttributesCommand({
      QueueUrl: process.env.QUEUE_URL,
      AttributeNames: ['ApproximateNumberOfMessages']
    }));
    checks.sqs = 'ok';
  } catch (err) {
    checks.sqs = `error: ${err.message}`;
    healthy = false;
  }

  return {
    statusCode: healthy ? 200 : 503,
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      status: healthy ? 'ok' : 'degraded',
      timestamp: new Date().toISOString(),
      checks
    })
  };
};

Deploy with Function URL

# Create the Lambda function
aws lambda create-function \
  --function-name vigilmon-health-check \
  --runtime nodejs20.x \
  --role arn:aws:iam::YOUR_ACCOUNT:role/lambda-health-role \
  --handler index.handler \
  --zip-file fileb://health-check.zip

# Add a Function URL with no auth (public health endpoint)
aws lambda create-function-url-config \
  --function-name vigilmon-health-check \
  --auth-type NONE

This gives you a URL like:
https://abc123.lambda-url.us-east-1.on.aws/

Point Vigilmon at this URL.

Approach 2: Monitor via API Gateway

If your Lambda runs behind API Gateway:

// app.js (with aws-serverless-express or similar)
const express = require('express');
const app = express();

app.get('/health', (req, res) => {
  // Check Lambda memory usage
  const memUsed = process.memoryUsage();
  const checks = {
    process: 'ok',
    memory_mb: Math.round(memUsed.heapUsed / 1024 / 1024)
  };

  res.json({ status: 'ok', lambda: 'healthy', ...checks });
});

Monitor https://api.yourdomain.com/health in Vigilmon.

Approach 3: CloudWatch → Vigilmon Webhook

For Lambda functions not exposed via HTTP, route CloudWatch alarms to Vigilmon via webhook:

Create CloudWatch alarm for Lambda errors:

aws cloudwatch put-metric-alarm \
  --alarm-name my-lambda-errors \
  --namespace AWS/Lambda \
  --metric-name Errors \
  --dimensions Name=FunctionName,Value=my-function \
  --statistic Sum \
  --period 60 \
  --threshold 1 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1

Route the alarm to an SNS topic → Lambda → Vigilmon webhook

Critical Lambda Metrics to Monitor

Metric	What it means	Alert threshold
Errors	Function threw an exception	>0 per minute
Throttles	Concurrency limit hit	>0 per minute
Duration	Execution time	>80% of timeout
ConcurrentExecutions	Simultaneous invocations	>80% of reserved concurrency
IteratorAge	SQS/Kinesis event lag	>30 seconds

Vigilmon Configuration for Lambda

Sign up at vigilmon.online
Add HTTP Monitor → your Lambda URL or API Gateway health endpoint
Check interval: 1 minute
Expected status: 200
Response time alert: 5000ms (account for cold start latency)
Multi-region: Vigilmon checks from multiple AWS regions — this is critical for Lambda since region-specific failures are common

Handling Cold Starts in Monitoring

Lambda cold starts can take 500ms-3000ms. To avoid false alerts:

Set Vigilmon's response time alert at 5000ms (not 1000ms)
Use Lambda Provisioned Concurrency for critical functions to eliminate cold starts
Configure Vigilmon's alert policy to require 2 consecutive failures before alerting

Synthetic Monitoring for Event-Driven Lambdas

For Lambdas triggered by SQS/EventBridge (not directly by HTTP), create a synthetic test:

// synthetic-health-check/index.mjs
import { SQSClient, SendMessageCommand, ReceiveMessageCommand, DeleteMessageCommand } from '@aws-sdk/client-sqs';

export const handler = async () => {
  const sqs = new SQSClient({ region: process.env.AWS_REGION });
  const testId = `health-${Date.now()}`;

  // Send a test message to trigger the Lambda
  await sqs.send(new SendMessageCommand({
    QueueUrl: process.env.TEST_QUEUE_URL,
    MessageBody: JSON.stringify({ type: 'health_check', id: testId }),
    MessageAttributes: { 'test': { DataType: 'String', StringValue: 'true' } }
  }));

  // Wait 10 seconds and check DynamoDB for the processed result
  await new Promise(r => setTimeout(r, 10000));

  // Verify processing completed
  // ... check DynamoDB for the testId ...

  return { statusCode: 200, body: 'ok' };
};

Run this synthetic check on a schedule (EventBridge rule) and expose its result via a health endpoint.

Production Checklist

[ ] Lambda Function URL or API Gateway health endpoint created
[ ] Health check verifies downstream dependencies (DynamoDB, SQS, etc.)
[ ] Vigilmon HTTP monitor pointed at the health endpoint
[ ] Response time alert at 5000ms (cold start tolerance)
[ ] CloudWatch alarm for Lambda Errors and Throttles
[ ] Alert 2+ consecutive failures before paging on-call
[ ] Synthetic health check for event-driven Lambdas

Start monitoring your Lambda functions for free →

Vigilmon is an uptime monitoring platform for developers. Free tier includes 10 monitors with 1-minute checks from multiple global regions.

Best StatusCake Alternatives in 2026

Vigilmon — Thu, 06 Aug 2026 01:12:21 +0000

Best StatusCake Alternatives in 2026

StatusCake has been a staple in the uptime monitoring space for over a decade. But in 2026, the monitoring landscape has matured significantly — and depending on your needs, there may be better options available.

Whether you're frustrated with StatusCake's pricing, its aging UI, or looking for better developer tooling, this guide covers the best StatusCake alternatives in 2026.

Why Developers Look for StatusCake Alternatives

Pricing complexity: StatusCake's free tier is limited to 10 monitors and 5-minute intervals — not enough for modern production setups
UI/UX: The interface feels dated compared to newer entrants
API limitations: Less flexible API compared to developer-first alternatives
Alert customization: Limited alerting rules compared to dedicated observability tools
Check frequency: 5-minute minimum on free tier; 1-minute checks require paid plans

Top StatusCake Alternatives in 2026

1. Vigilmon — Best for Developer Teams

Vigilmon is built specifically for development teams who want reliable uptime monitoring without the enterprise bloat.

Key features:

1-minute check intervals on the free tier (StatusCake requires paid for this)
Multi-region consensus monitoring — eliminates false positives
HTTP, TCP, and SSL monitoring in one platform
Webhook alerts compatible with Slack, PagerDuty, and custom integrations
Status pages for customer-facing communication
Simple, modern UI designed for developers

Pricing: Free tier with 10 monitors. Paid plans for larger teams.

Best for: Startups, SaaS products, and development teams who need fast, reliable monitoring without complexity.

2. UptimeRobot — Best Free Tier

UptimeRobot is the most popular StatusCake alternative with a generous free tier:

50 monitors on the free tier
5-minute check intervals (free) / 1-minute (paid)
HTTP, keyword, ping, and port monitoring
5 alert contacts on free tier

Pricing: Free (50 monitors, 5-min) | $7/month (50 monitors, 1-min) | $20/month (100 monitors)

Best for: Personal projects and teams that need many monitors at low cost.

Limitation: Single-region checking on free tier — prone to false positives.

3. Better Stack (formerly Logtail) — Best All-in-One

Better Stack combines uptime monitoring with log management:

10 second minimum check intervals
HTTP, TCP, ping, DNS, SMTP monitoring
Incident management and on-call scheduling
Log aggregation included
Beautiful status pages

Pricing: Free tier (10 monitors, 3-min intervals) | $24/month (unlimited monitors, 30s intervals)

Best for: Teams that also need log management alongside uptime monitoring.

Limitation: Higher price point once you need advanced features.

4. Freshping — Best for Non-Technical Users

Freshping by Freshworks offers an accessible interface:

50 free monitors on the free plan
1-minute check intervals (free!)
Check from 10+ global locations
Integrates with Freshdesk for customer support workflows

Pricing: Free (50 monitors) | $15/month (200 monitors with advanced features)

Best for: Customer success teams and non-technical users who need uptime visibility.

5. HetrixTools — Best for Infrastructure Monitoring

HetrixTools focuses on server and network monitoring:

Uptime monitors + blacklist monitoring + server monitoring
1-minute intervals on all plans
Server resource monitoring (CPU, RAM, disk) via agent
Cheap pricing for the feature set

Pricing: $5.95/month (15 monitors) | $15.95/month (50 monitors)

Best for: Hosting providers and teams managing multiple servers.

6. Checkly — Best for API and E2E Monitoring

Checkly specializes in synthetic API monitoring:

Monitor API endpoints with full request/response assertions
Playwright-powered browser checks for E2E flows
Multi-location checks from 20+ regions
Alert on response body content, headers, and status codes

Pricing: Free (50,000 check runs/month) | $29/month (unlimited monitors)

Best for: Teams with complex API contracts and critical user flows to monitor.

StatusCake vs Alternatives: Feature Comparison

Feature	StatusCake Free	Vigilmon Free	UptimeRobot Free	Better Stack Free
Monitors	10	10	50	10
Check interval	5 min	1 min	5 min	3 min
Multi-region	No	Yes	No	Yes
SSL monitoring	Yes	Yes	No	Yes
Status pages	1	1	1	1
API access	Limited	Yes	Yes	Yes

How to Choose

Choose Vigilmon if: You want 1-minute checks and multi-region consensus on the free tier, with a clean developer-focused interface.

Choose UptimeRobot if: You need many monitors (50) and 5-minute intervals are acceptable.

Choose Better Stack if: You need log management plus uptime monitoring in one platform.

Choose Checkly if: You have critical API flows or user journeys that need synthetic monitoring beyond simple uptime.

Choose Freshping if: You want a generous free tier with 1-minute intervals and an accessible UI.

Migrating from StatusCake

Export your StatusCake monitor list (Settings → Import/Export)
Sign up for your chosen alternative
Import monitors or recreate them (most have CSV import)
Update your alerting contacts (email, Slack, PagerDuty)
Verify alerts work with a test takedown
Cancel StatusCake after a 1-week overlap period

Try Vigilmon — free, 1-minute checks, multi-region →

Vigilmon is an uptime monitoring platform for developers. Free tier includes 10 monitors with 1-minute checks from multiple global regions.

How to Monitor Your Ruby on Rails Application with Vigilmon

Vigilmon — Thu, 06 Aug 2026 01:11:35 +0000

How to Monitor Your Ruby on Rails Application with Vigilmon

Ruby on Rails is an opinionated, batteries-included framework — and that includes health monitoring. Rails 7.1+ ships with built-in health check support. Combined with Vigilmon, you can have production-grade uptime monitoring running in under 15 minutes.

Rails 7.1+ Built-in Health Check

Rails 7.1 introduced a /up endpoint out of the box. It returns:

200 OK when the application is healthy
500 when it can't connect to the database or other dependencies

This endpoint is already in your config/routes.rb:

Rails.application.routes.draw do
  get "up" => "rails/health#show", as: :rails_health_check
end

Just point Vigilmon at https://yourapp.com/up and you're done for the basics.

Custom Health Controller (Rails 6 / Enhanced Rails 7)

For more granular health checks:

# app/controllers/health_controller.rb
class HealthController < ApplicationController
  skip_before_action :authenticate_user!, only: [:show, :database, :cache, :sidekiq]

  def show
    checks = {
      database: check_database,
      cache: check_cache,
      sidekiq: check_sidekiq
    }

    all_ok = checks.values.all? { |v| v == 'ok' }

    render json: { status: all_ok ? 'ok' : 'degraded', checks: checks },
           status: all_ok ? :ok : :service_unavailable
  end

  def database
    ActiveRecord::Base.connection.execute('SELECT 1')
    render json: { status: 'ok', db: 'connected' }
  rescue => e
    render json: { status: 'error', db: e.message }, status: :service_unavailable
  end

  def cache
    Rails.cache.write('health_check', 'ok', expires_in: 30.seconds)
    value = Rails.cache.read('health_check')
    raise 'Cache read failed' unless value == 'ok'
    render json: { status: 'ok', cache: 'connected' }
  rescue => e
    render json: { status: 'error', cache: e.message }, status: :service_unavailable
  end

  def sidekiq
    stats = Sidekiq::Stats.new
    enqueued = stats.enqueued
    workers = Sidekiq::Workers.new.count

    if workers == 0 && enqueued > 100
      render json: { status: 'warning', workers: 0, enqueued: enqueued }, 
             status: :service_unavailable
    else
      render json: { status: 'ok', workers: workers, enqueued: enqueued }
    end
  rescue => e
    render json: { status: 'error', sidekiq: e.message }, status: :service_unavailable
  end

  private

  def check_database
    ActiveRecord::Base.connection.execute('SELECT 1')
    'ok'
  rescue
    'error'
  end

  def check_cache
    Rails.cache.write('hc', '1', expires_in: 10)
    Rails.cache.read('hc') == '1' ? 'ok' : 'error'
  rescue
    'error'
  end

  def check_sidekiq
    Sidekiq::Workers.new.count >= 0 ? 'ok' : 'error'
  rescue
    'unavailable'
  end
end

# config/routes.rb
Rails.application.routes.draw do
  namespace :health do
    get '/', to: 'health#show'
    get '/db', to: 'health#database'
    get '/cache', to: 'health#cache'
    get '/sidekiq', to: 'health#sidekiq'
  end
end

Setting Up Vigilmon for Rails

Sign up at vigilmon.online (free tier)
Add HTTP Monitor → https://yourapp.com/up (or /health/)
Check interval: 1 minute
Expected status: 200
Response time alert: 1500ms (Rails cold starts can be slow)

Monitoring Sidekiq Background Jobs

Sidekiq failures are invisible to users until queues back up. The /health/sidekiq endpoint above handles this — but you can also use the Sidekiq Web UI's status endpoint:

# config/routes.rb
require 'sidekiq/web'
mount Sidekiq::Web => '/sidekiq'  # Protect this in production!

Alternatively, use the sidekiq_alive gem:

# Gemfile
gem 'sidekiq_alive'

This adds /sidekiq/alive that returns 200 when Sidekiq workers are running.

Rails-Specific Failure Modes

Puma Worker Crashes

When Puma workers OOM-crash, requests start timing out. Vigilmon's response time monitoring catches this — set an alert at 2000ms for production Rails apps.

Database Connection Pool Exhaustion

ActiveRecord has a connection pool (default: 5). When your pool exhausts under load:

# config/database.yml
production:
  pool: <%= ENV.fetch('RAILS_MAX_THREADS') { 5 } %>
  checkout_timeout: 5  # Raises ActiveRecord::ConnectionTimeoutError after 5s

Your health endpoint will return 503 when this happens.

Asset Precompile Failures (Post-Deploy)

After a bad deploy, CSS/JS assets may 404. Add a Vigilmon monitor for your main JS bundle:

https://yourapp.com/assets/application-abc123.js

This catches asset pipeline failures immediately after deploy.

Multi-Environment Setup

# Production monitors (1-minute checks, page on failure)
https://yourapp.com/up
https://yourapp.com/health/db
https://yourapp.com/health/sidekiq

# Staging monitors (5-minute checks, Slack only)
https://staging.yourapp.com/up

SSL and Domain Monitoring

Rails apps with Let's Encrypt certificates need SSL expiry monitoring. Vigilmon checks your certificate expiry and alerts 30 days before it expires — before auto-renewal issues leave your users with browser certificate errors.

Production Checklist

[ ] Rails 7.1 /up endpoint or custom HealthController
[ ] Database health check with SELECT 1
[ ] Cache health check (Redis/Memcache)
[ ] Sidekiq health check (if using background jobs)
[ ] Vigilmon HTTP monitors for each endpoint
[ ] Response time alert at 2000ms
[ ] SSL certificate monitoring
[ ] Maintenance windows for deployments and migrations

Start monitoring your Rails app for free →

Vigilmon is an uptime monitoring platform for developers. Free tier includes 10 monitors with 1-minute checks from multiple global regions.

How to Monitor Your Django Application with Vigilmon

Vigilmon — Thu, 06 Aug 2026 01:10:49 +0000

How to Monitor Your Django Application with Vigilmon

Django powers everything from Instagram to Disqus to Pinterest. It's battle-tested and reliable — but production Django apps still go down. Database connections fail, Celery workers stop processing, Redis caches become unavailable, and gunicorn workers start dying. Without monitoring, you find out from your users.

This guide shows you how to add production-grade monitoring to your Django application using Vigilmon — a free uptime monitoring platform for developers.

Installing django-health-check (Recommended)

The fastest way to add health endpoints to Django is django-health-check:

pip install django-health-check

Add to INSTALLED_APPS:

# settings.py
INSTALLED_APPS = [
    # ... existing apps
    'health_check',
    'health_check.db',                   # Checks the default database
    'health_check.cache',                # Checks the cache backend
    'health_check.storage',              # Checks file storage
    'health_check.contrib.celery',       # Checks Celery (if used)
    'health_check.contrib.redis',        # Checks Redis (if used)
]

Add to urls.py:

from django.urls import include, path

urlpatterns = [
    # ... existing URLs
    path('health/', include('health_check.urls')),
]

Now GET /health/ returns:

200 OK with all checks passing
500 if any check fails

{
  "DatabaseBackend": "working",
  "DefaultFileStorageHealthCheck": "working",
  "CacheBackend": "working",
  "CeleryHealthCheck": "working",
  "RedisHealthCheck": "working"
}

Custom Health Endpoint (Manual Approach)

If you prefer a lightweight custom endpoint:

# views.py
from django.http import JsonResponse
from django.db import connections
from django.db.utils import OperationalError
from django.core.cache import cache
import logging

logger = logging.getLogger(__name__)

def health_check(request):
    checks = {}
    http_status = 200

    # Check database
    try:
        db_conn = connections['default']
        db_conn.cursor().execute('SELECT 1')
        checks['db'] = 'ok'
    except OperationalError as e:
        logger.error(f'DB health check failed: {e}')
        checks['db'] = 'error'
        http_status = 503

    # Check cache (Redis/Memcache)
    try:
        cache.set('health_check', 'ok', timeout=10)
        value = cache.get('health_check')
        if value == 'ok':
            checks['cache'] = 'ok'
        else:
            raise Exception('Cache get/set mismatch')
    except Exception as e:
        logger.error(f'Cache health check failed: {e}')
        checks['cache'] = 'error'
        http_status = 503

    checks['status'] = 'ok' if http_status == 200 else 'degraded'
    return JsonResponse(checks, status=http_status)

# urls.py
from . import views

urlpatterns = [
    path('health/', views.health_check, name='health_check'),
]

Setting Up Vigilmon for Django

Sign up at vigilmon.online
Add HTTP Monitor → https://yourapp.com/health/
Check interval: 1 minute
Expected status: 200
Configure alerts: Slack, email, or PagerDuty

Vigilmon checks from multiple global regions — you won't get false alerts from regional network blips.

Monitoring Django + Celery

Celery worker failures are particularly sneaky — your app responds normally but background tasks queue up silently. Monitor Celery health with:

# views.py
from celery.app.control import Inspect
from django.http import JsonResponse

def celery_health(request):
    try:
        i = Inspect(timeout=3)
        active_workers = i.active()
        if active_workers is None:
            return JsonResponse(
                {'status': 'error', 'celery': 'no_workers'},
                status=503
            )
        worker_count = len(active_workers)
        return JsonResponse({
            'status': 'ok',
            'celery': 'healthy',
            'workers': worker_count
        })
    except Exception as e:
        return JsonResponse(
            {'status': 'error', 'celery': str(e)},
            status=503
        )

Add this as a separate Vigilmon monitor: https://yourapp.com/health/celery/

Monitoring Gunicorn Workers

Gunicorn worker crashes are another silent failure mode. When workers die faster than Gunicorn restarts them, requests start timing out.

Vigilmon's response time monitoring catches this — if your Django app usually responds in 100ms but starts taking 5+ seconds, your worker count is likely insufficient.

Set a response time alert at 1000ms in Vigilmon for your health endpoint.

Django-Specific Monitoring Configuration

# settings.py — exclude health check from auth middleware
HEALTH_CHECK_EXEMPT_PATHS = ['/health/']

# If using django-allauth or custom auth
LOGIN_URL = '/accounts/login/'
LOGIN_EXEMPT_URLS = [
    r'^health/$',  # Allow unauthenticated health checks
]

Important: make sure your load balancer and Vigilmon can reach /health/ without authentication.

What to Monitor Beyond Uptime

Monitor	URL	Alert on
App health	`/health/`	503 response
Database	`/health/db/`	503 response
Cache	`/health/cache/`	503 response
Celery workers	`/health/celery/`	503 or 0 workers
Static files	`/static/`	Not 200
SSL certificate	`https://yourapp.com`	30 days before expiry

Production Checklist

[ ] django-health-check installed and configured
[ ] All check backends enabled (DB, cache, Celery, Redis)
[ ] Health endpoints accessible without authentication
[ ] Vigilmon HTTP monitors for each endpoint
[ ] Response time alert at 1000ms
[ ] SSL certificate monitoring enabled
[ ] Maintenance windows for Django deployments

Start monitoring your Django app for free →

Vigilmon is an uptime monitoring platform for developers. Free tier includes 10 monitors with 1-minute checks from multiple global regions.

How to Monitor Your Kubernetes Cluster with Vigilmon

Vigilmon — Thu, 06 Aug 2026 01:09:59 +0000

How to Monitor Your Kubernetes Cluster with Vigilmon

Kubernetes adds resilience through automatic restarts and rescheduling — but it also adds complexity. Pods crash and restart silently. Services become unreachable due to failed readiness probes. Ingresses misconfigure and start routing traffic to dead pods. Your app can be "running" in Kubernetes while users see nothing but errors.

This guide covers how to use Vigilmon to monitor the externally-visible health of your Kubernetes-hosted services — the part that matters most to your users.

What Vigilmon Monitors in a Kubernetes Stack

Vigilmon focuses on external, user-facing health — not cluster internals. That means:

Ingress/LoadBalancer endpoints: Is your app actually reachable from the internet?
Health check endpoints: Are your pods healthy, or just running?
Service-specific endpoints: Is your database sidecar, Redis, or queue healthy?

For cluster internals (node CPU, pod restarts, etcd health), you'd use Prometheus + Grafana or Datadog. Vigilmon is your external eyes — what users experience.

Kubernetes Health Check Best Practices

Before monitoring with Vigilmon, make sure your Kubernetes services expose proper health endpoints.

Liveness and Readiness Probes

Define these in your Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
spec:
  template:
    spec:
      containers:
      - name: api
        image: your-app:latest
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /health/live
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 30
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /health/ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
          failureThreshold: 2

Implement the Health Endpoints

Liveness (/health/live): Is the process alive and not deadlocked?
Readiness (/health/ready): Can this pod serve traffic right now?

// Express.js example

// Liveness - just check process is alive
app.get('/health/live', (req, res) => {
  res.json({ status: 'ok' });
});

// Readiness - check dependencies
app.get('/health/ready', async (req, res) => {
  try {
    // Check DB connection
    await db.raw('SELECT 1');
    // Check Redis connection
    await redis.ping();
    res.json({ status: 'ready', db: 'ok', redis: 'ok' });
  } catch (err) {
    res.status(503).json({ status: 'not_ready', error: err.message });
  }
});

Setting Up Vigilmon for Kubernetes Services

Once your services are exposed via an Ingress or LoadBalancer:

Sign up at vigilmon.online
Add HTTP Monitor → https://api.yourdomain.com/health/ready
Check interval: 1 minute
Expected status: 200
Alert on first failure (Kubernetes should be self-healing; if Vigilmon sees a failure, something is seriously wrong)

Monitor Multiple Services

For a typical Kubernetes setup, create monitors for:

https://api.yourdomain.com/health/ready     → API service
https://yourdomain.com/                     → Frontend (check for 200)
https://api.yourdomain.com/health/db        → Database connectivity
https://api.yourdomain.com/health/worker    → Background worker status

Kubernetes-Specific Failure Modes to Watch

ImagePullBackOff / CrashLoopBackOff

Your pod keeps restarting. Kubernetes won't route traffic to unhealthy pods, so your service becomes unavailable. Vigilmon will catch this as an HTTP timeout or 503.

Ingress Misconfiguration

A bad Ingress rule or missing TLS secret causes your domain to stop resolving. Vigilmon's external HTTP check catches this immediately — your internal Kubernetes monitoring won't.

Resource Limits Causing OOMKills

resources:
  requests:
    memory: "256Mi"
    cpu: "100m"
  limits:
    memory: "512Mi"  # Hitting this causes OOMKill
    cpu: "500m"

When a pod gets OOMKilled, Kubernetes restarts it. During the restart window (which can be 30-60+ seconds with backoff), your service is partially down. Vigilmon catches this as intermittent failures.

Service Selector Mismatch

A common bug after refactoring: your Service selector stops matching your pod labels. Traffic gets silently dropped.

# Service
spec:
  selector:
    app: api-server  # Must match pod labels exactly

Vigilmon catches this as 503/timeout errors from your Ingress.

Multi-Environment Monitoring

For Kubernetes setups with multiple environments:

# Production
https://api.prod.yourdomain.com/health/ready

# Staging
https://api.staging.yourdomain.com/health/ready

# Development
https://api.dev.yourdomain.com/health/ready

In Vigilmon, group these with labels or naming conventions. Set stricter alerting for production (immediate page on first failure) and softer alerting for staging (warn only).

SSL Certificate Monitoring

Kubernetes TLS certificates (from cert-manager or cloud providers) have expiration dates. Vigilmon monitors SSL expiry and alerts you 30 days before expiration — before Let's Encrypt fails to renew and your site goes HTTPS-dead.

Alerting Configuration for Kubernetes

{
  "monitor": "k8s-api-health",
  "alert_on": {
    "status": "down",
    "response_time_ms": 2000,
    "ssl_days_remaining": 30
  },
  "channels": {
    "critical": ["pagerduty", "slack-ops"],
    "warning": ["slack-alerts"]
  }
}

Monitoring Checklist for Kubernetes

[ ] Liveness and readiness probes defined in Deployments
[ ] External health endpoints accessible via Ingress
[ ] Vigilmon HTTP monitors for each exposed service
[ ] SSL certificate expiry monitoring enabled
[ ] Maintenance windows configured for rolling deployments
[ ] Separate monitor groups for prod vs staging

Start monitoring your Kubernetes services for free →

Vigilmon is an uptime monitoring platform for developers. Free tier includes 10 monitors with 1-minute checks from multiple global regions.

How to Monitor Your Redis Cache with Vigilmon

Vigilmon — Thu, 06 Aug 2026 01:09:13 +0000

How to Monitor Your Redis Cache with Vigilmon

Redis is often the silent hero of your stack — until it isn't. Session stores, job queues, rate limiters, real-time leaderboards — they all fall apart when Redis goes down. And unlike your database, Redis failures can be subtle: memory limits hit, eviction starts silently, and your cache just quietly returns misses without anyone noticing.

This guide covers how to monitor Redis with Vigilmon — a free uptime monitoring platform for developers.

Why Redis Monitoring Is Different

Redis fails in ways that don't always surface immediately:

Memory limit hit — Redis starts evicting keys, your hit rate crashes
Persistence failure — RDB snapshots fail silently, you lose data on restart
Replication lag — your Redis replica falls behind primary
Connection pool exhaustion — your app queues Redis commands and hangs
Keyspace explosion — a bug creates millions of keys, memory fills up

Some of these won't throw errors — they just degrade performance gradually.

Setting Up a Redis Health Endpoint

The best approach: expose an HTTP endpoint in your app that PINGs Redis and returns a health status.

Node.js / Express

const { createClient } = require('redis');

const redis = createClient({ url: process.env.REDIS_URL });
redis.connect();

app.get('/health/redis', async (req, res) => {
  try {
    const result = await redis.ping();
    if (result === 'PONG') {
      return res.json({ status: 'ok', redis: 'connected' });
    }
    throw new Error('Unexpected PING response');
  } catch (err) {
    res.status(503).json({ status: 'error', redis: err.message });
  }
});

Python / FastAPI

import redis
import os
from fastapi import FastAPI
from fastapi.responses import JSONResponse

app = FastAPI()
r = redis.from_url(os.environ['REDIS_URL'], socket_timeout=2)

@app.get('/health/redis')
def health_redis():
    try:
        r.ping()
        return {'status': 'ok', 'redis': 'connected'}
    except redis.ConnectionError as e:
        return JSONResponse(status_code=503, content={'status': 'error', 'redis': str(e)})

PHP / Laravel

Route::get('/health/redis', function () {
    try {
        Redis::ping();
        return response()->json(['status' => 'ok', 'redis' => 'connected']);
    } catch (\Exception $e) {
        return response()->json(['status' => 'error', 'redis' => $e->getMessage()], 503);
    }
});

Configuring Vigilmon

Sign up at vigilmon.online
Add HTTP Monitor → your /health/redis endpoint
Check interval: 1 minute
Alert threshold: 1 failure (Redis should never be down)
Add Slack/email/PagerDuty notifications

TCP Port Monitor (Secondary)

Redis listens on port 6379 by default. Add a TCP monitor:

Host: your Redis server
Port: 6379
This catches Redis process crashes even if your app is down

Advanced Redis Health Metrics

Once basic connectivity is covered, check these critical Redis metrics:

Memory Usage

INFO memory
# Key fields:
# used_memory_human: 2.50G   (current usage)
# maxmemory_human: 4.00G     (configured max)
# mem_fragmentation_ratio: 1.2  (>1.5 is bad)

Alert when used_memory exceeds 80% of maxmemory.

Eviction Rate

INFO stats
# evicted_keys: 0   (should be 0 unless using LRU eviction intentionally)

Any non-zero evicted_keys means Redis is dropping your data.

Connection Count

INFO clients
# connected_clients: 42
# blocked_clients: 0  (should be 0)

Replication Health

INFO replication
# role: master
# connected_slaves: 1
# master_repl_offset: 12345
# slave0:ip=10.0.0.2,port=6379,state=online,offset=12345,lag=0

Expose these as additional health endpoints:

app.get('/health/redis/memory', async (req, res) => {
  const info = await redis.info('memory');
  const usedBytes = parseInt(info.match(/used_memory:(\d+)/)[1]);
  const maxBytes = parseInt(info.match(/maxmemory:(\d+)/)[1]);
  const pct = maxBytes > 0 ? (usedBytes / maxBytes * 100).toFixed(1) : 0;

  if (maxBytes > 0 && usedBytes / maxBytes > 0.9) {
    return res.status(503).json({ status: 'warning', usage_pct: pct });
  }
  res.json({ status: 'ok', usage_pct: pct });
});

Response Time Thresholds

A Redis PING should be near-instant:

<5ms: Healthy
5-50ms: Slightly loaded (network latency or CPU pressure)
>50ms: Investigate — possible memory pressure or slow commands

In Vigilmon, set a response time alert at 100ms for your /health/redis endpoint.

Alerting Matrix

Scenario	Severity	Response
TCP 6379 not responding	P0 Critical	Redis process down, restart immediately
HTTP health returns 503	P1 Critical	Connection error, check logs
Memory >85% of max	P1 Warning	Expand instance or audit keys
Eviction rate >0	P2 Warning	Review TTLs or increase memory
Response time >100ms	P2 Warning	Check for slow commands

Common Redis Monitoring Mistakes

Only checking TCP port — Redis can accept connections but be in a bad state (blocked by a slow LRANGE, near OOM). Always add an application-level health check.

Not monitoring evictions — Silent key eviction can break session stores, rate limiters, and caches in ways that look like application bugs.

Ignoring replica lag — If you're reading from Redis replicas, replication lag can cause stale reads that are hard to debug.

No maintenance windows — Redis restarts during RDB saves can briefly block. Mark these in Vigilmon as scheduled maintenance to avoid false alert fatigue.

Quick Setup Checklist

[ ] /health/redis endpoint with PING check
[ ] TCP monitor on port 6379
[ ] Memory usage endpoint with 80% alert threshold
[ ] Replication health endpoint (if using replica)
[ ] Response time alert at 100ms
[ ] On-call alert for P0/P1, Slack for P2

Start monitoring Redis for free with Vigilmon →

Vigilmon is an uptime monitoring platform for developers. Free tier includes 10 monitors with 1-minute checks from multiple global regions.

How to Monitor Your MySQL Database with Vigilmon

Vigilmon — Thu, 06 Aug 2026 01:08:26 +0000

How to Monitor Your MySQL Database with Vigilmon

MySQL powers some of the world's busiest applications — WordPress, Shopify, and countless others. When MySQL goes down, your entire application stops. Setting up reliable monitoring is one of the highest-leverage investments you can make.

This guide shows you how to monitor MySQL using Vigilmon, a free uptime monitoring platform built for developers.

Common MySQL Failure Modes

MySQL doesn't just "go down" — it degrades:

Max connections reached — new connections get Too many connections errors
Deadlocks — transactions lock each other out and roll back
InnoDB buffer pool pressure — disk I/O spikes as memory runs out
Replication broken — your replica stops syncing, serving stale reads
Slow query accumulation — one bad query brings the server to a crawl

Vigilmon catches the end result: when your app can't reach MySQL, your health endpoint returns an error and Vigilmon fires an alert within 60 seconds.

Building a MySQL Health Endpoint

PHP / Laravel

// routes/api.php
Route::get('/health/db', function () {
    try {
        DB::select('SELECT 1');
        return response()->json(['status' => 'ok', 'db' => 'mysql'], 200);
    } catch (\Exception $e) {
        return response()->json(['status' => 'error', 'db' => $e->getMessage()], 503);
    }
});

Python / Django

from django.http import JsonResponse
from django.db import connections
from django.db.utils import OperationalError

def health_mysql(request):
    try:
        conn = connections['default']
        conn.cursor().execute('SELECT 1')
        return JsonResponse({'status': 'ok', 'db': 'mysql'})
    except OperationalError as e:
        return JsonResponse({'status': 'error', 'db': str(e)}, status=503)

Node.js / Express

const mysql2 = require('mysql2/promise');

const pool = mysql2.createPool({
  host: process.env.DB_HOST,
  user: process.env.DB_USER,
  password: process.env.DB_PASS,
  database: process.env.DB_NAME,
  waitForConnections: true,
  connectionLimit: 10
});

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

Setting Up Vigilmon Monitoring

Create a free account at vigilmon.online
Add an HTTP monitor pointing to /health/db
Set check interval: 1 minute
Configure alerts (email, Slack webhook, or PagerDuty)
Enable multi-region consensus — Vigilmon won't alert unless multiple regions confirm the failure

TCP Port Monitor (Backup)

MySQL listens on port 3306. Add a TCP monitor as a secondary check:

Host: your MySQL server IP or hostname
Port: 3306
This catches cases where MySQL crashes completely

Advanced MySQL Health Checks

Check Connection Count

SHOW STATUS LIKE 'Threads_connected';
-- Alert if Threads_connected > 80% of max_connections
SHOW VARIABLES LIKE 'max_connections';

Check Replication Status

SHOW SLAVE STATUS\G
-- Look for:
-- Slave_IO_Running: Yes
-- Slave_SQL_Running: Yes
-- Seconds_Behind_Master: 0

Slow Query Detection

SHOW STATUS LIKE 'Slow_queries';

Response Time Monitoring

Vigilmon tracks not just uptime but response time. For MySQL health endpoints:

<50ms: Healthy — simple SELECT 1 should return instantly
50-200ms: Degraded — MySQL is under load
>500ms: Critical — likely lock contention or I/O pressure

Set a response time alert at 300ms to catch slowdowns before they become outages.

Alerting Strategy

Scenario	Alert Severity	Action
`/health/db` returns 503	Critical — page on-call	Restart MySQL or failover
Response time >300ms	Warning — Slack alert	Check slow query log
TCP 3306 not responding	Critical — page on-call	Check MySQL process
Replication lag >30s	Warning	Check replica error log

Production Checklist

[ ] Health endpoint with SELECT 1 and timeout
[ ] TCP monitor on port 3306
[ ] Replication health endpoint (if using replicas)
[ ] Response time threshold alert (300ms)
[ ] Alert routing: critical → PagerDuty, warning → Slack
[ ] Maintenance windows for schema migrations

Why Multi-Region Monitoring Matters

A single-location health check generates false positives from regional network blips. Vigilmon runs checks from multiple global regions and only alerts when a majority confirm the failure. This eliminates alert fatigue while keeping true MTTD under 2 minutes.

Start monitoring your MySQL database for free →

Vigilmon is an uptime monitoring platform for developers. Free tier includes 10 monitors with 1-minute checks.

How to Monitor Your PostgreSQL Database with Vigilmon

Vigilmon — Thu, 06 Aug 2026 01:07:39 +0000

How to Monitor Your PostgreSQL Database with Vigilmon

PostgreSQL is the backbone of countless production applications — and when it goes down, everything stops. Effective database monitoring isn't just about knowing when Postgres crashes; it's about catching degradation before it becomes an outage.

In this guide, we'll cover how to monitor your PostgreSQL database using Vigilmon — a free uptime monitoring platform designed for developers.

Why Monitor PostgreSQL?

Postgres failures rarely announce themselves. They creep in:

Connection pool exhaustion — your app starts refusing new connections
Long-running queries — one bad query locks tables and cascades failures
Replication lag — your replica falls behind; reads serve stale data
Disk pressure — write-ahead logs balloon; Postgres refuses writes
Process crashes — the postmaster dies silently

By the time users complain, you've already lost signups, orders, or worse.

Setting Up Postgres Health Checks

Option 1: HTTP Health Endpoint (Recommended)

The cleanest approach: expose a lightweight /health endpoint in your app that queries Postgres and returns 200/503 based on the result.

# Flask example
from flask import Flask, jsonify
import psycopg2
import os

app = Flask(__name__)

@app.route('/health/db')
def health_db():
    try:
        conn = psycopg2.connect(os.environ['DATABASE_URL'], connect_timeout=3)
        cur = conn.cursor()
        cur.execute('SELECT 1')
        cur.close()
        conn.close()
        return jsonify({'status': 'ok', 'db': 'connected'}), 200
    except Exception as e:
        return jsonify({'status': 'error', 'db': str(e)}), 503

// Node.js / Express example
const { Pool } = require('pg');
const pool = new Pool({ connectionString: process.env.DATABASE_URL });

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

Option 2: TCP Port Monitor

If you can't modify your app, monitor the Postgres port directly. Postgres listens on TCP port 5432 by default.

In Vigilmon, add a TCP monitor:

Host: your-db-host.example.com
Port: 5432
Check interval: 1 minute

This confirms the Postgres process is running and accepting connections — but doesn't verify it can actually execute queries.

Configuring Vigilmon for Database Monitoring

Sign up at vigilmon.online (free tier available)
Click Add Monitor
Select HTTP (for health endpoints) or TCP (for port checks)
Set your check interval — 1 minute is ideal for databases
Configure alerting thresholds

Vigilmon checks from multiple regions simultaneously — this means you won't get false positives from regional network issues. Both checks must fail before an alert fires.

What to Monitor Beyond Uptime

Raw uptime isn't enough for Postgres. Pair Vigilmon with these:

Connection Count

SELECT count(*) FROM pg_stat_activity WHERE state = 'active';

Alert when this approaches max_connections (default 100).

Replication Lag (for replicas)

SELECT EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp())) AS lag_seconds;

Alert when lag_seconds > 30.

Long-Running Queries

SELECT pid, now() - query_start AS duration, query
FROM pg_stat_activity
WHERE state = 'active' AND now() - query_start > interval '30 seconds';

Expose these as sub-endpoints and monitor them with Vigilmon alongside your main DB check.

Alert Configuration

In Vigilmon, configure:

Immediate alert on HTTP 503 or TCP connection failure
Response time alert if your DB health check takes >500ms
Multi-channel alerts: email, Slack, PagerDuty webhook

Production Checklist

[ ] HTTP health endpoint queries Postgres with a timeout
[ ] TCP port 5432 monitored as a secondary check
[ ] Replication lag endpoint for read replicas
[ ] Vigilmon alerts go to your on-call channel
[ ] Test alert delivery by temporarily returning 503
[ ] Maintenance windows set for planned Postgres upgrades

Common PostgreSQL Failure Modes

Failure	Symptom	Vigilmon Check
Process crash	TCP port closes	TCP monitor fires immediately
Connection exhaustion	HTTP 503	HTTP monitor catches 503
Long lock	Health check slow	Response time threshold
Replication lag	/health/replication returns 503	Separate HTTP monitor
Disk full	Postgres refuses writes	Custom endpoint

Wrapping Up

PostgreSQL monitoring with Vigilmon takes about 10 minutes to set up. A simple SELECT 1 health endpoint + a Vigilmon HTTP check catches 90% of real-world failure modes.

Start with the basics: an HTTP health endpoint that queries Postgres and returns 200 when healthy. Then layer in connection count, replication lag, and query performance checks as your app matures.

Set up your first Postgres monitor on Vigilmon →

Vigilmon is an uptime monitoring platform for developers. Free tier includes 10 monitors with 1-minute checks from multiple global regions.

AWS SQS Monitoring: Queue Depth, DLQ Alerts, and Consumer Health

Vigilmon — Wed, 05 Aug 2026 22:48:03 +0000

AWS SQS Monitoring: Catch Queue Failures Early

SQS queues fail silently. Messages pile up and users experience delays with no obvious error.

The Critical Metric: ApproximateAgeOfOldestMessage

This tells you how stale your oldest unprocessed message is. If it grows, consumers are not keeping up. Alert when it exceeds 5 minutes.

Consumer Logging

async function processMessages() {
  const { Messages = [] } = await sqs.send(new ReceiveMessageCommand({
    QueueUrl: process.env.QUEUE_URL,
    MaxNumberOfMessages: 10,
    WaitTimeSeconds: 20
  }));

  for (const msg of Messages) {
    const start = Date.now();
    try {
      await handleMessage(JSON.parse(msg.Body));
      await sqs.send(new DeleteMessageCommand({ QueueUrl: process.env.QUEUE_URL, ReceiptHandle: msg.ReceiptHandle }));
      console.log(JSON.stringify({ event: 'processed', duration_ms: Date.now() - start }));
    } catch (err) {
      console.error(JSON.stringify({ event: 'failed', error: err.message }));
    }
  }
}

Dead Letter Queue

Set a CloudWatch alarm on DLQ depth at threshold 1. Any DLQ message is a processing failure.

Consumer Health Endpoint

app.get('/health', async (req, res) => {
  const depth = await getQueueDepth();
  res.status(depth < 10000 ? 200 : 503).json({ queue_depth: depth });
});

Monitor with Vigilmon.

Alert Summary

Metric	Threshold
OldestMessage age	above 5 min
DLQ depth	above 0
Consumer health	non-200

Turso libSQL Monitoring: Query Latency and Edge Health Checks

Vigilmon — Wed, 05 Aug 2026 22:47:13 +0000

Turso libSQL Monitoring at the Edge

Turso is optimized for low latency. Queries above 50ms warrant investigation.

Query Instrumentation

import { createClient } from '@libsql/client';
const client = createClient({ url: process.env.TURSO_DATABASE_URL!, authToken: process.env.TURSO_AUTH_TOKEN! });

async function dbQuery(sql: string, args?: any[]) {
  const start = performance.now();
  const result = await client.execute({ sql, args: args ?? [] });
  const duration = performance.now() - start;
  if (duration > 50) {
    console.warn('turso_slow: ' + Math.round(duration) + 'ms - ' + sql.substring(0, 80));
  }
  return result;
}

Health Check

app.get('/health', async (_req, res) => {
  try {
    await client.execute('SELECT 1');
    res.json({ status: 'ok', db: 'turso' });
  } catch (err) {
    res.status(503).json({ status: 'unhealthy' });
  }
});

Monitor with Vigilmon every minute.

Edge Function Logging

export default {
  async fetch(request: Request, env: Env) {
    const start = Date.now();
    const result = await handleRequest(request, env);
    console.log(JSON.stringify({ path: new URL(request.url).pathname, duration_ms: Date.now() - start }));
    return result;
  }
};

Takeaways

Alert on queries above 50ms
Monitor health endpoint with Vigilmon
Log duration on every edge function request