IFTTT Pro Filter Code Execution Limits and Rate Throttling

Short Answer

Your Pro filter code is evaluated when the trigger event is processed, before the action stage, so a filter that returns false (or calls Service.action.skip()) still consumes an event-processing cycle — but it is recorded as a skip, not a successful action run. As for a numeric throttling threshold: IFTTT does not publish one. Any specific trigger-frequency or execution-time numbers you find in forums are anecdotal, plan-dependent, and subject to change. The authoritative signal for your account is the Applet's activity feed, which distinguishes runs, skips, and failures.

Confirmed vs. Likely

Well-established behavior

• Filter code is a small JavaScript snippet evaluated per trigger event, executed before the action. Skipping prevents the action from running.
• Filter code runs in a constrained sandbox: a short execution window, no network access, and a limited standard library. A script that throws or times out generally fails or skips that run rather than queueing.
• Polling-based triggers (RSS, most cloud services) are checked on IFTTT's poll cadence, so "rapid firing" is bounded by that interval regardless of filter complexity. Webhook/instant triggers behave differently and are the relevant case for true high-frequency testing.
• Applets that error repeatedly may be automatically disabled or flagged.

Likely, but not officially confirmed

• A skipped run consumes event-processing resources but is not accounted the same as a completed action run. Whether it counts toward any internal quota is not publicly documented.
• Filter complexity is unlikely to be the primary throttling driver; trigger type and event volume matter more. Treat this as a hypothesis, not a guarantee.

How to Verify on Your Own Account

Because thresholds are unpublished and may vary by plan tier (Free/Pro/Pro+), run a scoped experiment:

1. Create a test Applet with a Webhooks trigger (instant, not polling) and filter code that always skips the action.
2. Fire events at increasing rates — start at 1/minute, step up to several per minute — using a simple loop:

   for i in $(seq 1 60); do
     curl -s -X POST "https://maker.ifttt.com/trigger/YOUR_EVENT/with/key/YOUR_KEY"
     sleep 1
   done

3. Compare the number of webhooks sent against the activity feed. Check whether skipped runs appear, whether any events are silently dropped, and at what rate.
4. To determine whether filter evaluation precedes throttling, add a conditional logging action (e.g., append to a spreadsheet) on a second Applet with the same trigger and compare logged evaluations against received webhooks.

Practical Recommendations

• Keep filter code cheap: simple comparisons on trigger fields, no loops over large data, no date parsing you can avoid.
• If you need high-frequency conditional automation, prefer pushing the condition upstream (filter at the source service or in a small webhook intermediary) so IFTTT only sees events that should act.
• Monitor the activity feed's run/skip/failure breakdown after enabling a new filter — it is the only per-account ground truth IFTTT exposes.

One detail that would change this advice: which trigger type you're using. If it's polling-based, your frequency ceiling is IFTTT's poll interval and filter throttling is largely moot; if it's webhooks, the test above is the way to find your real limit. For an authoritative quota statement, IFTTT support is the only reliable source — treat everything else, including this article's "likely" section, as observation rather than SLA.