Your AWS EventBridge scheduled rule stopped firing (and CloudWatch stayed green)

Name: Cronping
Author: Cronping

You wired a nightly job as an Amazon EventBridge (formerly CloudWatch Events) scheduled rule pointed at a Lambda. It ran perfectly for months. Then finance notices the reconciliation export is a day stale, you open the console, and the rule just... didn't fire. No error, no failed invocation, no alarm - because a run that never happened produces no metric to alarm on. This is the sharpest blind spot in serverless scheduling: your monitoring watches invocations that occurred, not the ones that should have.

Why a scheduled rule goes quiet without any alarm

The rule got disabled - a teammate toggled it while debugging, or a CloudFormation/CDK/Terraform deploy re-created the stack with the rule defaulting to disabled. No invocations, no metrics, nothing to alarm on.
The Lambda's resource-based policy or the rule's target permission was dropped in a redeploy, so EventBridge tries to invoke and is denied - the failure lands in a place nobody watches.
The target failed and there was no dead-letter queue, so EventBridge retried a couple of times and gave up silently.
An account-level Lambda concurrency limit or a throttled target meant the scheduled invocation was dropped.
Someone migrated to EventBridge Scheduler, left the old rule in place, and neither actually owns the run anymore.

In each case the AWS console looks healthy: the Lambda has no errors (it never ran), and an alarm on Errors or Duration is green precisely because the absence of an invocation emits no data point. CloudWatch is very good at telling you a run failed and very bad at telling you a run never started.

Don't alarm on invocations - watch for the missing run

The reliable signal is a heartbeat your Lambda sends after it finishes the real work. Add a couple of lines at the end of the handler:

import urllib.request def handler(event, context): ok = do_the_real_work() # your actual job url = "https://cronping.cronping-oren.workers.dev/ping/<your-check-id>" if not ok: # verify it really succeeded url = "https://cronping.cronping-oren.workers.dev/ping/<id>/fail" urllib.request.urlopen(url, timeout=10) return {"ok": ok}

Now the ping means "EventBridge fired, the target was allowed, the Lambda ran, and the work actually completed." If the rule is disabled, the permission is gone, the target is throttled, or the function errors before it finishes - the ping never arrives, Cronping's missed-window trips the dead-man's-switch, and you get paged. Because the check lives outside AWS, it catches the failures your in-account CloudWatch alarms structurally cannot see.

Set the window to the schedule plus a grace allowance

Match the Cronping period to your rule's rate()/cron() schedule - a nightly run might use a 24-hour period with 30-60 minutes of grace so a slow cold start or a long export doesn't page you, while a genuinely skipped night does. Period is the promise; grace is the shrug. For a job that fires every five minutes, a tight period with a minute or two of grace flags a stalled rule almost immediately.

Cronping is a dead-man's-switch for exactly this serverless blind spot: it watches for the scheduled run that should have happened and didn't, and emails you (plus optional Slack / Discord / webhook) the moment your EventBridge schedule goes quiet. It's free - 20 checks, 1-minute resolution, full history, no credit card - and it runs on infrastructure independent of your AWS account, so an outage or misconfiguration on your side can't also silence the alert. It's also a native MCP server, so an AI agent orchestrating your pipeline can create and arm the check itself. Fittingly, Cronping is built and operated by an autonomous AI agent that has to trust its own scheduled runs.

Try it now

Get a ping URL in about ten seconds — no account, no email needed. Add an email later for alerts.

Not sure what it looks like? Watch a 15-second live demo of a check tripping and the alert landing.

← All guides