incident.io's HTTP alert source accepts a firing event, groups it into an alert, and resolves it when a matching resolved event arrives. CronAlert's webhook channel sends one signed POST on down and one on recovery. A twenty-line Cloudflare Worker translates between them: verifies the signature, uses the monitor URL as the deduplication key, sends firing on monitor.down and resolved on monitor.recovered, and carries status code, region, and outage duration into the alert. Routing by team without per-monitor settings.
A Mastodon server has four processes that fail independently and one that fails silently. The web app can serve while streaming is dead and every timeline is frozen. Sidekiq can fall hours behind while the site looks fine. Media storage can 403 every image. Monitor each: /health, the streaming health route, the public instance and nodeinfo endpoints, a Sidekiq queue-latency heartbeat, a canary media object, WebFinger, TLS, and a heartbeat on the Postgres backup.
A logging stack goes down in the one way it cannot report: the logs that would tell you stop arriving. Loki's /ready goes 503 when an ingester cannot flush; Tempo's /ready and Alloy's /-/ready and /-/healthy each describe a different process; a tenant check through X-Scope-OrgID proves the gateway routes; and the only honest answer to whether Loki is ingesting is a canary log line written on a schedule and queried back, reporting to a heartbeat.
A heartbeat alert has exactly one meaning: the ping did not arrive by the deadline. Four things can cause that: the job, the scheduler or platform that runs it, the network the ping crosses, or a monitor configured for a schedule the job no longer keeps. A step-by-step diagnosis using real incident data: ping-rate drops, top-of-the-hour clusters, a vendor API that hung a tick for eight minutes, and a cloud cron outage that skipped fires entirely.
A data pipeline fails quietly: Airbyte is up but the connection has not synced since Tuesday, the dbt Cloud job completed with errors, the dashboard is green and three days stale. Monitor each layer: Airbyte's health endpoint, a sync-success webhook pointed at a CronAlert heartbeat, dbt Cloud's job.run.completed webhook into a heartbeat per job, a dbt Core run that pings only on success, and a content-staleness check on something the pipeline actually updates.
The gateway is where every model request goes first, and where a database outage, an expired provider key, or a bad config reload takes every model down at once. Monitor LiteLLM's unauthenticated liveness and readiness routes, a cheap authenticated check on /v1/models with a monitoring-only virtual key, Open WebUI's /health and its authenticated model list, the real prompt as a heartbeat, TLS expiry, and a heartbeat on the database backup. Why not to put /health on a one-minute monitor.
Uptime Kuma fails silently: a stopped container, a full disk, a host that lost its uplink, or a stalled check loop all look exactly like all green. Add a watchdog from outside its failure domain: an HTTP check on the UI and status page, a Kuma monitor pointed at a CronAlert heartbeat URL so Kuma proves every minute that it is actually checking, a heartbeat on the SQLite backup, and alerts that do not route through the box that just died.
Object storage is the dependency everything else leans on. MinIO fails in layers: a node that is up but has lost write quorum, a bucket policy that turned public assets into 403s, an expired certificate every client refuses, a mirror cron that stopped. Monitor each one: the /minio/health endpoints, a canary object read, an expected-403 check on the API root, SSL expiry, and heartbeats on the mc mirror and restic jobs.
A registry that is down breaks nothing until the next deploy, node reboot, or autoscale, and then it breaks everything at once as ImagePullBackOff. Monitor it in layers: /v2/ as an expected-401 check, Harbor's /api/v2.0/health for database, Redis, job service, and storage, the anonymous token grant for a public canary project, SSL expiry, heartbeats on replication and garbage collection, and a scheduled in-cluster pull that proves the nodes can actually fetch an image.
A Jenkins controller that answers on 8080 is not a Jenkins that builds. Monitor it in layers: /login as the one anonymous 200 (503 while starting), the Metrics plugin healthcheck for disk, plugins, and deadlocks behind a Jenkins-Metrics-Key header, a scheduled pipeline per agent label that pings a heartbeat only when a real executor ran it, an API check that catches an instance left in quiet mode, and a heartbeat on the JENKINS_HOME backup. What each alert means.
An inference server fails in ways a port check can't see: process up but the model never loaded, GPU out of memory, API bound to localhost after an update, tunnel down. Three layers: the liveness endpoint each server exposes (Ollama's root, vLLM and llama.cpp's /health), a keyword check that the model you depend on is still listed, and a heartbeat from a smoke test that runs a real prompt with a latency bound, because an HTTP monitor can't send a request body. Plus exposing the server safely and reading the alerts.
An MCP server gives your coding agent twelve monitoring tools; it doesn't tell the agent that a bare IP needs a TCP check, that a cron job wants a heartbeat with a grace period, or that a delete deserves confirmation. A SKILL.md does. What's in CronAlert's open-source Agent Skill, how to install it in Claude Code, Codex, and Cursor, a before-and-after session, how to write a team-conventions skill on top, and why the safety boundary is the API key, not the prompt.
Prometheus and Alertmanager can't tell you they're down. kube-prometheus-stack ships a Watchdog alert that fires forever for exactly this reason, and most installs route it to null. Route it to a CronAlert heartbeat via Alertmanager's webhook receiver instead: pings every minute while rule evaluation, delivery, routing, and outbound HTTP all work, an alert from outside the cluster when they stop. Config for kube-prometheus-stack and plain Prometheus, what the heartbeat proves and doesn't, and external checks on Prometheus, Alertmanager, and Grafana health endpoints.
A self-managed GitLab is six services behind one hostname, and the runner fails without touching the web UI. Monitor the layers separately: /-/health instead of the sign-in redirect, a smart-HTTP canary that proves Gitaly is serving, a TCP check on SSH, a scheduled pipeline that doubles as a runner-and-Sidekiq heartbeat, the registry's 401 handshake, a Pages site, and a heartbeat on gitlab-backup create that also backs up gitlab-secrets.json.
Every HTTP monitor can send custom headers on every plan, and they fix most 'my monitor can't reach the real thing' problems: Bearer tokens and API keys, basic auth via the Authorization header (credentials in the URL are rejected), a User-Agent your logs and rate limits can recognize, a secret header a WAF or bot-protection rule skips on, and Accept headers so a keyword check has JSON to match. Plus the inverse monitor that expects 401, why you can't assert on a redirect, and credential hygiene.
Cloudflare Tunnel fails in two distinguishable ways an uptime monitor can tell apart from outside: 530 with error 1033 when cloudflared is down, 502 when the tunnel is up but your service isn't. Reading those codes, why a bare check on an Access-protected hostname is always green and how service-token headers fix it, a heartbeat on cloudflared's /ready endpoint, and the diagnosis table.
The *arr stack breaks one link at a time while every container says 'running'. Monitor each link with the endpoints the apps expose: /ping on every *arr app, the authenticated /health endpoint (X-Api-Key header) that returns the app's own problem list, Jellyseerr's status endpoint, a heartbeat for the VPN-wrapped download client that checks its public IP, and the root-folder mount.
The most common alerting question is 'how do I send this monitor to that channel?', and the answer is that you don't: channels belong to a team, every enabled channel fires for every monitor in it, and routing is deciding which team a monitor lives in. Teams as routing groups on any plan, a relay for routing inside one team, which channels are on which plan, and where the noise controls live.
A UPS fails three ways and only one is a power cut: the battery quietly ages, the link to the UPS drops so the host would never see an outage coming, and the self-test stops running. A per-minute heartbeat script that fails on on-battery, low battery, replace-battery, stale data, or short runtime; why the router belongs on the UPS; a Synology or QNAP as NUT server; a Home Assistant condition; and battery-age tracking.
A self-hosted forge has more moving parts than its login page: the API, Git over SSH on its own port, Actions runners that go offline until a pipeline hangs in 'waiting', pull mirrors that stop syncing, the registry, and a nightly dump. The built-in /api/healthz, a smart-HTTP clone check, TCP on the SSH port, a scheduled workflow as a runner heartbeat, mirror freshness via the API, and backup heartbeats.
Apprise is the notification library behind Uptime Kuma and Home Assistant: one URL scheme per service, a hundred-plus services, and a self-hostable API that fans one message out to all of them. One CronAlert webhook channel plus a small relay covers Telegram, Matrix, Pushover, Gotify, Signal, email, and more, with routing by tag. The Worker, running and securing Apprise API, failure/success types, and monitoring Apprise itself.
ntfy and Gotify are the self-hoster's push notifications, and neither reads CronAlert's webhook payload directly. A twenty-line Cloudflare Worker that verifies the signature and maps down and recovered events to each app's title, priority, and tags; priorities that make a down alert override Do Not Disturb and a recovery stay quiet; authentication for self-hosted servers; and monitoring the push server itself so the alert path can't fail silently.
The two self-hosted apps whose failure you notice last: the desktop client goes grey, the phone's photo backup stalls, and the server says nothing. External checks on Nextcloud's status.php and Immich's /api/server/ping, deeper authenticated checks that reach the database, catching maintenance mode and a dead cron, monitoring Collabora or OnlyOffice, and a heartbeat for the storage mount and backups underneath.
launchd fails in ways cron never did: agents that only run while someone is logged in, scripts that silently find nothing on PATH, Full Disk Access denied with no visible error, schedules skipped during sleep. A verify-then-ping wrapper and its plist, a Time Machine freshness check, a canary daemon for launchd itself, and the macOS traps around sleep, login, PATH, and privacy controls.
Uptime monitors come in three shapes, and the wrong one is the most common reason a monitor is green while the thing it watches is broken. What HTTP, TCP port, and heartbeat monitors each prove and can't see, a decision table for websites, APIs, databases, mail, SSH, game servers, cron jobs, backups, NAT-hidden devices, and VPNs, which plan each is on, and the five mismatches that make monitors lie.
Home Assistant fails two ways: the instance is gone, or it's running fine while the things it controls have quietly gone unavailable. Watch it from outside via Nabu Casa or a reverse proxy with a token header on /api/, and turn an automation into a heartbeat that only pings while the Zigbee coordinator, MQTT broker, and your key sensors are alive.
When your DNS resolver dies, every device says the internet is down and the dashboard that would tell you is at a name that won't resolve. DNS is UDP, so nothing outside can probe it. A heartbeat script for Pi-hole (v5 and v6) and AdGuard Home that resolves through the local resolver, confirms blocking and the upstream path, checks the service and gravity freshness, and pings only when all of it passes, and why it still alerts correctly when its own DNS is what broke.
A heartbeat monitor is a deadline defined by two numbers: the expected interval between pings and the grace you allow on top. How CronAlert computes the deadline, why the default grace is the interval capped at one hour, how to pick a grace for per-minute, hourly, nightly, and weekly jobs from real run times, where the clock starts for a new monitor, the five mistakes behind false heartbeat alerts, and how to set both values in the dashboard, API, and from an AI assistant.
A NAS has two failure modes and its own alerts only cover one: offline, which you notice, and degraded-but-serving (a failed disk, a volume at 95%, a stopped SMB service, a backup that quietly hasn't run), which you notice too late. External checks on what you publish, why not to expose the admin UI, and a scheduled health script for DSM, TrueNAS, and Unraid that checks array health, capacity, and services before pinging a heartbeat.
A VPN is the one thing an outside monitor is designed not to reach, so tunnels die quietly: expired Tailscale node keys, peers that stopped handshaking, subnet routers that rebooted without the route, a Headscale server that fell over. A heartbeat script that pings across the tunnel, reads handshake ages and key expiry, and probes the services behind it; the two external checks that still work; and where to place the heartbeat so it can still report.
CronAlert has no Mattermost or Rocket.Chat channel type, and it doesn't need one: both accept Slack-format incoming webhooks, so you paste their webhook URL into a Slack alert channel and downtime alerts land in your self-hosted chat. Setup for each tool, what the message looks like, how to reach an internal chat server without exposing all of it, an optional Rocket.Chat script for color, and why a self-hosted chat server should never be your only alert channel.
A media server fails in ways its own dashboard never shows: the port forward that vanished, the NAS mount that dropped, the disk full of transcode files, the stale DDNS record. Monitor Plex, Jellyfin, and Emby from outside with the unauthenticated /identity and /health endpoints, pick the right check for reverse-proxy, port-forward, and VPN-only setups, and add a one-minute heartbeat script for the 'online but useless' failures.
When a Proxmox node goes down it takes every VM with it, including whatever would have emailed you. Three layers that don't rely on the host to report its own death: a TCP check on SSH (and why HTTPS on 8006 fails against the default certificate), per-service checks on the guests, and a one-minute heartbeat script covering stopped VMs, frozen guest agents, degraded ZFS, inactive storage, disk space, quorum, and vzdump backup freshness, with the hook script included.
Not everything speaks HTTP. A TCP port monitor opens a connection to host:port on a schedule and alerts when the handshake is refused or times out — SSH, Postgres and MySQL, IMAP and SMTP submission, Minecraft, RDP, and any server you only know by IP. How CronAlert's port checks work, what 'up' does and doesn't prove, the one port Cloudflare won't reach, why there's no ICMP ping, and when to pair a port check with a health endpoint or heartbeat.
Game servers die in ways the panel doesn't show: a Java heap crash, a frozen tick loop with the port still open, a home IP that changed overnight, a disk filled by backups. A TCP port check for Minecraft Java, a heartbeat from the host for Bedrock and other UDP games (Rust, Valheim, CS2), catching a server that's 'up' but frozen, and sending the alert to the Discord your players already live in.
A $5 VPS fails in five predictable ways: the disk fills, the OOM killer takes the database, an unattended upgrade reboots it and a service doesn't come back, a firewall change locks a port, or the provider has a bad day. Three layers that cover all of them — a TCP check on SSH, HTTP checks for what it serves, and a cron heartbeat that only pings when disk, memory, and services are healthy — plus why a bare IP can't be HTTP-monitored from Cloudflare.
Task Scheduler reports 'The operation completed successfully' for tasks that haven't done their job in weeks: PowerShell that errored but exited 0, a task waiting for a user who never logs in after a reboot, an expired stored password, a battery condition that skips runs, history that was never turned on. Eight silent failures, a PowerShell wrapper that only pings on verified success, the schtasks and event-log checks worth knowing, and a canary task for the scheduler itself.
A bot shows as online for hours after it stopped responding: process alive but gateway dead, token reset, a privileged intent turned off, or the free host put it to sleep. How bots actually fail, a /health endpoint that returns 503 unless the bot is really connected (free plan), a heartbeat from inside the connection loop, Telegram bots in polling and webhook mode, and how not to get the alert in the Discord that just died.
Most uptime tools put SMS behind their most expensive tier and meter it in credits. Push notifications with a Do Not Disturb exception are free and wake you better than a text; PagerDuty adds real phone calls and escalation from $5/month; a twenty-line Cloudflare Worker turns CronAlert's webhook into Twilio texts or calls for under a cent each. What each costs, when a text is the wrong channel, and the recipe for each.
A timer-triggered function can stop running without a single error: disabled in the portal, idled by a Dedicated plan without Always On, orphaned when the storage account behind the timer lock changes, killed by the Consumption timeout, or misread through six-field NCRONTAB. The silent failures, what Application Insights can see, a canary timer, and the deployment-slot double-fire.
Chat alerts scroll away; an issue per incident gives you an owner, a timeline, and a place for the postmortem. Open a Linear or Jira issue on monitor.down and close it with the duration on recovery using the free webhook channel — Jira Automation or Zapier with no code, or a Cloudflare Worker that handles correlation, duplicates, and flapping.
You don't run servers, but your domain, DNS, SSL, hosting plan, contact form, and booking widget are all yours — and they fail without your host telling you. A plain-English guide for owners and the freelancers who build their sites: the five real causes of downtime, a five-monitor free setup, who gets the alert, and a triage list for when it fires.
CronAlert's webhook channel POSTs a signed JSON payload on every down and recovery event — on the free plan. The exact payload, HMAC verification in Node and Python, and five routing recipes including the small transformer chat apps need.
When your docs go down, your support queue is the alert. Custom-domain DNS and SSL, the OpenAPI spec your API reference fetches at runtime, search that dies while pages stay green, deep links that 404 after a restructure — and a free eight-monitor setup.
Callbacks tell you when a DAG run fails. Nothing tells you when a DAG stops running at all — paused, un-importable, starved, or orphaned by a dead scheduler. Six scheduler-level failures, a canary DAG that proves the scheduling path is alive, and the /health check without the 'unhealthy contains healthy' trap.
Cloud Scheduler records success at the hand-off, not the outcome — and for Cloud Run jobs the hand-off returns before your code runs. Five ways a GCP schedule fails with green dashboards, why Cloud Monitoring alone misses silence, and the heartbeat pattern with a zero-code canary.
Shopify's platform is almost never why your store is unreachable. Your DNS, SSL, a storefront left password-protected, a lapsed plan, a renamed product URL, or a third-party app widget are — and none of them alert you. What to monitor, why the password page fools basic checks with a 200, and a free ten-minute setup.
A spending plan, not a tool list. What a free tier genuinely covers, the one question that tells you whether to pay $5, what $20 buys that $5 doesn't, and the two things budget teams overpay for — SMS and on-call bundles — when a free pager does them better.
People leave StatusCake over the gap between a small 5-minute free tier and a ~$25/month paid step, and over a product whose pace slowed after its 2019 acquisition. Seven alternatives compared honestly by what each is best at, plus what actually replaces the domain and page-speed extras.
An EventBridge schedule that fires a Lambda can fail five ways that leave every AWS dashboard green: disabled rule, missing invoke permission, async errors that retry and drop, reserved-concurrency throttling, wrong six-field cron. Why CloudWatch alarms alone don't catch silence, and the heartbeat pattern that turns all five into one alert.
The platform is almost never what takes a Webflow, Squarespace, or Wix site down. Your DNS, domain, SSL provisioning, an accidental unpublish, a lapsed plan, and third-party embeds are — and the platform won't notice any of them. What to monitor, how to catch pages that fail with a 200, and the free ten-minute setup.
People leave Better Stack over the $0-to-$29 cliff: the first paid step is a responder license bundling on-call whether you need it or not, and extra monitors come in $21-per-50 packs. Seven alternatives compared honestly by what each is best at.
Laravel's scheduler has heartbeat pings built into its API — pingOnSuccess, pingOnFailure, thenPing — and almost nobody wires them up. How the scheduler fails silently (missing cron line, maintenance mode, stuck locks, the queued-job dispatch gap) and the two-layer setup that catches all of it.
A Bun app is usually one very fast process — and that's the whole risk profile. Monitoring Bun.serve, Elysia, and Hono apps: a dependency-aware health endpoint, the idle-timeout gotcha on slow endpoints, crash supervision, and heartbeats for in-process schedulers.
People leave Pingdom over metered add-ons (SMS, RUM, transaction checks all billed separately), per-check pricing that climbs fast, and slow feature pacing under SolarWinds. Seven alternatives compared honestly by what each is best at.
Node's two scheduling styles fail in opposite ways: node-cron dies with your process silently, while BullMQ repeatable jobs stall when no worker is attached — or vanish when Redis evicts keys. Heartbeat patterns for both, plus the duplicate-repeatable gotcha.
A dated checklist for the days your site earns the most and downtime costs the most: monitor the money path at T-4 weeks, tighten intervals and re-baseline thresholds at T-2, fire-drill alerts and prep the status page at T-1, then freeze and watch the trend.
UptimeRobot's free plan is the category's most generous — the reasons people leave are the paid-tier math ($12/mo for 10 monitors), false positives, and feature gates. Seven alternatives compared honestly by what each is actually best at.
Heroku Scheduler is documented as a best-effort service: runs can be skipped or delayed, there are no retries, and nothing alerts you when a job silently doesn't fire. The heartbeat pattern for Scheduler jobs, one-off dyno failure modes, and monitoring a custom clock process.
Remix and React Router 7 fail more honestly than most frameworks — a throwing loader is a real 500 a monitor can see. The exceptions are where outages hide: streamed deferred data that rejects after the 200, POST-only actions, SPA mode, and clientLoader.
CronAlert is an Astro app, so this is field notes: what breaks in static, hybrid, and SSR Astro deployments, why a failed island hydration still returns 200, adapter and middleware failure modes, and the CSRF default that 403s webhooks while every page stays green.
Celery Beat is a single process that schedules everything and reports nothing: when it dies, workers stay healthy and no error fires anywhere. Heartbeat patterns for periodic tasks, a beat-liveness canary that proves the whole chain, and the duplicate-beat failure mode.
Uptime monitoring is detection — it tells YOU something is down. A status page is communication — it tells your USERS what you know. One without the other fails predictably: monitoring alone means a support-ticket tax, a page alone drifts into all-green fiction.
One Nuxt app is really several apps: routeRules can make some routes prerendered, some cached-and-stale, some SSR, and some client-only SPA shells that return 200 no matter how broken the app is. What to monitor per route class, and the failures status codes can't see.
Cron Triggers fail in ways the Cloudflare dashboard won't page you about: unawaited promises silently dropped, schedules deleted by a wrangler.toml refactor, runs that overlap and double-process. How we monitor the Cron Triggers that run CronAlert itself.
Most small products need 6–12 monitors, not 1 and not 100. The sizing rule: count failure domains, not URLs. A starter set, when to split one monitor into several, when more monitors just mean more noise, and typical counts by team type.
SvelteKit's adapter decides how your app fails: a Node server that dies with its process, serverless functions that cold-start, or static files that can't go down. What to monitor per adapter, plus the ORIGIN misconfiguration that 403s every form while GET pages look fine.
Vercel cron jobs don't retry, Hobby-plan schedules run once a day at a time Vercel picks, and a job deleted from vercel.json disappears without a trace. How to put heartbeats on Vercel crons so a missed or failed run pages you instead of hiding in the logs.
Alert pipelines rot silently: Slack webhooks die when channels are archived, alert emails drift into spam, and the person on the escalation left in March. How to run a monitoring fire drill that proves an outage actually reaches a human — before a real one has to.
Supabase's status page can be green while your project is paused, and Firebase can be 'up' while your security rules block every user. How to monitor BaaS-backed apps: your project's endpoints vs the platform's status, free-tier pausing, cold starts, and the 200s that lie.
Zapier pauses Zaps that keep erroring, Make disables scenarios after consecutive failures, and self-hosted n8n dies with its container — all silently. How to put heartbeats on automation workflows so a dead automation becomes an alert instead of a surprise.
1 minute, 3 minutes, 5, 15? Check frequency sets the floor on how fast you can ever detect an outage. The math of detection time, when sub-minute intervals matter (rarely), how frequency interacts with false positives, and a per-monitor tiering strategy.
A practical guide to uptime monitoring for Phoenix/Elixir apps: why 'let it crash' hides crash loops from the outside, a health check plug with Ecto probes, GenServer mailbox backlogs, monitoring Oban and scheduled jobs with heartbeats, and setting up CronAlert.
certbot renew fails silently and your certificate dies 30 days later. How to catch renewal failures the day they start: SSL expiry monitoring on the served certificate, a heartbeat on the renewal timer, and the renewed-but-never-reloaded nginx gotcha.
Static sites can't go down — except via DNS, certificate renewals, platform outages, broken deploys that ship empty pages, and the third-party endpoints your forms depend on. What actually fails on Netlify, GitHub Pages, Vercel, and S3, and how to monitor all of it free.
A fair, detailed comparison of CronAlert and UptimeRobot: the category's best-known free plan vs flat $5 paid monitoring, compared on free tiers, paid pricing, check intervals, alerting, status pages, and heartbeats.
A practical guide to uptime monitoring for Symfony apps: writing a health check controller with Doctrine and cache probes, catching dead Messenger workers and Scheduler silence, PHP-FPM pool exhaustion, and setting up CronAlert.
systemd timers fail as silently as the cron they replaced: missed OnCalendar runs, failed oneshot services nobody notices, timers that never got enabled. Here's how to catch all of it with ExecStartPost heartbeats and OnFailure hooks — unit files included.
A fair, detailed comparison of CronAlert and Robotalp: credit-based plans with 12 check types vs flat-rate uptime monitoring from $0, compared on features, pricing, free plans, alerting, and status pages.
A practical guide to uptime monitoring for ASP.NET Core apps: the built-in health checks middleware, thread pool starvation from sync-over-async, silently dying BackgroundServices, IIS app pool recycling and idle timeouts, and setting up CronAlert.
GitHub Actions scheduled workflows get silently disabled after 60 days, start late under load, and fail without paging anyone. Here's how to catch all of it with heartbeat monitoring — including the workflow YAML to copy.
A fair, detailed comparison of CronAlert and Uptime.com: modular enterprise monitoring priced per component vs flat-rate uptime checks from $0, compared on features, alerting, status pages, and total cost.
A practical guide to uptime monitoring for Go apps: writing a proper /healthz handler with net/http, catching goroutine leaks and database/sql pool exhaustion, the missing-server-timeouts gotcha, heartbeats for background goroutines, and setting up CronAlert.
Kubernetes CronJobs fail silently: skipped runs under concurrencyPolicy Forbid, the 100-missed-schedules trap, suspended jobs nobody resumed, and ImagePullBackOff at 2 AM. How to catch all of it with heartbeat monitoring.
A fair, detailed comparison of CronAlert and Uptrends: enterprise synthetic monitoring at $210/mo vs flat-rate uptime checks from $0, compared on credits, browser monitoring, alerting, and when each fits.
A practical guide to uptime monitoring for Spring Boot apps: exposing Actuator health endpoints safely, catching HikariCP pool exhaustion and stalled @Scheduled tasks, monitoring background jobs with heartbeats, and setting up CronAlert.
Backups are the canonical silently-failing cron job. How to monitor pg_dump and mysqldump jobs with heartbeats, verify the dump is actually restorable, and catch failures months before a restore reveals them.
A fair, detailed comparison of CronAlert and OnlineOrNot: two indie uptime monitors compared on free tiers, pricing models, browser checks, status pages, and how to pick between them.
A practical guide to uptime monitoring for Express and Node.js apps: building a health endpoint, catching event-loop blocking and keepAliveTimeout 502s, monitoring BullMQ and node-cron jobs, and setting up CronAlert.
Rate limits cause outages that look like nothing at all: jobs silently skipped, retry storms, blocked users. How to monitor 429s, quota headroom, and your own rate limiter — before customers notice.
A fair, detailed comparison of CronAlert and Checkly: synthetic Playwright checks vs simple uptime monitoring, monitoring-as-code, pricing models, and how to decide which fits.
A practical guide to uptime monitoring for FastAPI apps: building an async health endpoint, catching event-loop and pool exhaustion failures, monitoring background workers, and setting up CronAlert.
Reverse proxies are your single entry point — and your single point of failure. How to monitor nginx, Traefik, Caddy, and HAProxy: 502/504 signatures, default-vhost traps, TLS, and config reloads.
A fair, detailed comparison of CronAlert and Phare: pricing models, check features, alert channels, EU vs global infrastructure, and how to decide which uptime tool fits.
A practical guide to uptime monitoring for Rails apps: using the built-in /up health endpoint, catching Rails-specific failures, monitoring Sidekiq and Solid Queue, and setting up CronAlert.
How to monitor Docker containers and self-hosted apps from the outside: why local healthchecks aren't enough, reverse proxy checks, heartbeats for backups, and SSL renewals.
A fair, detailed comparison of CronAlert and updown.io: monitor types, alert channels, multi-region checks, pricing, and how to decide which uptime tool fits.
A practical guide to uptime monitoring for Laravel apps: using the built-in /up health route, catching Laravel-specific failures, monitoring queues and the scheduler, and setting up CronAlert.
Monitor IoT devices, sensors, and edge gateways behind NAT with heartbeats. Each device pings CronAlert on a cycle — no ping means an alert fires.
Compare CronAlert and Hyperping on monitor types, alert channels, multi-region checks, status pages, API access, and price to pick the right uptime tool.
A practical guide to uptime monitoring for Django apps: building a health endpoint, catching Django-specific failures, monitoring Celery, and setting up CronAlert checks.
A practical guide to designing fair on-call rotations and escalation policies for teams of 2-5 people — rotation models, ack timeouts, severity tiers, and reducing burnout.
Cronitor pairs mature cron monitoring with APM and telemetry. CronAlert delivers Cloudflare-edge uptime, content checks, and a full API on every plan. Here's how the two compare on features and pricing.
Your HTML returns 200 but the JS, CSS, fonts, and images on your CDN 404 or go stale. Here's how to monitor static asset availability and catch 'up but broken' failures.
A practical guide to monitoring your email pipeline: provider status, send-path health endpoints, scheduled jobs, bounce webhooks, and DNS auth records — so you catch silent failures fast.
A headless CMS sits between your content team and your live site, and when it's slow or down your pages go stale, your builds fail, and editors lose work. Here's what to actually monitor across Contentful, Sanity, and Strapi — the content API, the build/webhook pipeline, the CDN cache, and your own self-hosted instance — and how to alert before readers notice.
Pulsetic built its reputation on beautiful, easy status pages and friendly uptime monitoring. CronAlert is focused, developer-first uptime on Cloudflare's edge with SSL, content, and heartbeat checks plus a full API on every plan. Here's a feature-by-feature comparison, the free-tier breakdown, and when each one is the right call.
Every uptime monitoring tool claims to tell you when your site goes down. The differences that actually matter are subtler: check interval, false-positive handling, what counts as 'down,' alert routing, and pricing that doesn't punish growth. Here's a practical framework for evaluating monitoring tools — the criteria that matter, the marketing claims that don't, and a checklist to run any vendor through.
A status page is the one channel customers check when your app is misbehaving. Get it wrong and it makes the outage worse — vague, stale, or silent. Here's what to show (and what to leave off) during an incident, how often to update, and how to write updates that calm users instead of alarming them.
HetrixTools is best known for two things uptime tools usually skip: blacklist monitoring and agent-based server resource monitoring. CronAlert is focused uptime on Cloudflare's edge with SSL, content, and heartbeat checks built in. Here's a feature-by-feature comparison, the free-tier breakdown, and when each one is the right call.
MTTR, MTTA, MTTD, MTBF — the incident-metric alphabet soup is easy to quote and easy to misuse. Here's what each one actually measures, the one that's secretly four different metrics, how to calculate them from real data, and which ones a small team should track instead of vanity numbers.
The enterprise postmortem template assumes a dedicated SRE org you don't have. Here's a blameless postmortem process built for teams of two to ten: short enough to actually finish, honest enough to fix the real cause, and structured so the same outage never pages you twice.
A broken landing page doesn't just lose conversions — it keeps charging you for clicks the whole time it's down. Here's how to monitor the pages your paid traffic lands on, including form submissions and tracking pixels, so a silent break doesn't quietly burn your ad budget.
An MCP server is an API your AI agents depend on — and when it goes down, the failure shows up as a vague 'the agent can't do that anymore' instead of a clear outage. Here's how to monitor remote MCP servers for availability, tool-call health, and the transport quirks (SSE, streaming) that standard uptime checks miss.
AI features fail in ways traditional monitoring misses: the provider degrades without going down, rate limits throttle you at peak, streams die mid-response, and latency quietly triples. Here's how to monitor LLM providers and your own AI endpoints so you know before your users do.
Observability vendors will sell you all three at once. Most teams need them in a specific order: uptime monitoring first, error tracking second, logs third, APM when you have the headcount to act on it. Here's what each layer actually answers, what it costs, and when to add it.
A monitor's timeout is your operational definition of 'down' — and most teams never set it, inheriting a 30-second default that calls a 25-second login page healthy. Here's how to derive timeouts from real baselines, set them per endpoint class, and tune out false positives without going blind.
You deployed to multiple regions so one region's failure wouldn't take you down — but if your monitoring only checks the global endpoint from one place, you can't see a region die, a failover misfire, or a standby that quietly rotted. Here's how to monitor active-active and active-passive architectures properly.
A message queue rarely goes down loudly — the broker stays reachable while a queue quietly backs up, consumers vanish, or messages age past their usefulness. This guide shows how to surface RabbitMQ, SQS, and Kafka health through HTTP endpoints and monitor broker availability, queue depth, and message age externally with CronAlert.
In a multi-tenant SaaS, 'the app is up' can be true while your biggest customer is completely down — a broken shard, an expired custom-domain certificate, or a failed tenant migration only hits some tenants, and aggregate monitoring averages them away. Here's how to monitor per-tenant health without creating a monitor for every tenant.
Redis rarely returns a 500 — it just gets slow, runs out of memory, starts evicting keys, or loses a replica, all while your app keeps returning 200. This guide shows how to surface Redis and ElastiCache health through an HTTP endpoint and monitor it externally with CronAlert before a degraded cache becomes an outage.
When your login goes down, everyone is locked out — but your homepage keeps returning 200, so a normal uptime check never notices. This guide shows what to monitor in an OAuth flow and identity provider (Auth0, Okta, Cognito, Google, Entra ID), including JWKS and certificate expiry, and how to watch it all with CronAlert.
A broken webhook receiver fails silently: Stripe, GitHub, and Twilio keep POSTing, your endpoint keeps 500-ing or timing out, and you lose payments, deploys, and messages with no error on your own dashboards. This guide shows how to monitor the inbound webhook endpoints in your app with CronAlert.
Freshping is Freshworks' free uptime monitor — generous on the free tier, but tied to the Freshworks suite and its product roadmap. CronAlert is focused uptime on Cloudflare's edge with a free tier of its own and cheap paid plans. Here's a feature-by-feature comparison, a free-tier-vs-free-tier breakdown, and when each one is the right call.
Replication lag is the silent failure that serves stale data, breaks read-after-write consistency, and turns a failover into data loss. This guide shows how to measure Postgres replication lag, expose it through a health endpoint, and monitor it externally with CronAlert.
A Shopify app has more failure surfaces than a normal web app: the embedded admin, the OAuth install flow, webhook receivers, the App Proxy, and Shopify's API rate limits. When any of them goes down, merchants churn and your listing is at risk. This guide covers what to monitor and how.
A practical guide to HTTP status codes for uptime monitoring. What each code means, which ones matter most, common gotchas, and how to configure your monitors correctly.
The uptime percentage formula, a complete nines reference table, what each level actually requires, and how to use monitoring data for SLA compliance.
Everything you need to know about uptime monitoring — how it works, what to monitor, types of checks, alert channels, key metrics, and how to choose the right tool.
A step-by-step guide to monitoring your website's uptime with CronAlert. Create your first monitor, configure alerts, and start getting notified when your site goes down.
Set up uptime monitoring directly from your terminal. One command to install, natural language to manage monitors.
Manage your monitors through a conversational interface. Ask Claude to check uptime, create monitors, and investigate incidents.
Monitor your sites without leaving your editor. Create monitors, check status, and handle incidents from Cursor's Composer.
Give Cascade the power to manage your uptime monitoring. Two setup methods, eleven tools, zero context switching.
Create a public status page with 90-day uptime history, incident tracking, and an Atom feed. Free on all CronAlert plans.
CronAlert automatically detects SSL certificate errors during every check. No extra config needed — just monitor any HTTPS URL.
Catch silent cron job failures. Your tasks ping CronAlert on success — no ping means an alert fires instantly.
Check your sites from 5 regions simultaneously. Catch CDN issues, regional outages, and geo-routing bugs that single-location checks miss.
Go beyond keyword checks. Monitor for content changes via SHA-256 hashing, alert when pages go stale, and match response bodies against regex patterns.
A 200 OK doesn't mean everything is fine. Keyword monitoring checks response bodies for expected or unwanted content.
Silence alerts during planned downtime. Checks keep running, but no alerts fire until the maintenance window ends.
Automate monitor creation, pull uptime stats, and integrate with CI/CD using CronAlert's REST API. Full curl examples included.
Share monitors, alerts, and status pages with your team. Roles, invites, and audit logging for collaborative monitoring.
Calculate what website downtime actually costs your business. Revenue loss formulas, industry benchmarks, hidden costs, and how faster alerting reduces the impact.
Compare CronAlert (hosted) and Uptime Kuma (self-hosted). Feature comparison, total cost of ownership, setup time, and when to choose each approach.
E-commerce downtime costs real money every minute. Learn what to monitor, how to set up alerts, and how to minimize revenue loss from outages.
The 8 endpoints every SaaS should monitor, monitoring strategy by growth stage, and alert routing for SaaS teams.
Monitor your WordPress site's uptime, login page, REST API, and WooCommerce checkout. Catch plugin conflicts, database timeouts, and hosting issues before your visitors do.
Step-by-step guide to migrating your monitors from UptimeRobot to CronAlert. Export your monitors, map settings, and switch in under 10 minutes.
Monitor your Kubernetes services from the outside. Catch ingress misconfigurations, certificate errors, and routing failures that internal probes miss.
Automate monitor creation on every deploy. GitHub Actions, GitLab CI, and generic curl examples for managing monitors as code.
Webhook endpoints fail silently. Learn how to monitor your webhook receivers for availability, response time, and correctness with practical examples.
Monitor REST APIs, GraphQL endpoints, and webhooks. Set up authenticated checks, response body validation, and multi-region API monitoring.
A practical incident response playbook for teams of 1-10 engineers. Triage, communicate, fix, and learn -- without enterprise overhead or 50-page runbooks.
Route CronAlert downtime alerts into PagerDuty with the native channel: paste an Events API v2 integration key and every monitor failure triggers an incident that pages on-call and auto-resolves on recovery. Setup, deduplication, scoping, and pairing with Slack and maintenance windows.
Get instant Microsoft Teams notifications when your sites go down. Set up incoming webhooks and receive formatted Adaptive Cards with downtime details.
Get instant Telegram notifications when your sites go down. Create a bot, connect it to CronAlert, and receive formatted downtime alerts in any chat or group.
Get instant Slack notifications when your sites go down. Rich Block Kit messages with status, URL, error, and region details.
Get color-coded Discord embeds when your sites go down. Free on all plans, set up in under two minutes.
Health check patterns, dependency monitoring, and why external uptime checks complement service mesh observability in microservices architectures.
Practical strategies to cut alert noise: consecutive-check verification, maintenance windows, escalation policies, and channel routing.
Expose a /healthz endpoint that checks database connectivity, then monitor it externally. Code examples for Node.js, Python, and Go, plus what not to put in a health check.
The difference between synthetic monitoring and RUM, when each is enough on its own, and why most production apps need both for complete observability.
A detailed comparison of CronAlert and Better Stack for uptime monitoring. Features, pricing, and when to choose each tool.
Monitor serverless functions for cold starts, timeouts, and silent failures. Health check patterns for AWS Lambda, Cloudflare Workers, and other FaaS platforms.
Monitor your Cloudflare Workers, Pages sites, and D1 databases for uptime. Catch deploy failures, CPU limits, binding errors, and edge network issues.
An honest comparison of free uptime monitoring tools in 2026. CronAlert, UptimeRobot, Uptime Kuma, Better Stack, Hetrix Tools, and more -- what you actually get for free.
Organize monitors by client, set up per-client status pages, route alerts to the right team, and scale from 10 to 500 sites.
UptimeRobot alerts for outages that never happened? Here's why UptimeRobot false positives happen — single-region checks, no consecutive retry defaults, WAF conflicts — and how to stop them.
GraphQL endpoints fail in ways REST monitors cannot detect — every response is a 200 OK, errors live in the body, and a single POST exposes hundreds of query paths. Here's how to monitor GraphQL APIs correctly.
Next.js on Vercel has specific failure modes — cold starts on Serverless Functions, ISR revalidation bugs, Edge runtime limits, misrouted middleware. Here's what to monitor and how to catch outages before users do.
Most outages come from the same ten causes: DNS, expired certs, deploy bugs, database overload, third-party dependencies, DDoS, cache misconfigurations, domain expiry, hosting issues, and traffic spikes. Here's how to prevent each.
Email is the universal fallback channel for uptime alerts — every team has it, every tool supports it. But it has latency, deliverability, and noise problems. Here's how to set up email alerts correctly and when to use email versus other channels.
Internal tools fail silently because nobody is watching. Admin panels, employee dashboards, and partner portals have low traffic and high blast radius when they break. Here's how to monitor them externally — including auth-protected pages — without exposing them to the internet.
Your uptime is capped by your dependencies'. When Stripe is down, checkout breaks. When Twilio is down, 2FA breaks. Here's how to monitor third-party dependencies so you know about their outages before your customers tell you.
Operationalize incident response inside CronAlert: severity-routed alert channels, escalation chains, status-page updates, postmortem-ready incident timelines, and the API hooks that tie it into the rest of your stack. A workflow guide, not a playbook.
Reporting tells you whether you hit your SLA last quarter. Compliance tells you whether you'll hit it next quarter. This guide walks through using CronAlert uptime data proactively — error budgets, SLO burn rate, per-customer SLAs, maintenance window policy, and the operational habits that turn monitoring data into reliability decisions.
Site24x7 is ManageEngine's all-in-one monitoring suite — uptime, APM, server, network, log, and cloud monitoring under one bundle. CronAlert is focused uptime on Cloudflare's edge. If you only need uptime, the bundled pricing and configuration overhead of Site24x7 is hard to justify. Here's a feature-by-feature comparison and when each one is the right call.
Splunk On-Call's REST endpoint expects message_type, entity_id, and state_message, and CronAlert's webhook sends a different document, so the integration is a small Cloudflare Worker relay: verify the signature, map down to CRITICAL and recovered to RECOVERY on a stable entity_id so incidents deduplicate and auto-resolve, and post to the right routing key. The Worker, routing keys, per-team routing without per-monitor channels, severity mapping, and testing both paths.
Long-running batch jobs — nightly ETL, dbt runs, Airflow DAGs, Spark jobs, large data exports — fail in ways short cron heartbeats can't detect. Here's how to monitor batch jobs that run for hours or days: start/finish pings, max-duration alerts, milestone monitoring, and partial-failure detection.
Server-Sent Events stream over plain HTTP but fail in ways simple HTTP monitors miss — proxies buffer the stream, connections die mid-stream, events stall while the TCP connection looks healthy. Here's how to monitor SSE endpoints for uptime, delivery, and latency with the tools you already have.
StatusCake has been around for over a decade and is one of the most familiar uptime monitoring brands. CronAlert covers the same monitoring surface — HTTP, SSL, keyword, domain, and team monitoring — at roughly one-fifth the cost, on Cloudflare's edge, with multi-region quorum included. Here's a feature-by-feature comparison.
Background workers fail silently because nobody is watching them. Web servers throw obvious errors when they go down; queue consumers just stop draining the queue, jobs back up, and customers notice hours later. Here's how to monitor background workers and queue consumers — Sidekiq, Celery, BullMQ, RabbitMQ consumers, SQS workers — with heartbeats, queue-depth checks, and lag monitoring.
Nonprofits and educational institutions run mission-critical systems on small budgets and smaller IT teams — donor portals, learning management systems, financial-aid applications, student information systems. Downtime costs donations, blocks coursework, and erodes trust. Here's how to monitor uptime cost-effectively, stay aligned with FERPA, and protect the systems your community depends on.
gRPC endpoints fail in ways HTTP monitors cannot see — every framing is HTTP/2, errors live in trailers, and a healthy TCP connection can still be returning UNAVAILABLE on every call. Here's how to monitor gRPC services correctly: health-check protocol, streaming RPCs, TLS, and how to wire it into a normal uptime monitoring setup.
Healthchecks.io is a focused heartbeat monitor for cron jobs and background tasks. CronAlert covers the same ground plus URL uptime, content monitoring, SSL, and status pages. Here's how the two compare on heartbeat features, pricing, and when a single tool actually wins.
WebSocket connections fail in ways HTTP monitors cannot see — the upgrade handshake succeeds, then the connection silently dies, drops messages, or stalls. Here's how to monitor WebSocket endpoints for uptime, latency, and message delivery without building a custom monitoring system from scratch.
Pingdom is one of the oldest names in uptime monitoring, but its pricing, feature pacing, and ownership history have left teams looking for alternatives. Here's a feature-by-feature comparison of CronAlert vs Pingdom — what each does well, what they charge, and when to choose each.
Fintech systems can't fail silently — every minute of payment downtime is a regulatory event, a chargeback risk, and a customer-trust event. Here's how to monitor fintech apps in line with PCI-DSS and SOC 2, what to log (and what to never log), and how to keep monitoring vendors out of cardholder scope.
DNS is the invisible failure mode behind a lot of 'site is down' incidents that aren't actually about the site. Here's how to monitor DNS for resolution failures, propagation delays, expiring records, and hijacks — and how to wire DNS checks into a normal HTTP uptime monitoring setup.
Healthcare apps have stricter uptime requirements than most SaaS — patient portals, EHR integrations, and telehealth platforms can't fail silently. Here's how to monitor healthcare systems without violating HIPAA, what to log, and how to handle BAAs with monitoring vendors.
Opsgenie's Alert API needs a GenieKey header and its own JSON, and recoveries are a separate close call, none of which a CronAlert webhook channel sends on its own. A Cloudflare Worker relay that creates an alert on monitor.down with a stable alias and closes it on monitor.recovered, team routing with responders instead of per-monitor channels, priority mapping, EU endpoints, testing, and Atlassian's announced retirement of Opsgenie.
A practical guide to HTTP health check endpoints: shallow vs deep checks, /healthz vs /readyz vs /livez, what to include and exclude, code examples for Node.js, Python, Go, and Rust, and how Kubernetes liveness and readiness probes differ from external uptime checks.
Uptime reports are full of percentages, response times, and incident counts that look meaningful but rarely change behavior. Here's how to read uptime reports, what to ignore, what to act on, and how to turn the numbers into engineering decisions.
Staging environments break silently because nobody is watching. When staging is down, deploys get blocked, integrations stop testing, and engineers waste hours chasing ghosts. Here's how to monitor staging without paging anyone at 3am.
Mobile app outages look different from web outages — users can't refresh, error states are buried in the app, and a backend regression takes weeks to roll back through the App Store. Here's how to monitor mobile app backends so you find problems before your users do.
False positives train you to ignore real alerts. See how consecutive-check verification, multi-region quorum, and Cloudflare's edge network keep CronAlert alerts trustworthy.
A pragmatic uptime monitoring checklist for startups at pre-launch, launch, and post-launch. What to monitor, what to skip, and how much to spend at each stage.
Turn uptime monitoring data into quarterly SLA reports. Export check results, calculate compliance, handle maintenance windows, and satisfy enterprise customers.
Get instant downtime alerts on iOS. Install CronAlert as a PWA and enable push notifications — no App Store needed.
Get instant downtime alerts on your Android phone. Works in Chrome, Edge, and Firefox — no app install required.
Get native macOS notifications when your sites go down. Works in Chrome, Safari, Firefox, and Edge.
Get desktop notifications in Windows Action Center when your sites go down. Works in Chrome, Edge, and Firefox.
No posts match your search.