DEV Community: Vigilmon

Monitoring Litestar Python Applications with Vigilmon

Vigilmon — Tue, 30 Jun 2026 07:49:44 +0000

Monitoring Litestar Python Applications with Vigilmon

Litestar (formerly Starlite) is a fast, async Python framework that takes first-class typing, dependency injection, and OpenAPI generation seriously. It's a compelling alternative to FastAPI for teams that want more structure out of the box.

But like any web framework, Litestar doesn't tell you when your app goes down. That's an external concern, and this guide covers exactly how to handle it: adding structured health endpoints to your Litestar app, then hooking them into Vigilmon for multi-region uptime monitoring and alerts.

What's different about Litestar monitoring

If you've already read monitoring guides for FastAPI, Django, or Flask, the concepts here are the same. The implementation is different because Litestar has:

Typed route handlers via @get, @post, etc. decorators with return type annotations
Dependency injection built into the framework — use it to inject your DB connection into health checks
Built-in OpenAPI — your health endpoint will automatically appear in your API docs
DTOFactory / dataclasses — returning structured responses is idiomatic

The patterns below fit the Litestar way of doing things.

Step 1: Add a structured health check endpoint

Litestar's route handlers are functions with type annotations. Create a dedicated health router:

# app/health.py
from __future__ import annotations

from dataclasses import dataclass
from typing import Literal

from litestar import Router, get
from litestar.status_codes import HTTP_200_OK, HTTP_503_SERVICE_UNAVAILABLE
from litestar.response import Response

Define a response dataclass:

@dataclass
class ServiceCheck:
    status: Literal["ok", "error"]
    detail: str | None = None


@dataclass
class HealthResponse:
    status: Literal["ok", "degraded"]
    checks: dict[str, ServiceCheck]

Add the health route:

async def check_database(db_url: str) -> ServiceCheck:
    """Verify database connectivity."""
    try:
        import asyncpg
        conn = await asyncpg.connect(db_url, timeout=3)
        await conn.execute("SELECT 1")
        await conn.close()
        return ServiceCheck(status="ok")
    except Exception as exc:
        return ServiceCheck(status="error", detail=str(exc))


async def check_redis(redis_url: str | None) -> ServiceCheck | None:
    if not redis_url:
        return None
    try:
        import redis.asyncio as aioredis
        r = aioredis.from_url(redis_url)
        await r.ping()
        await r.aclose()
        return ServiceCheck(status="ok")
    except Exception as exc:
        return ServiceCheck(status="error", detail=str(exc))


@get("/health", status_code=HTTP_200_OK, tags=["ops"])
async def health_handler(
    db_url: str,         # injected via Litestar DI
    redis_url: str | None = None,
) -> Response[HealthResponse]:
    db = await check_database(db_url)
    checks: dict[str, ServiceCheck] = {"database": db}

    redis = await check_redis(redis_url)
    if redis is not None:
        checks["redis"] = redis

    all_ok = all(c.status == "ok" for c in checks.values())

    return Response(
        content=HealthResponse(
            status="ok" if all_ok else "degraded",
            checks=checks,
        ),
        status_code=HTTP_200_OK if all_ok else HTTP_503_SERVICE_UNAVAILABLE,
    )

Wire up the router and inject the dependencies in your app:

# app/main.py
import os
from litestar import Litestar
from litestar.di import Provide
from app.health import health_handler


def get_db_url() -> str:
    return os.environ["DATABASE_URL"]


def get_redis_url() -> str | None:
    return os.environ.get("REDIS_URL")


app = Litestar(
    route_handlers=[health_handler],
    dependencies={
        "db_url": Provide(get_db_url),
        "redis_url": Provide(get_redis_url),
    },
)

Test it:

uvicorn app.main:app --reload
curl http://localhost:8000/health

Healthy response:

{
  "status": "ok",
  "checks": {
    "database": {"status": "ok", "detail": null}
  }
}

Degraded response (HTTP 503):

{
  "status": "degraded",
  "checks": {
    "database": {
      "status": "error",
      "detail": "could not connect to server: Connection refused"
    }
  }
}

The 503 is the signal your external monitor needs to open an incident automatically.

Step 2: Add liveness vs readiness separation

For containerised deployments, distinguish between the two:

# app/health.py — add these two handlers

@get("/health/live", tags=["ops"], status_code=HTTP_200_OK)
async def liveness_handler() -> dict[str, str]:
    """Is the process alive? For container liveness probes."""
    return {"status": "ok"}


@get("/health/ready", tags=["ops"])
async def readiness_handler(db_url: str) -> Response[dict]:
    """Are dependencies ready? For container readiness probes."""
    db = await check_database(db_url)
    if db.status != "ok":
        return Response(
            content={"status": "not_ready", "database": db.detail},
            status_code=HTTP_503_SERVICE_UNAVAILABLE,
        )
    return Response(
        content={"status": "ready"},
        status_code=HTTP_200_OK,
    )

Vigilmon monitors /health/ready — this reflects whether your app is actually serving traffic correctly
Kubernetes uses /health/live for the liveness probe — it won't restart a healthy pod just because Postgres is temporarily slow

Step 3: Set up external monitoring with Vigilmon

With your health endpoints live, point Vigilmon at them:

Sign up at vigilmon.online — free tier, no credit card required
New Monitor → HTTP
Enter https://yourdomain.com/health
Set check interval to 5 minutes
Save

Vigilmon probes from multiple geographic regions. If any region gets a non-2xx response or timeout, it opens an incident and sends an alert.

Add a keyword monitor

For deeper assurance, add a keyword monitor that asserts the response body contains "status":"ok":

New Monitor → Keyword
URL: https://yourdomain.com/health
Keyword: "status":"ok"

This catches the case where your app returns HTTP 200 but serves a degraded response — which you'd otherwise miss with a status-only check.

Recommended Litestar monitor set

Monitor	URL	Type	What it catches
App health	`/health`	HTTP	Database down, Redis down
Keyword check	`/health`	Keyword	Degraded response despite 200
Readiness	`/health/ready`	HTTP	App in unready state
Root route	`/`	HTTP	App startup failure

Step 4: Heartbeat monitoring for background tasks

If your Litestar app has background workers or scheduled tasks, HTTP endpoint checks won't catch silent worker failures.

Using APScheduler with Litestar's lifespan

# app/main.py
import os
import httpx
import logging
from contextlib import asynccontextmanager
from collections.abc import AsyncGenerator
from litestar import Litestar
from apscheduler.schedulers.asyncio import AsyncIOScheduler

logger = logging.getLogger(__name__)
scheduler = AsyncIOScheduler()


async def nightly_cleanup() -> None:
    """Run cleanup and ping heartbeat on success."""
    try:
        # Your actual logic
        await do_cleanup()

        heartbeat_url = os.environ.get("CLEANUP_HEARTBEAT_URL")
        if heartbeat_url:
            async with httpx.AsyncClient() as client:
                await client.get(heartbeat_url, timeout=10)
            logger.info("nightly_cleanup: heartbeat pinged")

    except Exception:
        logger.exception("nightly_cleanup: failed, skipping heartbeat")


@asynccontextmanager
async def lifespan(_: Litestar) -> AsyncGenerator[None, None]:
    scheduler.add_job(
        nightly_cleanup,
        trigger="cron",
        hour=2,
        minute=0,
        id="nightly_cleanup",
        replace_existing=True,
    )
    scheduler.start()
    yield
    scheduler.shutdown()


app = Litestar(
    route_handlers=[health_handler, liveness_handler, readiness_handler],
    lifespan=[lifespan],
)

# .env
CLEANUP_HEARTBEAT_URL=https://vigilmon.online/api/heartbeat/your-unique-token

In Vigilmon:

New Monitor → Heartbeat
Expected interval: 25 hours (buffer for a nightly job)
Copy the ping URL and add to your environment

Step 5: Configure alerts

Slack:

Create an incoming webhook in your Slack workspace
Vigilmon: Notifications → New Channel → Slack
Paste the URL and enable on your monitors

Discord:

In your Discord server: Integrations → Webhooks → New Webhook
Vigilmon: Notifications → New Channel → Discord
Paste and enable

When your app goes down:

🔴 DOWN: yourdomain.com/health
Status: 503 Service Unavailable
Regions: US-East, EU-West, AP-Southeast
Started: 3 minutes ago

When a scheduled task misses its heartbeat:

🔴 MISSED: nightly_cleanup heartbeat
Expected every: 25 hours
Last ping: 27 hours ago

Step 6: Docker and Gunicorn setup

For production Litestar deployments:

# Dockerfile
FROM python:3.12-slim

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8000

HEALTHCHECK --interval=30s --timeout=10s --retries=3 --start-period=30s \
  CMD python -c "import urllib.request; urllib.request.urlopen('http://localhost:8000/health/live')"

CMD ["gunicorn", "app.main:app", \
     "--worker-class", "uvicorn.workers.UvicornWorker", \
     "--workers", "4", \
     "--bind", "0.0.0.0:8000"]

The HEALTHCHECK directive gives Docker visibility into app health for automatic restarts. Vigilmon provides the external alert when the container isn't even reachable.

Step 7: Public status page

In Vigilmon:

Status Pages → New Status Page
Name it and add your monitors
Share the URL with your users

Add it to your Litestar app's OpenAPI metadata so it appears in the docs:

from litestar.openapi.config import OpenAPIConfig
from litestar.openapi.spec import Contact

app = Litestar(
    openapi_config=OpenAPIConfig(
        title="My API",
        version="1.0.0",
        description="Status page: https://status.yourdomain.com",
        contact=Contact(name="Ops Team", email="ops@yourdomain.com"),
    ),
    route_handlers=[health_handler, liveness_handler, readiness_handler],
)

What you've built

What	How
Typed health endpoint	`/health` with dependency-injected DB check, returns 503 on failure
Liveness vs readiness	`/health/live` and `/health/ready` — separate concerns
External uptime monitoring	Vigilmon HTTP monitor (multi-region)
Keyword assertion	Verify `"status":"ok"` in response body
Background task monitoring	APScheduler + heartbeat ping on success
Instant alerts	Slack/Discord notifications on down + recovery
Container health	Docker `HEALTHCHECK` directive
Public status page	Vigilmon status page linked from API docs

Litestar's typed handler system makes health endpoints clean to write and self-documenting in OpenAPI. Pair that with Vigilmon's external monitoring and you have full visibility into your application's health without adding any heavy dependencies.

Get started free at vigilmon.online — your first monitor is running in under a minute.

Monitoring Temporal.io Workflows with Vigilmon

Vigilmon — Tue, 30 Jun 2026 07:49:38 +0000

Monitoring Temporal.io Workflows with Vigilmon

Temporal is a workflow orchestration platform that handles the hard parts of distributed systems: retries, timeouts, state persistence, and failure recovery. When it's working, your workflows run reliably across days, weeks, or months without you thinking about them.

When Temporal goes down — or when a scheduled workflow silently stops firing — business processes halt. Payments aren't processed. Reports aren't generated. Data isn't synced. And because Temporal is designed to feel invisible, failures in it are often invisible too.

This guide shows you how to monitor the Temporal server health endpoints and use Vigilmon heartbeat monitors to catch silent workflow failures before they become business incidents.

The two failure modes in Temporal deployments

Server-level failures: The Temporal frontend, history, matching, or worker services crash or become unresponsive. New workflows can't be started, existing ones can't advance.

Silent workflow failures: The Temporal server is healthy but a specific workflow type has stopped being scheduled — perhaps because the worker process that handles it crashed, the cron schedule was misconfigured, or a code deployment broke the workflow registration. The server is "green" but critical business logic isn't running.

Standard HTTP uptime monitors only catch the first type. You need heartbeat monitoring to catch the second.

Step 1: Understand Temporal's health endpoints

Temporal exposes health information through two interfaces: an HTTP gateway and gRPC.

HTTP health endpoint (Temporal Web UI + gateway)

If you're running Temporal with the bundled web UI or a Temporal Cloud gateway, you typically have an HTTP endpoint available:

# Check the Temporal frontend via HTTP gateway
curl https://your-temporal.com/health

# Or via the metrics endpoint (Prometheus-compatible)
curl http://your-temporal.com:7233/metrics

For self-hosted Temporal, the most accessible HTTP health check is through the Temporal Web UI:

curl https://your-temporal-ui.com
# Returns HTTP 200 if the UI is serving

gRPC health check (the authoritative check)

Temporal's services expose standard gRPC health checks. Using grpc-health-probe:

