Which Events Actually Run a Job, and Which Get Filtered

The default is not “runs on nothing.” The default is “runs on everything.”

---

An event-triggered job is subscribed to a stream, and streams are busier than they look. If no filter expression is set, every event passes and triggers an agent run — which is the correct default for a job you are still designing and the wrong one for a job you have left running.

What a filter is evaluated against

When an event arrives on a push job — or a cron tick fires carrying a payload — the filter is evaluated against that payload. Return false and the run is skipped and recorded with the Filtered status.

That recording matters more than it sounds. A filtered run is not a silent non-event: it is a visible statement that the job saw something and declined it. When a job is not doing what you expected, the first question is which of the two it is — no events arriving, or events arriving and being filtered out — and the status answers it without guessing.

The syntax

Filters use filtrex, a safe sandboxed expression language, with the payload under the event namespace:

event.source == "aws-marketplace"

event.amount > 1000

event.action == "entitlement_created" and event.partner == "AWS"

lower(event.status) == "active"

Available functions: lower(), upper(), and includes() for checking whether an array contains a value. Dot notation reaches nested fields — event.buyer.name, event.offer.info.commits.

lower() is the one to reach for by habit. Comparing a status field exactly is a filter that works until the day a system sends Active instead of active, and that day arrives without an announcement.

How to write one that keeps working

Filter on the field that means what you want, not the field that happens to correlate with it. event.amount > 1000 and event.action == "entitlement_created" are both narrow, but only one of them will still mean the same thing after somebody changes your pricing.

Start permissive, then tighten. Run the job with no filter, look at what actually arrives, then write the expression against real payloads. Writing the filter from the shape you expect is how you end up with a job that has been silently filtering everything for a week.

Check the Filtered count after you deploy one. A job that suddenly stopped producing runs and a job that is correctly declining irrelevant events look identical from a distance and completely different in the status column.

Frequently asked questions

What happens if a job has no filter expression?

Every event passes and triggers an agent run. The default is permissive, which suits a job you are still designing and not one left running.

What does the Filtered status mean?

The event arrived, the filter evaluated to false, and the run was skipped — recorded rather than discarded, so you can tell “no events” from “events declined.”

What syntax do filter expressions use?

Filtrex, a safe sandboxed expression language, with the event payload under the event namespace. lower(), upper() and includes() are available, and dot notation reaches nested fields.

How do I compare a status field safely?

Wrap it in lower(). An exact comparison works until an upstream system sends a differently-cased value, which happens without warning.

Why is my job not running?

Check whether events are arriving at all, then whether they are being recorded as Filtered. The two look the same from outside and have opposite fixes.

Takeaways

• No filter means every event runs the job — the default is permissive.
• A skipped run is recorded as Filtered, which is how you tell silence from rejection.
• Filtrex syntax, event namespace, lower() / upper() / includes(), dot notation for nested fields.
• Use lower() on anything case-sensitive by habit.
• Write the filter against payloads you have actually seen, not the ones you expect.

More on triggers and scheduling in jobs.