AWS Step Functions & EventBridge Support
Fixing an EventBridge rule that is not triggering.
When an EventBridge rule seems dead, the cause is almost always one of four things: the event is on a different bus, the pattern does not match exactly, the target lacks permission, or the delivery failed silently. Metrics and a test pattern tell us which in minutes.
When You Need This
The situations where this work pays for itself.
Signs it is time
- A rule is enabled but the target Lambda, queue or workflow never runs
- Events from an AWS service or CloudTrail do not arrive
- The rule worked in testing and not in another account or Region
- The target shows invocations but fails with permission errors
- A custom application event does not match your pattern
What you get
- The reason the rule did not fire, with metric and log evidence
- A corrected event pattern and target permissions
- A DLQ and alarm for failed deliveries
- A sample event and test command for future checks
How we do it
A clear, safe process you can follow along with.
1. Check the bus, Region and account
Rules only see events on their own event bus in their own Region. AWS service events go to the default bus. Custom events must be sent to the bus the rule is on, and cross-account delivery needs a bus policy.
2. Compare the real event to the pattern
We capture an actual event, for example with a catch-all rule sending to CloudWatch Logs, then test the pattern with the console test tool or the TestEventPattern API. Matching is exact and case-sensitive, and every field in the pattern must match.
3. Fix common pattern mistakes
Typical errors are a wrong source or detail-type, expecting a string where the field is an array, a pattern that matches fields at the wrong nesting level in detail, and needing numeric, prefix or exists operators.
4. Read the rule metrics
TriggeredRules shows matches, Invocations shows attempts to targets, and FailedInvocations shows delivery failures. A rule with no matches is a pattern or bus issue. Matches with failures is a target issue.
5. Fix target permissions
Lambda needs a resource policy allowing events.amazonaws.com from the rule ARN. SQS and SNS need a resource policy, and other targets use a role. KMS-encrypted targets also need key permissions.
6. Add a dead-letter queue and retry settings
A DLQ on the target captures events that could not be delivered, with the error reason, instead of dropping them after the retry window. We then replay them.
7. Verify end to end
We send a known event, follow it through TriggeredRules, the target logs and the DLQ, and leave an alarm on FailedInvocations.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Testing with a hand-written event
It may differ from the real event. Capture a real one.
Looking only at the target
If TriggeredRules is zero the target is not the problem.
Assuming CloudTrail events appear automatically for all services
Management events arrive on the default bus, but some data events need a trail or service-specific setup.
No DLQ on targets
Failed deliveries disappear once the retry period ends.
Frequently Asked Questions
Why does my EventBridge rule show no invocations?
Either no event matched, so check the bus and pattern, or events matched but the target is misconfigured. The TriggeredRules and FailedInvocations metrics separate the two.
Is EventBridge pattern matching case-sensitive?
Yes. Values must match exactly unless you use content filtering operators designed for that purpose.
How do I replay missed events?
If you use an archive, you can replay events to a bus. Otherwise, a target DLQ keeps the undelivered ones for reprocessing.
Want Help With Fixing an EventBridge rule that is not triggering?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required