# Install grpc-health-probe
go install github.com/grpc-ecosystem/grpc-health-probe@latest

# Check the frontend service (default port 7233)
grpc-health-probe -addr=your-temporal.com:7233

# Check the history service (port 7234)
grpc-health-probe -addr=your-temporal.com:7234 -service temporal.api.workflowservice.v1.WorkflowService

Healthy output:

status: SERVING

HTTP wrapper for external monitoring

Since most external monitoring tools (including Vigilmon) probe HTTP, wrap the gRPC check in a lightweight HTTP health service on your server:

// cmd/temporal-healthcheck/main.go
package main

import (
    "context"
    "fmt"
    "log"
    "net/http"
    "time"

    "google.golang.org/grpc"
    "google.golang.org/grpc/credentials/insecure"
    healthpb "google.golang.org/grpc/health/grpc_health_v1"
)

func temporalHealthHandler(w http.ResponseWriter, r *http.Request) {
    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()

    conn, err := grpc.DialContext(ctx, "localhost:7233",
        grpc.WithTransportCredentials(insecure.NewCredentials()),
        grpc.WithBlock(),
    )
    if err != nil {
        http.Error(w, fmt.Sprintf("cannot connect: %v", err), http.StatusServiceUnavailable)
        return
    }
    defer conn.Close()

    client := healthpb.NewHealthClient(conn)
    resp, err := client.Check(ctx, &healthpb.HealthCheckRequest{
        Service: "temporal.api.workflowservice.v1.WorkflowService",
    })
    if err != nil || resp.Status != healthpb.HealthCheckResponse_SERVING {
        http.Error(w, "temporal not serving", http.StatusServiceUnavailable)
        return
    }

    w.WriteHeader(http.StatusOK)
    fmt.Fprintln(w, `{"status":"ok","temporal":"serving"}`)
}

