AWS EventBridge Pattern Tester

Match a pattern against an event without creating a rule and waiting to see whether anything arrives. The matching runs here, in your browser.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Test. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

A bare string in the pattern

The rule is created and never fires

pattern:
{ "source": "aws.s3" }
event:
{ "source": "aws.s3", "detail-type": "Object Created" }

A pattern that matches

Every named key found, and the rest of the event ignored

pattern:
{ "source": ["aws.s3"], "detail": { "object": { "key": [{ "suffix": ".pdf" }] } } }
event:
{ "source": "aws.s3", "detail-type": "Object Created", "detail": { "object": { "key": "uploads/report.pdf", "size": 4096 } } }

A pattern that does not

The exact place they disagree, rather than a rule that stays silent

pattern:
{ "source": ["aws.s3"], "detail": { "object": { "size": [{ "numeric": [">", 8192] }] } } }
event:
{ "source": "aws.s3", "detail": { "object": { "size": 4096 } } }

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Writing a pattern value as a plain string

    Every leaf in an event pattern is an array of alternatives, so a bare string matches nothing and the rule is created without complaint.

    Instead:Wrap it: "source": ["aws.s3"].

  2. Expecting a pattern to match values that differ only in case

    Matching is exact. There is no case folding and no partial matching.

    Instead:Use equals-ignore-case, or prefix and wildcard where the value is not under your control.

  3. Using two numeric filters to express a range

    Each leaf takes one list of alternatives, and two filters in the array are alternatives rather than requirements, so either one matching is enough.

    Instead:Write both bounds in one filter: { "numeric": [">=", 100, "<", 200] }.

A leaf value that is not an array matches nothing

Every value in an event pattern is a list of alternatives, so "detail-type": "Object Created" matches nothing while "detail-type": ["Object Created"] matches. The rule is created either way, and it simply never fires.

Which is a hard failure to debug from the outside

There is no error, no metric that distinguishes it from a quiet event bus, and the rule looks correct in the console. The only signal is that the target is never invoked.

Keys the event has and the pattern does not are ignored

That is the model: a pattern is a subset the event has to satisfy, not a shape it has to equal. So a narrow pattern is narrow because of what it names, not because of what it leaves out.

Matching is exact and case sensitive

There is no partial matching. A pattern that works today stops matching silently if a producer changes the case of a value or adds a prefix, which is what prefix, wildcard and equals-ignore-case exist for.

An array in the event matches if any element does

So resources: ["arn:aws:s3:::my-bucket"] in a pattern matches an event whose resources array contains that value among others. The same applies to an object sub-pattern against an array of objects.

anything-but can wrap a prefix

Which is how you exclude a whole namespace rather than a list of values. numeric takes pairs of an operator and a number, and every pair has to hold, so a range is written as one filter rather than two.

exists is the only operator that reads an absent field

It works on leaf nodes, and exists: false is the way to match events that do not carry an optional attribute. Everything else requires the field to be there before it can compare anything.