func main() {
    http.HandleFunc("/health", temporalHealthHandler)
    log.Println("health proxy listening on :8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

Run this sidecar on your Temporal host:

go run cmd/temporal-healthcheck/main.go

Now Vigilmon can probe http://your-temporal-host:8080/health and get a meaningful HTTP response that reflects actual Temporal service state.

Step 2: Set up Vigilmon server monitoring

With your health endpoint live, configure Vigilmon:

Sign up at vigilmon.online — free tier, no credit card
New Monitor → HTTP
URL: http://your-temporal-host:8080/health
Keyword: "status":"ok"
Set check interval to 5 minutes
Save

Also add a monitor for the Temporal Web UI if you use it:

URL: https://your-temporal-ui.com
Expected status: 200

Step 3: Heartbeat monitoring for scheduled workflows

This is the most important monitoring pattern for Temporal. Server health checks only tell you the engine is running. Heartbeat monitoring tells you that your specific workflows are actually executing.

The pattern: at the end of each successful workflow execution (or the last activity in the workflow), ping a unique Vigilmon heartbeat URL. If the ping stops arriving within the expected interval, Vigilmon alerts you.

Temporal Go SDK example

// internal/workflows/nightly_report.go
package workflows

import (
    "context"
    "net/http"
    "os"
    "time"

    "go.temporal.io/sdk/activity"
    "go.temporal.io/sdk/temporal"
    "go.temporal.io/sdk/workflow"
)

func NightlyReportWorkflow(ctx workflow.Context) error {
    ao := workflow.ActivityOptions{
        StartToCloseTimeout: 30 * time.Minute,
        RetryPolicy: &temporal.RetryPolicy{
            MaximumAttempts: 3,
        },
    }
    ctx = workflow.WithActivityOptions(ctx, ao)

    // Execute report generation
    if err := workflow.ExecuteActivity(ctx, GenerateReport).Get(ctx, nil); err != nil {
        return err
    }

    // Ping heartbeat on successful completion
    if err := workflow.ExecuteActivity(ctx, PingHeartbeat).Get(ctx, nil); err != nil {
        workflow.GetLogger(ctx).Warn("heartbeat ping failed — non-fatal", "error", err)
        // Don't fail the workflow over a monitoring ping failure
    }

    return nil
}

func PingHeartbeat(ctx context.Context) error {
    logger := activity.GetLogger(ctx)
    heartbeatURL := os.Getenv("REPORT_HEARTBEAT_URL")
    if heartbeatURL == "" {
        return nil
    }

    client := &http.Client{Timeout: 10 * time.Second}
    resp, err := client.Get(heartbeatURL)
    if err != nil {
        logger.Warn("heartbeat ping error", "error", err)
        return nil // Don't surface this as an activity failure
    }
    defer resp.Body.Close()
    logger.Info("heartbeat pinged", "status", resp.StatusCode)
    return nil
}

Temporal Python SDK example

# workflows/sync_workflow.py
import asyncio
import os
import aiohttp
from temporalio import activity, workflow
from temporalio.common import RetryPolicy
from datetime import timedelta


@activity.defn
async def ping_heartbeat() -> None:
    """Ping Vigilmon heartbeat — call after successful workflow completion."""
    url = os.environ.get("SYNC_HEARTBEAT_URL")
    if not url:
        return
    try:
        async with aiohttp.ClientSession() as session:
            async with session.get(url, timeout=aiohttp.ClientTimeout(total=10)) as resp:
                activity.logger.info(f"Heartbeat pinged: {resp.status}")
    except Exception as e:
        activity.logger.warning(f"Heartbeat ping failed (non-fatal): {e}")


@activity.defn
async def run_data_sync() -> dict:
    """Actual sync logic."""
    # ... your sync implementation ...
    return {"synced": 0}


@workflow.defn
class DataSyncWorkflow:
    @workflow.run
    async def run(self) -> None:
        result = await workflow.execute_activity(
            run_data_sync,
            start_to_close_timeout=timedelta(minutes=30),
            retry_policy=RetryPolicy(maximum_attempts=3),
        )
        workflow.logger.info(f"Sync complete: {result}")

        # Always ping on success, even if the ping itself fails
        await workflow.execute_activity(
            ping_heartbeat,
            start_to_close_timeout=timedelta(seconds=30),
            retry_policy=RetryPolicy(maximum_attempts=1),
        )

Set up the Vigilmon heartbeat monitor

In Vigilmon:

New Monitor → Heartbeat
Name: "Nightly Report Workflow"
Expected interval: 25 hours (for a nightly cron — buffer beyond 24h)
Copy the unique URL
Set in your worker environment:

# .env or environment config
REPORT_HEARTBEAT_URL=https://vigilmon.online/api/heartbeat/your-token-1
SYNC_HEARTBEAT_URL=https://vigilmon.online/api/heartbeat/your-token-2

One heartbeat per critical workflow type. When you get an alert, you know exactly which workflow stopped — not just that "something is wrong."

Step 4: Monitor the Temporal worker processes

Your Temporal workflows won't run if the worker processes aren't polling for tasks. Workers are separate processes from the Temporal server, and they die silently.

Add a liveness ping from your worker startup:

// worker/main.go
package main

import (
    "log"
    "net/http"
    "os"
    "os/signal"
    "syscall"

    "go.temporal.io/sdk/client"
    "go.temporal.io/sdk/worker"
)

func main() {
    c, err := client.Dial(client.Options{
        HostPort: os.Getenv("TEMPORAL_HOST"),
    })
    if err != nil {
        log.Fatalf("client dial failed: %v", err)
    }
    defer c.Close()

    w := worker.New(c, "main-task-queue", worker.Options{})
    // Register workflows and activities
    // w.RegisterWorkflow(...)
    // w.RegisterActivity(...)

    // Expose a simple health endpoint for the worker process
    go func() {
        http.HandleFunc("/alive", func(rw http.ResponseWriter, r *http.Request) {
            rw.WriteHeader(http.StatusOK)
            rw.Write([]byte(`{"alive":true}`))
        })
        log.Println("worker liveness on :8081")
        http.ListenAndServe(":8081", nil)
    }()

    // Block until interrupt
    quit := make(chan os.Signal, 1)
    signal.Notify(quit, os.Interrupt, syscall.SIGTERM)

    if err := w.Start(); err != nil {
        log.Fatalf("worker start failed: %v", err)
    }
    <-quit
    w.Stop()
}

Add a Vigilmon monitor on http://your-worker-host:8081/alive. If the worker process crashes, you'll know in minutes rather than at the next missed workflow execution.

Step 5: Configure alerts

Slack setup:

Create an incoming webhook in Slack
Vigilmon: Notifications → New Channel → Slack
Enable on all Temporal monitors

When a workflow heartbeat is missed:

🔴 MISSED: Nightly Report Workflow heartbeat
Expected every: 25 hours
Last ping: 27 hours ago
Action needed: check Temporal worker logs

When the Temporal server goes down:

🔴 DOWN: temporal-health.your-domain.com/health
Status: 503 Service Unavailable
Regions: US-East, EU-West

What you've built

What	How
Server health monitoring	HTTP proxy over gRPC health check
Per-workflow monitoring	Vigilmon heartbeat — one per critical workflow type
Worker liveness	HTTP endpoint on worker process
Immediate alerts	Slack notifications on server down or missed heartbeat
Failure isolation	Named heartbeats identify exactly which workflow stopped

The server health check catches Temporal infrastructure failures. The per-workflow heartbeats catch silent execution failures that infrastructure monitors will never see. Together, they give you full observability over your Temporal deployment.

Get started free at vigilmon.online — your first monitor is running in under a minute.

Monitoring Your Self-Hosted Appwrite Backend with Vigilmon

Vigilmon — Tue, 30 Jun 2026 07:48:49 +0000

Monitoring Your Self-Hosted Appwrite Backend with Vigilmon

Appwrite gives you a full backend in a single Docker deployment — authentication, databases, file storage, cloud functions, and realtime subscriptions. It's the self-hosted alternative to Firebase and Supabase that keeps your data on your own infrastructure.

That self-hosted advantage comes with a responsibility: no one else is watching your uptime. When Appwrite goes down, every app that depends on it stops working. This guide shows you how to set up proper monitoring using Vigilmon so you know about failures before your users do.

What makes Appwrite monitoring distinct

Appwrite is not a single process — it's a set of microservices running as Docker containers:

appwrite — the core API
appwrite-worker-* — background workers for functions, mails, webhooks, etc.
appwrite-executor — runs cloud functions
mariadb — the primary database
redis — caching and queues
influxdb — usage metrics
traefik — the reverse proxy that routes traffic

A partial failure — say, the functions executor crashes while the core API stays up — looks like "Appwrite is running" from the outside but silently breaks cloud function invocations. You need service-level monitoring, not just a single ping.

Step 1: Explore Appwrite's health API

Appwrite exposes a comprehensive health API at /v1/health. You don't need to write any code — it's built in.

Overall health check

curl https://your-appwrite.com/v1/health

Response when healthy:

{
  "ping": 128,
  "status": "pass"
}

This confirms the Appwrite API process is alive and responding.

Per-service health endpoints

Appwrite provides granular health checks for each internal service:

# Database (MariaDB)
curl https://your-appwrite.com/v1/health/db

# Cache (Redis)
curl https://your-appwrite.com/v1/health/cache

# Queue (Redis-backed)
curl https://your-appwrite.com/v1/health/queue

# Storage filesystem
curl https://your-appwrite.com/v1/health/storage/local

# Certificate renewal queue
curl https://your-appwrite.com/v1/health/certificate

# Functions execution queue depth
curl https://your-appwrite.com/v1/health/queue/functions

Each returns the same shape:

{ "ping": 45, "status": "pass" }

Or on failure:

{ "ping": 0, "status": "fail" }

Authentication requirement

The /v1/health endpoints require an API key with the health.read scope. Create one:

Appwrite console → Settings → API Keys → Add API Key
Name it "monitoring" and enable the health.read permission
Copy the key

You'll pass this in the X-Appwrite-Key header.

Step 2: Set up Vigilmon monitors for each service

With the health API explored, set up a monitor per critical service in Vigilmon:

Sign up at vigilmon.online — free tier, no credit card
New Monitor → HTTP

For monitors that require authentication headers, use Vigilmon's custom headers:

Monitor name	URL	Custom header
Appwrite API	`/v1/health`	`X-Appwrite-Key: your-key`
Database	`/v1/health/db`	`X-Appwrite-Key: your-key`
Cache	`/v1/health/cache`	`X-Appwrite-Key: your-key`
Storage	`/v1/health/storage/local`	`X-Appwrite-Key: your-key`
Queue	`/v1/health/queue`	`X-Appwrite-Key: your-key`

Add keyword monitors for status assertion

HTTP status alone isn't enough — you want to assert that the response body says "status":"pass", not just that the server returned 200.

For each service monitor, set the Keyword to "status":"pass". If Appwrite returns a 200 but the body says "status":"fail", Vigilmon treats it as an outage.

Step 3: Monitor cloud functions with heartbeats

HTTP endpoint checks confirm Appwrite is running. They won't tell you if a cloud function that runs on a schedule has silently stopped executing.

The heartbeat pattern: your function pings Vigilmon at the end of each successful run. If Vigilmon stops receiving pings within the expected interval, it fires an alert.

Example: Node.js cloud function with heartbeat

// functions/nightly-sync/src/index.js
import { Client, Databases } from 'node-appwrite';
import https from 'https';

export default async ({ req, res, log, error }) => {
  try {
    const client = new Client()
      .setEndpoint(process.env.APPWRITE_FUNCTION_API_ENDPOINT)
      .setProject(process.env.APPWRITE_FUNCTION_PROJECT_ID)
      .setKey(req.headers['x-appwrite-key']);

    const databases = new Databases(client);

    // Your actual business logic
    const items = await databases.listDocuments('main', 'sync-queue');
    log(`Processing ${items.total} items`);
    // ... process items ...

    // Ping heartbeat only on success
    const heartbeatUrl = process.env.SYNC_HEARTBEAT_URL;
    if (heartbeatUrl) {
      await new Promise((resolve, reject) => {
        https.get(heartbeatUrl, resolve).on('error', reject);
      });
      log('Heartbeat pinged');
    }

    return res.json({ ok: true, processed: items.total });
  } catch (err) {
    error(err.message);
    // Do NOT ping on failure — the missed ping is the alert
    return res.json({ ok: false, error: err.message }, 500);
  }
};

Set the environment variable in Appwrite's function settings:

SYNC_HEARTBEAT_URL = https://vigilmon.online/api/heartbeat/your-unique-token

In Vigilmon:

New Monitor → Heartbeat
Set the expected interval (e.g., 25 hours for a nightly function)
Copy the ping URL and add it to your function's env vars

Now if the function crashes, the Appwrite executor goes down, or the function is accidentally deleted, Vigilmon alerts you within one missed interval.

Step 4: Monitor the Appwrite console

The Appwrite web console is separate from the API. Monitor it independently — a broken Traefik configuration or a failed SSL certificate renewal can take down the console while leaving the API accessible.

Add a simple HTTP monitor:

URL: https://your-appwrite.com (the console root)
Expected status: 200
Keyword: Appwrite (to confirm the right page is loading)

Step 5: Configure alerts

Set up alert channels in Vigilmon so the right people are notified immediately.

Slack:

Create an incoming webhook in your Slack workspace
Vigilmon: Notifications → New Channel → Slack
Paste the webhook URL and enable it on all your Appwrite monitors

PagerDuty or on-call rotation:
For production Appwrite deployments, wire Vigilmon into your on-call tool via webhook:

Vigilmon: Notifications → New Channel → Webhook
Enter your PagerDuty Events API or on-call webhook URL

When the database goes down:

🔴 DOWN: your-appwrite.com/v1/health/db
Keyword "status":"pass" not found
Regions: US-East, EU-West
Started: 4 minutes ago

When it recovers:

✅ RECOVERED: your-appwrite.com/v1/health/db is back UP
Total downtime: 12 minutes

Step 6: Docker Compose health checks

If you manage Appwrite via Docker Compose (the standard self-hosted setup), add container-level health checks to the core service:

# docker-compose.yml (add to the appwrite service)
services:
  appwrite:
    # ... existing config ...
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost/v1/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 90s

This makes Docker aware of Appwrite's health state and restarts the container automatically on repeated failures. Vigilmon handles the external alert; Docker handles the self-healing.

Step 7: Set up a public status page

If you're offering Appwrite as a backend to other developers or teams, give them visibility into service health.

In Vigilmon:

Status Pages → New Status Page
Name it (e.g. "Backend Services")
Add monitors grouped by service:
- API — the core /v1/health monitor
- Database — the /v1/health/db monitor
- Storage — the /v1/health/storage/local monitor
Save and share the public URL

What you've built

What	How
API health monitoring	Vigilmon HTTP monitor on `/v1/health`
Per-service health	Separate monitors for DB, cache, queue, storage
Keyword assertion	Verify `"status":"pass"` in response body
Cloud function monitoring	Heartbeat ping after each successful execution
Console monitoring	HTTP monitor on the Appwrite console URL
Instant alerts	Slack/webhook notifications on down + recovery
Container self-healing	Docker Compose `healthcheck` + restart policy
Public status page	Vigilmon status page for API consumers

Appwrite's built-in /v1/health API does most of the heavy lifting. The key is checking each service independently — a database failure that keeps the API process alive is invisible to a single top-level monitor but immediately visible when you watch /v1/health/db separately.

Get started free at vigilmon.online — your first monitor is running in under a minute.

Monitoring Your Strapi CMS with Vigilmon (Free, Multi-Region)

Vigilmon — Tue, 30 Jun 2026 07:48:48 +0000

Monitoring Your Strapi CMS with Vigilmon (Free, Multi-Region)

Strapi is the go-to open-source headless CMS for teams that want full control over their content API. When it works, it's invisible — your Next.js front end, mobile app, and marketing site all pull content seamlessly.

When it goes down, all of them break at once.

This guide covers how to expose Strapi's built-in health endpoints, set up external uptime monitoring from multiple regions with Vigilmon, and get alerted the moment something goes wrong — before a client or user tells you.

Why Strapi monitoring is different from a regular web app

Strapi is infrastructure. A typical SaaS app only breaks users of that one app. Strapi outages cascade:

Frontend sites return empty pages or crash entirely
E-commerce storefronts lose product data
Mobile apps fail to load dynamic content
Scheduled content publishes are silently missed

Standard process monitors won't catch this. You need external checks that verify Strapi is actually accepting HTTP requests and returning valid responses.

Step 1: Understand Strapi's health endpoints

Strapi ships with two built-in health routes. No code needed — they're ready out of the box.

`/_health`

The primary health endpoint. Returns HTTP 200 with a plain text response when Strapi is running:

curl https://your-strapi.com/_health
# Strapi is alive

Returns 503 or a connection error when Strapi is down. This is the endpoint you'll point your external monitor at.

`/api/health` (Strapi v5+)

Starting with Strapi v5, there's a JSON-formatted health route under /api/health:

curl https://your-strapi.com/api/health
# {"status":"healthy","time":"2026-06-30T08:00:00.000Z","degraded":false}

If you're on v5+, prefer this endpoint — the structured JSON lets you assert on the response body, not just the HTTP status code.

Verify your database is included

The built-in health endpoints confirm the Node.js process is alive but don't always surface database connectivity issues. To catch DB failures, add a lightweight custom health route:

// src/api/health/routes/health.js
module.exports = {
  routes: [
    {
      method: 'GET',
      path: '/health/detailed',
      handler: 'health.check',
      config: { auth: false },
    },
  ],
};

// src/api/health/controllers/health.js
module.exports = {
  async check(ctx) {
    try {
      // Test database connectivity
      await strapi.db.connection.raw('SELECT 1');
      ctx.body = { status: 'ok', database: 'ok' };
    } catch (err) {
      ctx.status = 503;
      ctx.body = { status: 'degraded', database: 'error', detail: err.message };
    }
  },
};

curl https://your-strapi.com/health/detailed
# {"status":"ok","database":"ok"}

Step 2: Set up Vigilmon HTTP monitoring

With your health endpoint live, point Vigilmon at it:

Sign up at vigilmon.online — free tier, no credit card required
Click New Monitor → HTTP
Enter https://your-strapi.com/_health (or /api/health for v5+)
Set the check interval (5 minutes on the free tier)
Save

Vigilmon probes from multiple geographic regions simultaneously. If your Strapi instance is unreachable from any region, it opens an incident immediately.

Add a keyword monitor for deeper assurance

For Strapi v5's JSON response, add a second monitor with keyword matching:

New Monitor → Keyword
URL: https://your-strapi.com/api/health
Keyword to match: "status":"healthy"
If the keyword is absent, Vigilmon treats it as a failure

This catches the edge case where Strapi returns HTTP 200 but serves an error page or garbled output — which can happen after a failed plugin load.

Recommended monitor set for Strapi

Monitor	URL	Type	What it catches
Strapi health	`/_health`	HTTP	Process down, port not listening
API health (v5+)	`/api/health`	Keyword	Degraded startup, plugin errors
Database health	`/health/detailed`	Keyword	PostgreSQL/MySQL/SQLite down
Admin panel	`/admin`	HTTP	Admin UI broken (bad deploy)

Step 3: Monitor scheduled content publishing

Strapi's scheduled publishing feature silently fails when something goes wrong with the cron internals. Catch this with heartbeat monitoring.

Create a custom scheduled job that pings Vigilmon on each successful publish cycle:

// config/cron-tasks.js
const axios = require('axios');

module.exports = {
  publishHeartbeat: {
    task: async ({ strapi }) => {
      try {
        // Find and publish any content scheduled for now
        const now = new Date();
        const scheduled = await strapi.db.query('api::article.article').findMany({
          where: {
            publishedAt: null,
            scheduledAt: { $lte: now },
          },
        });

        for (const item of scheduled) {
          await strapi.entityService.update('api::article.article', item.id, {
            data: { publishedAt: now },
          });
        }

        // Ping heartbeat only on success
        const heartbeatUrl = process.env.PUBLISH_HEARTBEAT_URL;
        if (heartbeatUrl) {
          await axios.get(heartbeatUrl, { timeout: 10000 });
        }
      } catch (err) {
        strapi.log.error('publishHeartbeat failed:', err);
        // No ping — the missed ping is the alert
      }
    },
    options: {
      rule: '*/5 * * * *', // every 5 minutes
    },
  },
};

In Vigilmon:

New Monitor → Heartbeat
Set the expected interval to 10 minutes (double the cron interval — gives you a buffer)
Copy the unique ping URL
Add to your environment:

# .env
PUBLISH_HEARTBEAT_URL=https://vigilmon.online/api/heartbeat/your-unique-token

Now if the scheduled publish cron stops firing — because Strapi crashed and restarted, or the cron plugin threw an error — Vigilmon alerts you within one missed interval.

Step 4: Configure alert delivery

Set up where Vigilmon sends alerts when Strapi goes down.

Slack:

Create an incoming webhook in your Slack workspace
In Vigilmon: Notifications → New Channel → Slack
Paste your webhook URL and enable it on your monitors

Email:

In Vigilmon: Notifications → New Channel → Email
Add your email address (or your whole team's)

When Strapi goes down, you'll receive:

🔴 DOWN: your-strapi.com/_health
Status: Connection refused
Regions: US-East, EU-West, AP-Southeast
Started: 2 minutes ago

And recovery:

✅ RECOVERED: your-strapi.com/_health is back UP
Total downtime: 6 minutes

Step 5: Create a public status page

Strapi powers public-facing content. Your content team and external developers using your API deserve visibility into uptime.

In Vigilmon:

Status Pages → New Status Page
Name it (e.g. "Content API Status")
Add your Strapi health monitors
Save and copy the public URL

Add the status page URL to your developer docs, your Strapi admin welcome message, or your README:

## API Status

Real-time status: https://status.yourdomain.com

Step 6: Self-hosted Strapi — docker-compose health checks

If you run Strapi via Docker, wire up a container-level health check so failed containers are restarted automatically:

# docker-compose.yml
services:
  strapi:
    image: your-strapi-image
    healthcheck:
      test: ["CMD", "wget", "--quiet", "--tries=1", "--spider", "http://localhost:1337/_health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 60s
    restart: unless-stopped

This gives you two layers:

Docker restarts the container if it becomes unhealthy
Vigilmon alerts you if the whole host is unreachable or the restart loop isn't resolving the issue

What you've built

What	How
Built-in health check	`/_health` or `/api/health` — no code needed
Database health	Custom `/health/detailed` route with DB query
External uptime monitoring	Vigilmon HTTP monitor (multi-region)
Content publish monitoring	Heartbeat ping after each successful cron run
Instant alerts	Slack/email notifications on down + recovery
Public status page	Vigilmon status page for your API consumers
Container health	Docker Compose `healthcheck` directive

Your Strapi instance is now visible. The next time the Node.js process crashes, the database connection pool exhausts, or a bad deploy breaks the admin panel, you'll know about it in under five minutes.

Get started free at vigilmon.online — your first monitor is running in under a minute.

Monitoring AWS ECS/Fargate Containers with Vigilmon

Vigilmon — Tue, 30 Jun 2026 07:06:36 +0000

Monitoring AWS ECS/Fargate Containers with Vigilmon

AWS ECS and Fargate handle container orchestration, auto-scaling, and self-healing. But "self-healing" has limits — ECS can restart a failed task, but it can't tell you the restart happened, or that your load balancer was routing to a broken target for 3 minutes before it did.

External monitoring fills that gap. Vigilmon probes your container's public URL from outside AWS, catches outages that CloudWatch misses, and sends alerts the moment something breaks.

This tutorial covers:

A health check route in your container
ECS task definition health check configuration
Vigilmon external HTTP monitoring
Alerts on ECS task failure
Heartbeat monitoring for ECS Scheduled Tasks

Step 1: Add a health check route to your container

Every container that serves HTTP traffic needs a /health endpoint. This is used both by ECS/ALB internally and by Vigilmon externally.

Node.js / Express:

// src/health.js
app.get('/health', async (req, res) => {
  const checks = {};
  let healthy = true;

  // Check database if used
  try {
    await db.query('SELECT 1');
    checks.database = 'ok';
  } catch {
    checks.database = 'error';
    healthy = false;
  }

  res.status(healthy ? 200 : 503).json({
    status: healthy ? 'ok' : 'degraded',
    checks,
    timestamp: new Date().toISOString(),
  });
});

Python / FastAPI:

# app/health.py
from fastapi import APIRouter, Response
from datetime import datetime

router = APIRouter()

@router.get("/health")
async def health(response: Response):
    checks = {}
    healthy = True

    try:
        # check your DB/cache
        checks["database"] = "ok"
    except Exception:
        checks["database"] = "error"
        healthy = False
        response.status_code = 503

    return {
        "status": "ok" if healthy else "degraded",
        "checks": checks,
        "timestamp": datetime.utcnow().isoformat(),
    }

Go:

// internal/health/handler.go
package health

import (
    "encoding/json"
    "net/http"
    "time"
)

func Handler(w http.ResponseWriter, r *http.Request) {
    status := map[string]interface{}{
        "status":    "ok",
        "timestamp": time.Now().UTC().Format(time.RFC3339),
    }
    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(status)
}

Keep the health endpoint fast — ECS uses it for routing decisions and slow checks delay recovery.

Step 2: Configure health checks in your task definition

ECS supports container-level health checks directly in your task definition. Add this to your taskDefinition.json or CDK/Terraform config:

JSON task definition:

{
  "containerDefinitions": [
    {
      "name": "app",
      "image": "your-ecr-image:latest",
      "healthCheck": {
        "command": [
          "CMD-SHELL",
          "curl -f http://localhost:8080/health || exit 1"
        ],
        "interval": 30,
        "timeout": 5,
        "retries": 3,
        "startPeriod": 60
      },
      "portMappings": [
        { "containerPort": 8080, "protocol": "tcp" }
      ]
    }
  ]
}

Terraform:

resource "aws_ecs_task_definition" "app" {
  family = "app"

  container_definitions = jsonencode([{
    name  = "app"
    image = "your-ecr-image:latest"

    healthCheck = {
      command     = ["CMD-SHELL", "curl -f http://localhost:8080/health || exit 1"]
      interval    = 30
      timeout     = 5
      retries     = 3
      startPeriod = 60
    }

    portMappings = [{ containerPort = 8080 }]
  }])
}

startPeriod (60 seconds) prevents ECS from killing a container during initialization. Adjust it to match your actual cold-start time.

Step 3: Configure ALB health checks

If your ECS service sits behind an Application Load Balancer, configure ALB target group health checks to use the same endpoint:

AWS Console:

Go to EC2 → Target Groups → your target group
Click Health checks → Edit
Set Health check path to /health
Set Success codes to 200
Set Interval to 30 seconds, Threshold to 2

Terraform:

resource "aws_lb_target_group" "app" {
  name     = "app-tg"
  port     = 8080
  protocol = "HTTP"
  vpc_id   = var.vpc_id

  health_check {
    path                = "/health"
    healthy_threshold   = 2
    unhealthy_threshold = 3
    interval            = 30
    timeout             = 5
    matcher             = "200"
  }
}

ALB health checks control routing. Vigilmon health checks control your alerting. Both should point to the same endpoint.

Step 4: Set up Vigilmon external monitoring

ECS health checks are internal — they run inside the VPC. You also need an external probe that monitors your service from the internet.

Connect your ECS service to Vigilmon:

Sign up at vigilmon.online — free, no card required
Click New Monitor → HTTP
URL: https://api.yourdomain.com/health (your ALB or CloudFront URL)
Check interval: 1 minute (paid) or 5 minutes (free)
Expected status: 200
Save

Vigilmon catches things CloudWatch and ECS health checks miss:

ALB misconfiguration (target group removed from listener)
Security group changes blocking traffic
Route 53 DNS failures
CloudFront distribution errors
Certificate expiry

These are control-plane failures where the container is healthy but external traffic can't reach it.

Step 5: Configure alerts

In Vigilmon, go to Notifications → New Channel:

Slack:

Create an incoming webhook at api.slack.com/apps
Paste the webhook URL into Vigilmon
Enable it on your ECS service monitors

Email:

Add email address as notification channel
Enable on monitors

PagerDuty (for on-call rotation):

Create a Vigilmon integration in PagerDuty
Add the integration key in Vigilmon's notification settings

When ECS task replacement causes brief downtime:

🔴 DOWN: api.yourdomain.com/health
Status: 503
Duration: 45s

This is normal during ECS rolling updates. Use Vigilmon's Confirm Down After setting to suppress alerts for brief replacement windows:

Set Confirm Down After to 2 failures
This ignores single-probe failures from task replacement

Step 6: CloudWatch → Vigilmon alert routing

For task-level failures (not service-level), you can combine CloudWatch alarms with Vigilmon:

Create a CloudWatch alarm for unhealthy ECS tasks:

resource "aws_cloudwatch_metric_alarm" "ecs_unhealthy_tasks" {
  alarm_name          = "ecs-unhealthy-tasks"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 2
  metric_name         = "UnhealthyHostCount"
  namespace           = "AWS/ApplicationELB"
  period              = 60
  statistic           = "Maximum"
  threshold           = 0

  dimensions = {
    TargetGroup  = aws_lb_target_group.app.arn_suffix
    LoadBalancer = aws_lb.app.arn_suffix
  }

  alarm_actions = [aws_sns_topic.alerts.arn]
}

Route the SNS topic to Vigilmon's webhook receiver (available in Vigilmon's integration settings) or to Slack directly. This gives you ECS-level task health on top of Vigilmon's external probe.

Step 7: Heartbeat monitoring for ECS Scheduled Tasks

ECS Scheduled Tasks (cron jobs running on Fargate) aren't covered by HTTP monitoring. If a scheduled task fails silently, nothing external detects it.

Add a heartbeat ping at the end of each successful run:

// tasks/sync.js
import fetch from 'node-fetch';

async function main() {
  try {
    await runSyncJob();

    const heartbeatUrl = process.env.VIGILMON_SYNC_HEARTBEAT;
    if (heartbeatUrl) {
      await fetch(heartbeatUrl, { method: 'GET' });
    }

    console.log('Sync complete');
    process.exit(0);
  } catch (err) {
    console.error('Sync failed:', err);
    process.exit(1);
  }
}

async function runSyncJob() {
  // your scheduled work
}

main();

Pass the heartbeat URL as a task definition environment variable:

{
  "environment": [
    {
      "name": "VIGILMON_SYNC_HEARTBEAT",
      "value": "https://vigilmon.online/heartbeat/your-monitor-id"
    }
  ]
}

Or store it in AWS Secrets Manager and reference it as a secret:

{
  "secrets": [
    {
      "name": "VIGILMON_SYNC_HEARTBEAT",
      "valueFrom": "arn:aws:secretsmanager:us-east-1:123456789:secret:vigilmon-heartbeat"
    }
  ]
}

In Vigilmon, create a Heartbeat Monitor:

Click New Monitor → Heartbeat
Set the interval to match your ECS cron schedule
Copy the ping URL
Add it to your task definition environment

Step 8: Public status page

Go to Status Pages → New Status Page in Vigilmon, add all your ECS service monitors, and publish:

Service issues? https://status.yourdomain.com

Each monitor generates a live badge:

![API Status](https://vigilmon.online/badge/your-monitor-slug)

What you've built

What	How
Health endpoint	Container-native `/health` route
ECS task health	Task definition `healthCheck`
ALB routing protection	Target group health check
External uptime monitoring	Vigilmon HTTP monitor on public URL
Task failure alerts	Vigilmon + optional CloudWatch SNS routing
Slack/email/PagerDuty alerts	Vigilmon notification channels
Scheduled task monitoring	Heartbeat ping in ECS cron tasks
Status page	Vigilmon public status page

ECS handles self-healing. Vigilmon handles visibility. CloudWatch tells you what happened after — Vigilmon tells you the moment it does.

Next steps

Add Vigilmon monitors for each ECS service environment (prod, staging, canary)
Watch response time trends to catch gradual container resource exhaustion before it causes failures
Add heartbeat monitors for every ECS Scheduled Task that does important work — billing jobs, data sync, report generation

Get started free at vigilmon.online.

Monitoring Your Render.com Application with Vigilmon

Vigilmon — Tue, 30 Jun 2026 07:06:00 +0000

Monitoring Your Render.com Application with Vigilmon

Render is a popular Heroku alternative that handles build, deploy, and TLS automatically. But like Heroku before it, free and starter-tier Render services spin down after inactivity — and when a real outage hits, Render's internal dashboards don't page you.

You need external monitoring: something that probes your live URL from outside Render's infrastructure, knows the difference between a cold start and a crash, and wakes you up when something actually breaks.

This tutorial covers:

A health endpoint for Render web services
Vigilmon HTTP monitoring with cold-start tolerance
Alerts that don't false-fire on every spin-up
Heartbeat monitoring for Render cron jobs

Step 1: Add a health endpoint to your app

Every Render web service needs a /health route that returns 200 when the app is running correctly and 503 when something is wrong.

Node.js / Express:

// server.js
import express from 'express';

const app = express();

app.get('/health', async (req, res) => {
  try {
    // optional: check DB or cache connectivity here
    res.json({
      status: 'ok',
      env: process.env.RENDER_SERVICE_NAME || 'local',
      timestamp: new Date().toISOString(),
    });
  } catch {
    res.status(503).json({ status: 'error' });
  }
});

app.listen(process.env.PORT || 3000);

Python / Flask:

# app.py
from flask import Flask, jsonify
import os, datetime

app = Flask(__name__)

@app.route('/health')
def health():
    return jsonify({
        'status': 'ok',
        'service': os.getenv('RENDER_SERVICE_NAME', 'app'),
        'timestamp': datetime.datetime.utcnow().isoformat(),
    })

Python / FastAPI:

# main.py
from fastapi import FastAPI, Response
import os, datetime

app = FastAPI()

@app.get("/health")
def health(response: Response):
    # check dependencies; set response.status_code = 503 on failure
    return {
        "status": "ok",
        "service": os.getenv("RENDER_SERVICE_NAME", "app"),
        "timestamp": datetime.datetime.utcnow().isoformat(),
    }

Render injects PORT and RENDER_SERVICE_NAME automatically. Always bind to PORT.

Step 2: Enable Render's native health check

Render supports health check paths that control deploy promotion. In your service settings:

Go to Settings → Health & Alerts
Set Health Check Path to /health
Set the failure threshold (e.g., 3 consecutive failures)

This prevents a broken deploy from going live. It doesn't give you external alerts — that's what Vigilmon handles.

Step 3: Set up Vigilmon monitoring

With your app deployed on Render, connect it to Vigilmon:

Sign up at vigilmon.online — free, no card required
Click New Monitor → HTTP
URL: https://your-service.onrender.com/health
Check interval: 1 minute (paid) or 5 minutes (free)
Expected status: 200
Save

If you've connected a custom domain, monitor that instead — it covers both your DNS and your Render service:

https://api.yourdomain.com/health

Step 4: Tune for cold starts

Render's free and starter web services spin down after 15 minutes of inactivity. The first request after a spin-down triggers a cold start that can take 10–30 seconds.

To avoid false alerts from cold starts:

In Vigilmon's monitor settings, set Timeout to 30 seconds
Set Confirm Down After to 2 consecutive failures

With these settings, Vigilmon waits for two consecutive failures before alerting. A single cold start shows up as a slow response, not a false-positive outage.

If you're on a Render paid plan with always-on instances, you can lower the timeout to 10 seconds for faster real outage detection.

Step 5: Configure alerts

In Vigilmon, go to Notifications → New Channel:

Slack:

1. Create an incoming webhook at api.slack.com/apps
2. Paste the URL into Vigilmon → Notifications → Slack
3. Enable it on your Render monitors

Email:

1. Add your address as a notification channel
2. Enable on monitors

What you see when a real outage happens:

🔴 DOWN: your-service.onrender.com/health
Status: 0 (connection timeout)
Region: EU-West
5 minutes ago

And on recovery:

✅ RECOVERED: your-service.onrender.com/health
Downtime: 12 minutes

The key difference from a cold start: a real outage produces multiple consecutive failures across different Vigilmon regions. A cold start produces a slow (but successful) response from one region.

Step 6: Monitor Render cron jobs

Render supports cron jobs as a separate service type. A cron job that silently crashes or stops running won't surface in your HTTP monitor — the web service stays green while background work stops.

Add a heartbeat ping to your cron job:

Node.js:

// cron/main.js
import fetch from 'node-fetch';

async function main() {
  try {
    await runScheduledWork();

    const heartbeatUrl = process.env.VIGILMON_CRON_HEARTBEAT;
    if (heartbeatUrl) {
      await fetch(heartbeatUrl);
    }
  } catch (err) {
    console.error('Cron job failed:', err);
    process.exit(1);
  }
}

async function runScheduledWork() {
  // your job logic
}

main();

Python:

# cron/main.py
import os, requests

def main():
    try:
        run_scheduled_work()

        heartbeat_url = os.getenv('VIGILMON_CRON_HEARTBEAT')
        if heartbeat_url:
            requests.get(heartbeat_url, timeout=5)
    except Exception as e:
        print(f'Cron job failed: {e}')
        raise

def run_scheduled_work():
    pass  # your logic

if __name__ == '__main__':
    main()

In Vigilmon:

Click New Monitor → Heartbeat
Set the interval to match your cron schedule
Copy the ping URL
Add VIGILMON_CRON_HEARTBEAT=<url> as a Render environment variable

Step 7: Watch for spin-down patterns in Render

Render free services spin down on idle. If your health check interval is 5 minutes (free Vigilmon tier), the service may spin down between checks and Vigilmon's probe will wake it up each time — masking the spin-down behavior.

To understand your app's idle behavior:

Add Vigilmon's Response Time chart to your dashboard
Look for latency spikes on a regular pattern — those are cold starts
Upgrade Render (to always-on) or Vigilmon (1-minute interval) if the pattern concerns you

The charts give you evidence for the upgrade conversation.

Step 8: Public status page

Go to Status Pages → New Status Page in Vigilmon, add your monitors, and share the URL:

Something broken? Check https://status.yourdomain.com

Each monitor generates a live status badge:

![Service Status](https://vigilmon.online/badge/your-monitor-slug)

What you've built

What	How
Health endpoint	Framework-native `/health` route
Render deploy protection	Render health check path
External uptime monitoring	Vigilmon HTTP monitor
Cold-start tolerance	30s timeout + 2-failure confirm threshold
Slack/email alerts	Vigilmon notification channels
Cron job monitoring	Heartbeat ping in cron service
Spin-down visibility	Vigilmon response time charts
Status page	Vigilmon public status page

Render takes care of deployment. Vigilmon takes care of watching it from the outside.

Next steps

Add separate Vigilmon monitors for staging and production Render services
Set up response time alerts — Render cold starts that regularly take >10 seconds are a signal to upgrade to always-on
Add heartbeats for every Render cron service that does work you'd notice missing

Get started free at vigilmon.online.

Monitoring Your Railway.app Deployment with Vigilmon

Vigilmon — Tue, 30 Jun 2026 07:05:08 +0000

Monitoring Your Railway.app Deployment with Vigilmon

Railway makes deployment fast. You push code, Railway builds and runs it. But Railway doesn't tell you when your app goes down from the outside — it only shows you internal metrics and logs. If your deployed service starts returning errors or timing out, you need an external monitor to catch it.

This tutorial covers:

A health check route for Node/Python/Go apps on Railway
Vigilmon HTTP monitoring for your Railway service URL
Alert configuration for downtime and recovery
Heartbeat monitoring for Railway cron jobs

Step 1: Add a health check route to your app

Railway auto-generates a public URL for each service. Your monitor will probe this URL, so you need a lightweight route that returns 200 when healthy and something else when not.

Node.js / Express:

// app.js
import express from 'express';

const app = express();

app.get('/health', (req, res) => {
  res.json({
    status: 'ok',
    service: process.env.RAILWAY_SERVICE_NAME || 'app',
    region: process.env.RAILWAY_REGION || 'unknown',
    timestamp: new Date().toISOString(),
  });
});

app.listen(process.env.PORT || 3000);

Python / FastAPI:

# main.py
from fastapi import FastAPI
import os, datetime

app = FastAPI()

@app.get("/health")
def health():
    return {
        "status": "ok",
        "service": os.getenv("RAILWAY_SERVICE_NAME", "app"),
        "timestamp": datetime.datetime.utcnow().isoformat(),
    }

Go:

// main.go
package main

import (
    "encoding/json"
    "net/http"
    "os"
    "time"
)

func healthHandler(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(map[string]string{
        "status":    "ok",
        "service":   os.Getenv("RAILWAY_SERVICE_NAME"),
        "timestamp": time.Now().UTC().Format(time.RFC3339),
    })
}

func main() {
    port := os.Getenv("PORT")
    if port == "" {
        port = "8080"
    }
    http.HandleFunc("/health", healthHandler)
    http.ListenAndServe(":"+port, nil)
}

Railway injects PORT automatically — always bind to it instead of hardcoding.

Step 2: Configure Railway's health check

Railway supports native health checks that control whether traffic is routed to your service. In your Railway service settings:

Go to Settings → Deploy → Health Check Path
Set it to /health
Set Health Check Timeout to 300 seconds

This prevents Railway from routing traffic to a broken deploy. Combined with Vigilmon's external monitoring, you get both internal routing protection and external alerting.

Step 3: Set up Vigilmon monitoring

Once your app is deployed and the Railway URL is live, connect it to Vigilmon:

Sign up at vigilmon.online — free, no card required
Click New Monitor → HTTP
URL: https://your-service.up.railway.app/health
Check interval: 1 minute (paid) or 5 minutes (free)
Expected status: 200
Save

You can also add monitors for your custom domain if you've set one up:

https://api.yourdomain.com/health     → production service
https://staging.yourdomain.com/health → staging service

Monitoring both environments means you catch staging regressions before they hit production.

Step 4: Handle Railway cold starts and spin-downs

Railway's hobby plan services spin down after inactivity. When a request hits a spun-down service, it takes a few seconds to start — Vigilmon may see this as a timeout depending on your threshold.

To avoid false alerts:

In Vigilmon, set Timeout to 15 seconds (instead of the default 5–10)
Set Confirm Down After to 2 consecutive failures before alerting

This gives Railway enough time to spin up on the first probe while still catching real outages quickly.

If you're on a Railway paid plan with always-on services, you can keep the default timeout.

Step 5: Alert configuration

In Vigilmon, go to Notifications → New Channel:

Slack alerts:

Create an incoming webhook at api.slack.com/apps
Paste the webhook URL into Vigilmon
Enable it on your Railway monitors

Email alerts:

Add your email as a notification channel
Enable on monitors

When your Railway service goes down:

🔴 DOWN: your-service.up.railway.app/health
Status: 503
Region: US-East
2 minutes ago

And when Railway restarts it and it recovers:

✅ RECOVERED: your-service.up.railway.app/health
Downtime: 4 minutes

Step 6: Monitor Railway cron jobs with heartbeats

Railway supports cron jobs as separate services. If a cron job stops running silently — due to a crash, a missed schedule, or a Railway outage — your HTTP monitor won't catch it.

Use a heartbeat: the job pings a Vigilmon URL at the end of every successful run. If Vigilmon doesn't receive a ping within the expected window, it alerts you.

Node.js cron job with heartbeat:

// cron.js
import fetch from 'node-fetch';

async function runJob() {
  try {
    await doWork();

    const heartbeatUrl = process.env.VIGILMON_CRON_HEARTBEAT;
    if (heartbeatUrl) {
      await fetch(heartbeatUrl);
    }
    console.log('Job complete');
  } catch (err) {
    console.error('Job failed:', err);
    process.exit(1);
  }
}

async function doWork() {
  // your job logic
}

runJob();

In Vigilmon:

Click New Monitor → Heartbeat
Set the interval to match your Railway cron schedule (e.g., 1 hour)
Copy the ping URL
Add VIGILMON_CRON_HEARTBEAT=<url> as a Railway environment variable

Step 7: Public status page

Go to Status Pages → New Status Page in Vigilmon, add your Railway service monitors, and publish the URL. Drop it in your app's error pages or README:

Service issues? Check our status page: https://status.yourdomain.com

Each monitor also generates a live badge:

![Railway Service Status](https://vigilmon.online/badge/your-monitor-slug)

What you've built

What	How
Health endpoint	Framework-native `/health` route
Railway deploy protection	Railway health check path
External uptime monitoring	Vigilmon HTTP monitor
Cold-start tolerance	Vigilmon timeout + confirm-down settings
Slack/email alerts	Vigilmon notification channels
Cron job monitoring	Heartbeat ping in cron handler
Status page	Vigilmon public status page

Railway handles deployment. Vigilmon handles visibility. Together they give you a complete picture of whether your service is actually working.

Next steps

Add separate monitors for each Railway environment (production, staging, preview)
Watch Vigilmon's response time charts — Railway cold starts show up as latency spikes
Add heartbeat monitors for every Railway cron service that does important work

Get started free at vigilmon.online.

Monitoring Your Qwik/QwikCity Application with Vigilmon

Vigilmon — Tue, 30 Jun 2026 07:05:07 +0000

Monitoring Your Qwik/QwikCity Application with Vigilmon

Qwik's resumability model means your app boots fast. That's great for users — but it doesn't protect you from the moment your server goes down or your deployment breaks. You still need an external eye watching your production URL around the clock.

This tutorial walks through:

A /health server route in QwikCity
An HTTP uptime monitor in Vigilmon
A keyword monitor that confirms your app is actually rendering
Slack or email alerts when anything goes wrong

The full setup takes about 15 minutes.

Step 1: Add a health endpoint in QwikCity

QwikCity uses file-based routing. Server routes live in src/routes/ and export request handlers. Add a health/ route that returns a JSON status:

// src/routes/health/index.ts
import type { RequestHandler } from '@builder.io/qwik-city';

export const onGet: RequestHandler = ({ json }) => {
  json(200, {
    status: 'ok',
    service: 'qwik-app',
    timestamp: new Date().toISOString(),
  });
};

Start your dev server and verify:

npm run dev
curl http://localhost:5173/health
# {"status":"ok","service":"qwik-app","timestamp":"..."}

For a deeper health check that exercises your data layer:

// src/routes/health/index.ts
import type { RequestHandler } from '@builder.io/qwik-city';

export const onGet: RequestHandler = async ({ json, env }) => {
  const checks: Record<string, string> = {};
  let healthy = true;

  // Example: check a database or external API
  try {
    const dbUrl = env.get('DATABASE_URL');
    if (dbUrl) {
      // perform a lightweight ping query here
      checks['database'] = 'ok';
    }
  } catch {
    checks['database'] = 'error';
    healthy = false;
  }

  json(healthy ? 200 : 503, {
    status: healthy ? 'ok' : 'degraded',
    checks,
    timestamp: new Date().toISOString(),
  });
};

A 503 on failure means Vigilmon will detect the outage immediately without needing a body check.

Step 2: Set up an HTTP monitor in Vigilmon

Deploy your QwikCity app (Node adapter, Cloudflare Pages, Vercel, etc.) then connect it to Vigilmon:

Sign up at vigilmon.online — free, no card required
Click New Monitor → HTTP
URL: https://yourapp.example.com/health
Check interval: 1 minute (paid) or 5 minutes (free)
Expected status: 200
Save

Vigilmon probes from multiple regions. If your /health route returns anything other than 200 — or times out — you get alerted immediately.

Step 3: Add a keyword monitor for the home page

Your health endpoint checks the server. A keyword monitor checks that your Qwik app is actually rendering HTML correctly — critical since Qwik's HTML-streaming output could silently break during a bad deploy.

In Vigilmon:

Click New Monitor → Keyword
URL: https://yourapp.example.com/
Keyword: your app name, a nav label, or any static string that appears in every render
Match type: Contains
Expected status: 200
Save

If your deploy breaks the rendering pipeline but leaves the server running, the HTTP monitor stays green — only the keyword monitor catches it.

Step 4: Configure alerts

Go to Notifications → New Channel in Vigilmon and pick your channel type:

Slack:

Create an incoming webhook at api.slack.com/apps
Paste the URL into Vigilmon's Slack channel config
Enable it on both your monitors

Email:

Add your email address as a notification channel
Enable it on the monitors you want coverage for

When your Qwik app goes down, the alert lands within the check interval:

🔴 DOWN: yourapp.example.com/health
Status: 503
Region: EU-West
3 minutes ago

When it recovers:

✅ RECOVERED: yourapp.example.com/health
Downtime: 6 minutes

For critical production apps, enable both Slack (immediate) and email (paper trail).

Step 5: Heartbeat monitoring for Qwik build jobs or cron tasks

If you run scheduled tasks alongside your QwikCity app — revalidation jobs, data sync, cron endpoints — HTTP monitoring won't catch a silent failure there.

Use QwikCity's onRequest to create a cron-compatible endpoint that pings a Vigilmon heartbeat on success:

// src/routes/api/cron/sync/index.ts
import type { RequestHandler } from '@builder.io/qwik-city';

export const onPost: RequestHandler = async ({ json, env }) => {
  try {
    await runDataSync();

    const heartbeatUrl = env.get('VIGILMON_SYNC_HEARTBEAT');
    if (heartbeatUrl) {
      await fetch(heartbeatUrl);
    }

    json(200, { status: 'synced' });
  } catch (err) {
    json(500, { status: 'error', message: String(err) });
  }
};

async function runDataSync() {
  // your sync logic
}

In Vigilmon, create a Heartbeat Monitor:

Click New Monitor → Heartbeat
Set the expected interval to match your job schedule
Copy the ping URL
Set VIGILMON_SYNC_HEARTBEAT=<url> in your environment

If the job stops running or throws, Vigilmon alerts you after one missed interval.

Step 6: Public status page

Go to Status Pages → New Status Page in Vigilmon, add your monitors, and publish. Drop the URL in your README or error pages so users can self-check:

Service unavailable. Check our status page: https://status.yourapp.example.com

Each monitor also generates a live badge:

![App Status](https://vigilmon.online/badge/your-monitor-slug)

What you've built

What	How
Health endpoint	QwikCity server route at `/health`
HTTP uptime check	Vigilmon HTTP monitor
Rendering check	Vigilmon keyword monitor on home page
Slack/email alerts	Vigilmon notification channels
Cron job monitoring	Heartbeat ping in scheduled handler
Status page	Vigilmon public status page

Your Qwik app is fast. Now it's also visible when it breaks.

Next steps

Add check-specific monitors for any critical API routes your app depends on
Watch response time trends — Vigilmon charts latency over time, and gradual slowdowns are often visible before a full outage
Add a heartbeat for every background job, not just the main one

Get started free at vigilmon.online.

Vigilmon vs Datadog Synthetics: Lightweight Uptime Monitoring vs Full Observability Platform

Vigilmon — Mon, 29 Jun 2026 23:17:49 +0000

Datadog Synthetics is a powerful testing and monitoring product embedded inside one of the most capable observability platforms in the world. Vigilmon is a purpose-built uptime checker. If you're evaluating both, the question isn't which one is technically superior — Datadog Synthetics has more features. The question is whether you're paying for an observatory when all you need is a smoke detector.

This article focuses specifically on the uptime monitoring use case: external checks on HTTP endpoints, TCP ports, and SSL certificates. Within that narrow scope, the comparison tells a surprising story.

What Datadog Synthetics Is

Datadog Synthetics is one of many products inside the Datadog platform. It lets teams run two categories of tests:

API tests — scheduled checks against HTTP endpoints, TCP hosts, UDP sockets, WebSocket connections, SSL certificates, and DNS resolution. These are closest to traditional uptime monitoring.

Browser tests — scripted, headless-browser recordings that simulate real user flows: logging in, adding to cart, completing checkout, submitting a form. These are synthetic user-journey tests, not uptime checks.

Synthetics integrates with the broader Datadog ecosystem: results feed into dashboards, SLO tracking, incident management, and the APM trace explorer. If you're already running Datadog for infrastructure monitoring and APM, adding Synthetics feels natural — everything lives in one platform.

The price of that integration is complexity and cost. Synthetics was designed as an enterprise observability feature, not as a standalone uptime monitoring product.

What Vigilmon Is

Vigilmon is an external uptime monitoring service with a single focus: confirming that your services are reachable and alerting you the moment they are not.

Its defining architectural feature is multi-region consensus: rather than a single probe declaring your service down after one failed check, Vigilmon requires a quorum of geographically distributed probes to agree before firing an alert. This eliminates a category of false positives — regional CDN flaps, transient DNS failures, upstream routing glitches — that cause alert fatigue in single-probe monitoring systems.

Vigilmon monitors HTTP/HTTPS endpoints, TCP ports, SSL certificate expiry, and cron job heartbeats. Alerts go out via Slack, email, or webhooks. A built-in status page is live the moment you add your first monitor. Setup takes under two minutes.

No agent. No SDK. No configuration of alert policies before the first notification.

Pricing: Where the Comparison Gets Stark

Datadog's pricing is notoriously layered. Here's what Synthetics specifically costs:

Datadog Synthetics Pricing

Datadog bills Synthetics separately from its core platform. API tests are charged per 10,000 runs. Browser tests are charged per 1,000 test runs (at significantly higher rates).

Volume	Approximate Cost
API tests — 100K runs/month	~$5
API tests — 1M runs/month	~$50
API tests — 5M runs/month	~$250
Browser tests — 10K runs/month	~$120
Browser tests — 100K runs/month	~$1,200

What that means in practice:

One HTTP monitor at 1-minute intervals generates approximately 43,200 checks per month. Ten monitors = 432,000 checks/month.

At ~$5 per 100,000 API test runs, ten monitors at 1-minute intervals costs roughly $22/month in Synthetics alone — before accounting for the core Datadog platform fee, which starts at $15/host/month for Infrastructure.

That $22/month sounds reasonable until you realize Datadog's platform requires at minimum an Infrastructure subscription to do anything useful. A small team running 5 hosts and 10 uptime monitors is realistically looking at:

Component	Approximate Cost
Infrastructure monitoring (5 hosts)	$75/month
Synthetics (10 monitors, 1-min interval)	~$22/month
Total	~$97/month

And that's the stripped-down configuration, excluding APM, log management, and the other products that make Datadog compelling at scale.

Vigilmon Pricing

Tier	Cost	Monitors	Interval
Free	$0	5 managed / unlimited self-hosted	3 minutes
Pro	~$10–20/month	More monitors	1 minute
Self-hosted	~$5/month VPS	Unlimited	Configurable

For pure uptime monitoring, Vigilmon's free tier covers the same ground as paid Datadog Synthetics at zero cost.

Feature Comparison: Uptime Monitoring Specifically

Stripping away APM, infrastructure monitoring, log management, and everything else Datadog does — and focusing only on external uptime checking:

Feature	Vigilmon	Datadog Synthetics
HTTP/HTTPS monitoring	✅	✅
TCP port monitoring	✅	✅
SSL certificate monitoring	✅	✅
Cron / heartbeat monitoring	✅	❌
Multi-region consensus alerting	✅	❌ (per-location alerts)
Scripted browser tests	❌	✅
Multi-step API flow tests	❌	✅
SLO tracking	❌	✅ (via Datadog SLOs)
Integrated status page	✅ (included)	❌ (StatusPage is separate)
Self-hostable	✅	❌
Standalone product	✅	❌ (requires Datadog platform)
Free tier for uptime	5 monitors, permanent	No — paid per test run
Setup time	~2 minutes	15–45 minutes

The two features Datadog Synthetics offers that Vigilmon does not are scripted browser tests and multi-step API flow monitoring. These are meaningful capabilities for teams that need to validate complex user journeys. For teams that need to know "is the endpoint responding?", they're irrelevant.

The False Positive Problem

Here's a practical concern that rarely shows up in feature comparison tables: alert quality.

Datadog Synthetics runs checks from selected "probe locations" — their managed infrastructure in various regions. Each location evaluates independently. If a check from the aws:us-east-1 probe fails, Datadog alerts you. It doesn't matter whether the endpoint is perfectly healthy from every other location in the world.

This design is standard across most uptime monitoring tools, and it explains why uptime alert fatigue is so common. Regional DNS hiccups, CDN route flaps, probe-side network issues, and ASN peering anomalies all generate alerts for outages that self-resolve in seconds — outages your users never experienced.

Vigilmon's consensus architecture handles this differently. Every check is dispatched simultaneously to multiple geographic probe regions. An alert fires only when a majority of regions agree the service is unreachable. One probe going dark doesn't wake anyone up. Multiple independent vantage points converging on failure? That's a real outage.

For teams already managing Datadog alert noise across infrastructure metrics, APM error rates, and log-based monitors, adding single-probe Synthetics alerts to the mix often makes on-call harder, not easier. Vigilmon's dedicated channel provides a structurally quieter signal for the single most important question: is the service completely down?

Setup Complexity

Getting Datadog Synthetics configured for reliable uptime alerting requires:

Create a Datadog account and subscribe to Infrastructure (prerequisite)
Navigate to Synthetics in the Datadog UI
Create API tests with locations, assertions, retry logic, and frequency settings
Create a Monitor or SLO for alerting — this is separate from the test itself
Configure Notification routing — who gets paged, via which channel, at what threshold
Test that alerts actually fire and route correctly end-to-end

For a team not already inside Datadog, this is 30–60 minutes of configuration before the first alert is trustworthy. For a team already living in Datadog, it's faster — but still non-trivial to get right.

Vigilmon:

Enter a URL
Configure your Slack webhook or email
Click Save

Two minutes, no prior account infrastructure required.

When Datadog Synthetics Is the Right Choice

You're already a Datadog customer. If your team pays for Datadog Infrastructure and APM, adding Synthetics is marginal incremental cost and keeps your monitoring signal in one platform. The SLO integration and correlation with traces and logs is genuinely useful.

You need scripted browser tests. Datadog's browser test recorder lets you capture multi-step user flows and replay them on a schedule — login sequences, checkout funnels, OAuth redirects, multi-page form submissions. If validating user journey continuity is a monitoring requirement, Datadog Synthetics handles that. Vigilmon does not.

You need multi-step API sequences. Chained API calls where step 2 depends on a token from step 1 — authentication flows, session-dependent operations — are supported by Datadog Synthetics via step sequences. This is out of scope for basic uptime monitoring.

You have a dedicated SRE or observability team. Datadog's depth pays off when someone owns the platform. When no one does, most of the investment goes unused.

When Vigilmon Is the Right Choice

You want to know when your site is down. If the question is "can users reach this URL right now?", you don't need a full observability platform. You need an external check with reliable alerting.

You're not already a Datadog customer. Adopting Datadog specifically for uptime monitoring means paying platform-level prices and learning platform-level complexity for a problem Vigilmon solves in two minutes for free.

You want fewer false alarms. Multi-region consensus is a structural advantage that most monitoring tools — including Datadog Synthetics — don't offer. If your team has learned to dismiss alerts, the architecture is the problem, not the configuration.

You need a customer-facing status page. Datadog doesn't include one — StatusPage is a separate Atlassian product. Vigilmon's status page is included, live immediately, and requires no additional configuration.

Budget is a real constraint. At startup or small-team scale, paying for Datadog to get uptime monitoring is paying for a platform you're using at 5% capacity. Vigilmon free covers the use case entirely.

The Complementary Approach

Vigilmon and Datadog aren't mutually exclusive. Many engineering teams run both: Datadog for internal APM, traces, logs, and infrastructure metrics; Vigilmon for clean, dedicated external uptime monitoring on a structurally separate alert channel.

The separation is intentional. Uptime monitoring answers "can users reach the service?" from outside your network. APM answers "what's happening inside the service?" These are different questions, and mixing the signals often makes both harder to act on.

Running Vigilmon alongside Datadog adds zero marginal cost on the free tier and provides an architecturally independent signal that doesn't drown in Datadog's alert volume.

Conclusion

Datadog Synthetics is a feature inside one of the most powerful observability platforms in the industry. If your team is already invested in Datadog and needs scripted browser tests, SLO tracking, and correlation between uptime signals and APM traces, Synthetics is a natural extension.

But for teams evaluating "how do I know when my site is down?" as a standalone question, Datadog Synthetics is the wrong entry point. You'd be onboarding to an enterprise-scale platform, paying platform-level prices, and configuring platform-level alert routing — for a use case that Vigilmon handles in two minutes at no cost.

For the majority of developer teams — startups, indie developers, small agencies, bootstrapped SaaS — Vigilmon delivers accurate, low-noise uptime monitoring without the observability platform overhead.

Start monitoring for free at vigilmon.online — no credit card, no platform subscription, multi-region consensus included.

Vigilmon vs Uptime Kuma: Self-Hosted vs Managed Monitoring

Vigilmon — Mon, 29 Jun 2026 22:14:21 +0000

Uptime Kuma is the darling of the homelab and self-hosted community — and for good reason. It is free, open-source, and genuinely well-designed. But self-hosting a monitoring tool introduces real operational challenges that many teams underestimate until 3 AM when the monitoring server itself is down.

This guide compares Uptime Kuma and Vigilmon directly: who each tool is built for, what you gain by self-hosting, what you give up, and when a managed alternative like Vigilmon makes more sense.

What Is Uptime Kuma?

Uptime Kuma is an open-source, self-hosted monitoring tool created by Louis Lam and released in 2021. It has grown rapidly in popularity on GitHub (45,000+ stars) and is especially popular among homelab users, indie hackers, and developers who prefer to own their infrastructure.

It runs as a Node.js application in Docker, supports a wide variety of check types (HTTP, TCP, ping, DNS, and more), and comes with a polished, real-time dashboard. The appeal is clear: you download it, run it, and it works — completely free, no accounts, no external dependencies.

What Is Vigilmon?

Vigilmon is a managed SaaS uptime monitor designed for developers and SREs who want reliable alerting without operating monitoring infrastructure. Its key technical differentiator is multi-region consensus checking: before firing any alert, Vigilmon requires multiple geographically distributed probe nodes to agree that a target is down.

The Fundamental Trade-off

Uptime Kuma: You own the infrastructure. Complete control, complete privacy, zero recurring cost — but you are also responsible for keeping the monitoring system running.

Vigilmon: Managed infrastructure. You get multi-region redundancy, automatic updates, and zero operational burden — at the cost of direct infrastructure control.

The Self-Hosting Reliability Problem

Here is the uncomfortable truth about self-hosted monitoring: if your monitoring server goes down, you won't know your services are down.

Uptime Kuma runs on a single node. If that node loses power, network connectivity, or memory, monitoring stops. Many Uptime Kuma users end up signing up for a hosted monitoring service just to watch their Uptime Kuma instance.

Vigilmon's probe infrastructure is distributed across multiple regions by design. There is no single point of failure in the check path.

Multi-Region Consensus vs Single-Node Checks

Uptime Kuma checks from wherever you installed it — one machine, one network, one geographic location. If that location has a routing problem or DNS hiccup, every service it monitors will appear to be down, even if all your services are perfectly healthy.

Vigilmon requires consensus across multiple probe regions before firing any alert. A single node's network issue is silently discarded. Every alert you receive corresponds to a genuine, geographically confirmed outage.

Feature Comparison

Feature	Uptime Kuma	Vigilmon
HTTP/HTTPS monitoring	✅	✅
TCP port monitoring	✅	✅
DNS monitoring	✅	❌
Cron / heartbeat monitoring	✅	✅
Multi-region consensus	❌ single node	✅
Response time history	✅	✅
Self-hostable	✅	❌
Free tier	✅ (self-hosted)	✅ managed
Auto-updates	❌ manual	✅
Monitoring redundancy	❌ single server	✅ multi-region
Setup time	20–60 min	< 5 min

Setup Time

Uptime Kuma requires: VPS provisioning, Docker, reverse proxy config, HTTPS/SSL setup, process management. A 30–60 minute process for someone comfortable with Linux server admin; longer for others.

Vigilmon: Sign up, add a monitor URL, done. Under 5 minutes.

Data Ownership

Uptime Kuma's greatest privacy advantage: your monitoring data never leaves your server. This matters for regulated industries, data residency requirements, or teams that simply prefer to own everything.

Vigilmon is a cloud service. Check results and response times are stored on Vigilmon's infrastructure. If data sovereignty is a hard requirement, Uptime Kuma is the correct answer.

Can You Use Both?

Many teams do:

Vigilmon for external monitoring — public APIs and services, checked from multiple regions
Uptime Kuma for internal monitoring — services behind a firewall where external probes can't reach

This gives you multi-region reliability for public surfaces without the single-node limitation.

Who Should Use Uptime Kuma?

You prefer full data ownership
You have homelab or internal-only services
You enjoy self-hosting and maintaining infrastructure
Cost is the primary concern and you already have a VPS
You need niche check types (DNS, Steam servers, etc.)

Who Should Use Vigilmon?

Monitoring reliability is non-negotiable (no single point of failure)
You don't want to maintain monitoring infrastructure
False-positive elimination matters — multi-region consensus only alerts on real outages
Setup speed matters — five minutes vs an hour+
You are a startup or SaaS team on the free tier

Conclusion

Uptime Kuma is excellent for self-hosters who value data ownership and enjoy managing their own infrastructure. It is especially strong for internal services and homelab environments.

Vigilmon trades infrastructure control for reliability, setup speed, and multi-region alert quality — the right fit for developers who want monitoring that works without becoming a second infrastructure project.

Try Vigilmon free at vigilmon.online — up and running in five minutes, no server required.

Setting Up Uptime Monitoring for Remix Apps with Vigilmon

Vigilmon — Mon, 29 Jun 2026 15:57:26 +0000

Setting Up Uptime Monitoring for Remix Apps with Vigilmon

Remix is a full-stack React framework built around web standards — loader functions, actions, and nested routes make it a joy to build with. But when a Remix app goes down, you want to know immediately, not when a user tweets at you.

This tutorial shows you how to add a health-check route to a Remix app and connect it to Vigilmon for multi-region uptime monitoring with email and webhook alerts.

What You'll Build

A Remix _health route that probes real dependencies
A Vigilmon monitor checking the route every 5 minutes from multiple regions
Alert channels (email + Slack webhook) for instant down/up notifications

Prerequisites

Node.js 18+ with a Remix project (or npx create-remix@latest)
A free Vigilmon account (5 monitors free, no credit card)

Step 1: Create a Health-Check Route in Remix

Remix uses file-based routing. Create a dedicated health route that bypasses the React rendering pipeline entirely:

app/
  routes/
    _health.tsx       ← new file
    _index.tsx

// app/routes/_health.tsx
import type { LoaderFunctionArgs } from "@remix-run/node";
import { json } from "@remix-run/node";

export async function loader({ request }: LoaderFunctionArgs) {
  const health = {
    status: "ok",
    timestamp: new Date().toISOString(),
    env: process.env.NODE_ENV,
  };

  return json(health, {
    status: 200,
    headers: {
      "Cache-Control": "no-store",
    },
  });
}

// No default export — this route returns JSON only, no UI

The absence of a default export means Remix won't try to render a React component for this route; it's a pure data endpoint.

Test it:

npx remix dev
curl http://localhost:3000/_health
# {"status":"ok","timestamp":"...","env":"development"}

Why _health instead of health? The leading underscore tells Remix this is a "pathless" route segment — you access it at /_health. You can also use health.tsx for /health — either works fine with Vigilmon.

Step 2: Add Real Dependency Checks

A 200-always endpoint only tells you the Node process is alive. Add checks that test your actual data layer:

// app/routes/_health.tsx
import type { LoaderFunctionArgs } from "@remix-run/node";
import { json } from "@remix-run/node";
import { db } from "~/db.server";          // your Prisma / Drizzle client
import { redis } from "~/redis.server";    // your Redis client (if any)

interface CheckResult {
  ok: boolean;
  latencyMs?: number;
  error?: string;
}

async function checkDatabase(): Promise<CheckResult> {
  const start = Date.now();
  try {
    // Prisma example:
    await db.$queryRaw`SELECT `4;
    // Drizzle example:
    // await db.execute(sql`SELECT 1`);
    return { ok: true, latencyMs: Date.now() - start };
  } catch (err) {
    return { ok: false, error: String(err) };
  }
}

async function checkRedis(): Promise<CheckResult> {
  if (!redis) return { ok: true };          // skip if not configured
  const start = Date.now();
  try {
    await redis.ping();
    return { ok: true, latencyMs: Date.now() - start };
  } catch (err) {
    return { ok: false, error: String(err) };
  }
}

export async function loader({ request }: LoaderFunctionArgs) {
  const [database, cache] = await Promise.allSettled([
    checkDatabase(),
    checkRedis(),
  ]);

  const dbResult = database.status === "fulfilled" ? database.value : { ok: false };
  const cacheResult = cache.status === "fulfilled" ? cache.value : { ok: false };

  const allOk = dbResult.ok && cacheResult.ok;

  return json(
    {
      status: allOk ? "ok" : "degraded",
      checks: { database: dbResult, cache: cacheResult },
      timestamp: new Date().toISOString(),
    },
    {
      status: allOk ? 200 : 503,
      headers: { "Cache-Control": "no-store" },
    }
  );
}

Vigilmon sees the 503 and fires an alert — no manual threshold configuration needed.

Step 3: Deploy Your Remix App

Remix runs on multiple targets. The health route works identically across all of them.

Vercel (zero config):

npm install @remix-run/vercel vercel
npx vercel deploy --prod

Fly.io (Dockerfile-based):

fly launch          # generates fly.toml + Dockerfile
fly deploy

Railway / Render: Connect your GitHub repo and set the start command to npm run start.

After deployment, note your production URL, e.g. https://my-remix-app.vercel.app.

Step 4: Create the Vigilmon Monitor

Log in at vigilmon.online and click + New Monitor.
Monitor Type: HTTP / HTTPS.
URL: https://my-remix-app.vercel.app/_health
Check Interval: 5 minutes.
Expected Status: 2xx (or 200 specifically).
Click Save Monitor.

Vigilmon immediately begins polling from geographically distributed nodes. The multi-region consensus model means a single regional network fault won't trigger a false alert — it only fires when a majority of probes agree the site is unreachable.

Step 5: Configure Alert Channels

Email

Settings → Alert Channels → + Add Channel → Email

Enter your email address. Assign it to the monitor under Monitors → Edit → Alert Channels. You'll receive:

A "DOWN" email within minutes of the first failed check consensus
An "UP" email once the endpoint recovers, with total downtime duration

Slack Webhook

In your Slack workspace: Apps → Incoming Webhooks → Add to Slack, pick a channel, copy the URL.
In Vigilmon: Settings → Alert Channels → + Add Channel → Webhook, paste the URL.
Assign it to your monitor.

Sample down alert your Slack channel receives:

{
  "monitor": "my-remix-app /_health",
  "status": "down",
  "reason": "HTTP 503",
  "body_excerpt": "{\"status\":\"degraded\",\"checks\":{\"database\":{\"ok\":false}}}",
  "regions_failed": ["us-east", "eu-west"],
  "checked_at": "2024-01-15T10:31:00Z"
}

Step 6: Multi-Region Strategy for Remix

Remix on edge runtimes (Cloudflare Workers, Vercel Edge) is often deployed to tens of regions simultaneously. Consider adding region-aware health metadata:

export async function loader({ request }: LoaderFunctionArgs) {
  // Cloudflare: request.cf?.colo; Vercel: process.env.VERCEL_REGION
  const region =
    (request as any).cf?.colo ??
    process.env.VERCEL_REGION ??
    process.env.FLY_REGION ??
    "unknown";

  const allOk = true; // replace with your checks
  return json(
    { status: allOk ? "ok" : "degraded", region, timestamp: new Date().toISOString() },
    { status: allOk ? 200 : 503, headers: { "Cache-Control": "no-store" } }
  );
}

If you use Remix on multiple custom domains (e.g. per-tenant subdomains), add a separate Vigilmon monitor for each — the free tier covers up to 5 monitors.

Step 7: Test the Full Pipeline

Simulate a failure by temporarily forcing a 503:

// _health.tsx — temporary, for testing only
export async function loader() {
  return json({ status: "down", reason: "test failure" }, { status: 503 });
}

Deploy, wait ≥ 5 minutes, and confirm the alert fires. Then revert and confirm the recovery notification.

Step 8: Add a Status Badge (Optional)

Show your uptime status directly in your README:

[![Uptime](https://vigilmon.online/badge/<monitor-id>)](https://vigilmon.online)

Find your monitor ID in the dashboard URL. The badge auto-updates on every check cycle.

Remix-Specific Tips

Loader caching: Always set Cache-Control: no-store on health responses. Remix loaders are sometimes cached by CDNs — a cached 200 will mask a real outage.

Resource routes vs. standard routes: The approach above uses a resource route (no default export). This is the recommended pattern — it keeps health checks off the React rendering critical path and avoids any risk of client-side hydration errors.

Nested routes: If your app uses a root loader that fetches user session data, don't inherit it in the health route. Keep health checks stateless and fast.

Scheduled jobs / background queues: If your Remix app depends on a worker process (Inngest, BullMQ), add a separate endpoint or Vigilmon monitor for the queue health — the web health route won't catch a stalled job processor.

Summary

You've added production-grade monitoring to your Remix application in a few steps:

A _health resource route that tests real dependencies and returns 503 on failure
Vigilmon polling every 5 minutes from multiple global regions
Email and Slack webhook alerts with automatic recovery notifications

The Vigilmon free tier at vigilmon.online requires no credit card and supports up to 5 monitors — perfect for a Remix project in early production.

Using Remix in an interesting stack? Let me know in the comments what you're monitoring.

Uptime Monitoring for Bun Applications with Vigilmon

Vigilmon — Mon, 29 Jun 2026 15:53:20 +0000

Uptime Monitoring for Bun Applications with Vigilmon

Bun's blazing startup speed and drop-in Node.js compatibility make it an appealing runtime for microservices and APIs. But speed at startup doesn't prevent outages at runtime. This tutorial walks you through adding a production-grade health endpoint to a Bun HTTP server and monitoring it with Vigilmon.

What You'll Build

A Bun HTTP server with a /health route that reflects real app state
A Vigilmon monitor with 5-minute polling from multiple regions
Webhook alerts wired to Slack (plus email fallback)

Prerequisites

Bun v1.0+ installed
A free Vigilmon account (5 monitors free, no credit card)

Step 1: Scaffold a Bun HTTP Server

Create a new project:

mkdir bun-monitored-app && cd bun-monitored-app
bun init -i

Replace index.ts with a basic HTTP server:

// index.ts
const PORT = Number(process.env.PORT ?? 3000);

const server = Bun.serve({
  port: PORT,
  async fetch(req) {
    const url = new URL(req.url);

    switch (url.pathname) {
      case "/":
        return new Response("Hello from Bun!", { status: 200 });

      case "/health":
        return healthHandler();

      default:
        return new Response("Not Found", { status: 404 });
    }
  },
});

console.log(`Server running at http://localhost:${server.port}`);

Add the health handler in the same file (or a separate module):

function healthHandler(): Response {
  const payload = JSON.stringify({
    status: "ok",
    runtime: "bun",
    version: Bun.version,
    timestamp: new Date().toISOString(),
  });
  return new Response(payload, {
    status: 200,
    headers: { "Content-Type": "application/json" },
  });
}

Start it:

bun run index.ts

Verify:

curl http://localhost:3000/health
# {"status":"ok","runtime":"bun","version":"1.0.20","timestamp":"..."}

Step 2: Add Real Dependency Checks

A health endpoint that always returns 200 isn't actually useful for monitoring. Wire in checks for the things your app actually depends on:

// health.ts
interface CheckResult {
  ok: boolean;
  latencyMs?: number;
  error?: string;
}

async function pingDatabase(): Promise<CheckResult> {
  // Replace with your actual DB client ping
  // Example shown for a hypothetical SQLite check via bun:sqlite
  try {
    const start = performance.now();
    // const db = new Database("myapp.db");
    // db.query("SELECT 1").get();
    // Placeholder: always ok for this example
    return { ok: true, latencyMs: Math.round(performance.now() - start) };
  } catch (err) {
    return { ok: false, error: String(err) };
  }
}

async function pingCache(): Promise<CheckResult> {
  // Replace with your Redis / Bun KV check
  try {
    const start = performance.now();
    // await redisClient.ping();
    return { ok: true, latencyMs: Math.round(performance.now() - start) };
  } catch (err) {
    return { ok: false, error: String(err) };
  }
}

export async function buildHealthPayload() {
  const [db, cache] = await Promise.all([pingDatabase(), pingCache()]);

  const allOk = db.ok && cache.ok;
  return {
    status: allOk ? "ok" : "degraded",
    checks: { database: db, cache },
    timestamp: new Date().toISOString(),
    httpStatus: allOk ? 200 : 503,
  };
}

Update the handler:

import { buildHealthPayload } from "./health";

case "/health": {
  const payload = await buildHealthPayload();
  const { httpStatus, ...body } = payload;
  return new Response(JSON.stringify(body), {
    status: httpStatus,
    headers: { "Content-Type": "application/json" },
  });
}

Vigilmon treats any non-2xx response as a downtime event, so returning 503 when a check fails will trigger an alert automatically.

Step 3: Deploy Your Bun App

Your app needs a public URL before Vigilmon can monitor it.

Fly.io (works great with Bun):

# fly.toml
app = "my-bun-app"
primary_region = "iad"

[http_service]
  internal_port = 3000
  force_https = true

[[vm]]
  memory = "256mb"
  cpu_kind = "shared"
  cpus = 1

fly launch
fly deploy

Railway / Render also work with zero config — just point them at your repo and set bun run index.ts as the start command.

Note your production URL (e.g. https://my-bun-app.fly.dev).

Step 4: Create a Vigilmon Monitor

Sign in at vigilmon.online.
Click + New Monitor.
Choose HTTP / HTTPS as the monitor type.
Enter your health URL: https://my-bun-app.fly.dev/health.
Set Check Interval to 5 minutes.
Leave Expected HTTP Status as 2xx.
Click Save Monitor.

Vigilmon starts polling from multiple geographic nodes simultaneously. A downtime event is only recorded when a consensus of regions fails — single-location network hiccups won't wake you at 3 AM.

Step 5: Set Up Webhook Alerts

Slack Integration

Create a Slack Incoming Webhook for your alerts channel.
In Vigilmon: Settings → Alert Channels → + Add Channel → Webhook.
Name it "Slack Alerts", paste the webhook URL, save.
Open your monitor → Edit → Alert Channels → select "Slack Alerts".

You'll now receive a Slack message like:

🔴 my-bun-app /health is DOWN

Reason: HTTP 503 — {"status":"degraded","checks":{"database":{"ok":false},...}}

Checked at: 2024-01-15 10:31 UTC

And a recovery message when it comes back up:

🟢 my-bun-app /health is back UP (was down 4m 32s)

Email Alerts

Settings → Alert Channels → + Add Channel → Email. Enter your address and assign it to the monitor. Email is a good fallback even if you already have Slack.

Step 6: Validate the Alert Pipeline

Force a failure locally or in staging to confirm alerts fire end-to-end:

// Temporarily break the health endpoint
case "/health":
  return new Response(JSON.stringify({ status: "down", reason: "test" }), {
    status: 503,
    headers: { "Content-Type": "application/json" },
  });

Deploy this, wait for the next check cycle (≤ 5 min), and verify the Slack/email notification arrives. Then revert and confirm the recovery alert.

Step 7: Protect the Health Endpoint (Optional)

If you don't want the health response (which may reveal internal dependency states) to be publicly readable, you can add token-based gating:

case "/health": {
  const token = req.headers.get("x-health-token");
  if (token !== process.env.HEALTH_TOKEN) {
    return new Response("Unauthorized", { status: 401 });
  }
  const payload = await buildHealthPayload();
  // ...
}

In Vigilmon, set a custom request header under Monitor → Edit → Request Headers:

Header	Value
`x-health-token`	`your-secret-token`

Bun-Specific Tips

Hot reload in dev: Use bun --hot run index.ts during development so code changes reload without restarting — but always test the health endpoint after a hot reload to confirm handlers rewired correctly.

Bun macros: If you use Bun's compile-time macros, make sure your health handler doesn't accidentally import macro-only modules that won't be available at runtime.

Built-in SQLite: Bun ships bun:sqlite — if your app uses it, a SELECT 1 ping in the health check is zero-overhead and catches "database file locked or corrupted" failures early.

Summary

In under 15 minutes you've added production-grade observability to a Bun application:

/health endpoint with real dependency checks (returns 503 on failure)
Vigilmon polling every 5 minutes from multiple regions
Slack + email alerts on down/up state changes

Start free at vigilmon.online — no credit card, up to 5 monitors, 5-minute check intervals.

Building something interesting with Bun? Share what you're monitoring in the comments.

DEV Community: Vigilmon

Monitoring Litestar Python Applications with Vigilmon

Monitoring Litestar Python Applications with Vigilmon

What's different about Litestar monitoring

Step 1: Add a structured health check endpoint

Step 2: Add liveness vs readiness separation

Step 3: Set up external monitoring with Vigilmon

Add a keyword monitor

Recommended Litestar monitor set

Step 4: Heartbeat monitoring for background tasks

Using APScheduler with Litestar's lifespan

Step 5: Configure alerts

Step 6: Docker and Gunicorn setup

Step 7: Public status page

What you've built

Monitoring Temporal.io Workflows with Vigilmon

Monitoring Temporal.io Workflows with Vigilmon

The two failure modes in Temporal deployments

Step 1: Understand Temporal's health endpoints

HTTP health endpoint (Temporal Web UI + gateway)

gRPC health check (the authoritative check)

HTTP wrapper for external monitoring

Step 2: Set up Vigilmon server monitoring

Step 3: Heartbeat monitoring for scheduled workflows

Temporal Go SDK example

Temporal Python SDK example

Set up the Vigilmon heartbeat monitor

Step 4: Monitor the Temporal worker processes

Step 5: Configure alerts

What you've built

Monitoring Your Self-Hosted Appwrite Backend with Vigilmon

Monitoring Your Self-Hosted Appwrite Backend with Vigilmon

What makes Appwrite monitoring distinct

Step 1: Explore Appwrite's health API

Overall health check

Per-service health endpoints

Authentication requirement

Step 2: Set up Vigilmon monitors for each service

Add keyword monitors for status assertion

Step 3: Monitor cloud functions with heartbeats

Example: Node.js cloud function with heartbeat

Step 4: Monitor the Appwrite console

Step 5: Configure alerts

Step 6: Docker Compose health checks

Step 7: Set up a public status page

What you've built

Monitoring Your Strapi CMS with Vigilmon (Free, Multi-Region)

Monitoring Your Strapi CMS with Vigilmon (Free, Multi-Region)

Why Strapi monitoring is different from a regular web app

Step 1: Understand Strapi's health endpoints

/_health

/api/health (Strapi v5+)

Verify your database is included

Step 2: Set up Vigilmon HTTP monitoring

Add a keyword monitor for deeper assurance

Recommended monitor set for Strapi

Step 3: Monitor scheduled content publishing

Step 4: Configure alert delivery

Step 5: Create a public status page

Step 6: Self-hosted Strapi — docker-compose health checks

What you've built

Monitoring AWS ECS/Fargate Containers with Vigilmon

Monitoring AWS ECS/Fargate Containers with Vigilmon

Step 1: Add a health check route to your container

Step 2: Configure health checks in your task definition

Step 3: Configure ALB health checks

Step 4: Set up Vigilmon external monitoring

Step 5: Configure alerts

Step 6: CloudWatch → Vigilmon alert routing

Step 7: Heartbeat monitoring for ECS Scheduled Tasks

Step 8: Public status page

What you've built

Next steps

Monitoring Your Render.com Application with Vigilmon

Monitoring Your Render.com Application with Vigilmon

Step 1: Add a health endpoint to your app

Step 2: Enable Render's native health check

Step 3: Set up Vigilmon monitoring

Step 4: Tune for cold starts

Step 5: Configure alerts

`/_health`

`/api/health` (Strapi v5+)