Plans and usage

Copy page

Free, Starter, Grow and Unlimited plans, the rolling 30-day allowance, what counts as a trigger event, quota alerts at 80% and 100%, and how to reduce usage.

Workflow Trigger Extensions is free to install. Paid plans raise the event allowance, which is counted over the last 30 days.

Plans

Plan	Price	Trigger events per 30 days
Free	$0	5,000
Starter	$25	25,000
Grow	$50	75,000
Unlimited	$100	Unlimited

Every trigger is available on every plan, including Free. Plans differ only in volume.

The allowance is a rolling 30-day window

Your usage at any moment is the number of events this app fired in the last 30 days. It is not a calendar month and there is no reset date: each event stops counting exactly 30 days after it fired, and that part of the allowance becomes available again on that day.

This matters when usage comes in bursts. A bulk edit on the 30th of one month still counts during the first weeks of the next, so the usage shown on Home can be higher than what you fired since the 1st. Once a day has dropped out of the window, triggers resume by themselves for as many events as that day held.

What counts as an event

One event is counted each time a trigger from this app fires and delivers to Shopify Flow.

Triggers from Shopify or from other apps are not counted. Only this app's triggers consume the allowance.
A change that is detected but does not match an enabled trigger is not counted.
The typed metafield triggers (Order, Product, Product Variant and Customer Metafield Update) share a single event with the generic Metafield Update trigger, so they do not double-count.
Storefront triggers count like any other event: one per shopper action that reaches us. Events dropped in the browser because the shopper declined analytics consent never reach us and never count. Out-of-Stock Variant Viewed needs every product view to do its job, so enabling it counts every product view. See Storefront triggers.

How custom triggers are counted

A Custom triggers runs your code for every event of the type it listens to, and each of those runs counts as one event - including the ones your code filters out by returning null.

Why it works that way. Shopify sends us the event whether or not your code ends up firing on it. We receive it, check it is not a duplicate, queue it, and start an isolated sandbox to run your code with a time and memory budget of its own. All of that has already happened by the time your code decides to return null. Counting only the fires would mean a trigger that inspects 60,000 product updates and fires 100 times is billed for 100, while the work done was 60,000.

What this means for your bill: a custom trigger costs the same as the built-in trigger listening to the same event. Product Update counts 60,000 either way. You are not paying extra to filter - you are paying the same and getting conditions Flow cannot express, output shaped the way you want, and data the event does not carry.

The one thing it is not is a way to spend less. To genuinely reduce usage, listen to a narrower event or switch the trigger off - both stop the events reaching us at all.

Testing is always free: neither the Run test button nor the /test API endpoint uses your allowance.

The app's home page with events, plan usage, success rate and the current plan — Home shows your usage against your plan for the last 30 days, next to the events per trigger.

Quota alerts

The app emails you when usage crosses 80% and again at 100% of the allowance. Recipients and the 80% threshold are configurable in the app's notification settings; the threshold can be set anywhere between 50% and 99%.

Each alert is sent once per calendar month. Changing plan re-arms the alerts against the new limit. Stores on Unlimited never receive quota emails.

What happens at 100%

Once the allowance is used up, triggers stop firing until enough events have left the 30-day window or you upgrade. Your configuration is untouched: settings, permissions, and workflows are all preserved, and firing resumes by itself the moment there is allowance again.

This is worth understanding precisely, because it is not recoverable:

Nothing is replayed. There is no backlog to drain. An order that changed while you were over the limit does not fire when you upgrade.
The gap is invisible in Event History. Blocked events never create a history row, so you cannot look back afterwards and see what you missed.
Change detection moves on regardless. For a field-level trigger, the app still records the new value as its baseline even though the trigger did not fire. After you upgrade, the next change is compared against that newer value, so the missed change cannot resurface later. One exception: for the variant triggers (price, SKU, barcode and unit price), when allowance frees up because older events leave the 30-day window rather than through an upgrade, a variant change made while you were over the limit can still be reported once, at that product's next update.

A worked example. You are on Free (5,000) and hit the cap on the 20th:

On the 22nd a customer changes an order's shipping address. Order Shipping Address Changed does not fire, and the event is gone.
On the 23rd you upgrade to Starter. Triggers resume immediately.
On the 24th someone edits that same order's address again. This fires normally, comparing against the address from the 22nd.

The change on the 22nd is never delivered, in step 2 or at any later point.

Keeping usage down

If you are consuming more than you expect, the cause is almost always one of the broad ... Update triggers firing on every edit, or a storefront trigger on a busy store:

Open Home and look at the per-trigger breakdown.
Open the Triggers page and switch off the broad ... Update triggers your workflows do not use.
Prefer a narrow trigger over a broad one. Product Variant Price Changed fires far less often than Product Update.
Switch on Storefront Product Viewed and Out-of-Stock Variant Viewed only for a workflow that needs them. On a high-traffic store they are the highest-volume triggers in the app.
Before a bulk import or a stock sync that touches thousands of records, switch off the triggers that would fire once per record and switch them back on afterwards. Inventory triggers fire once per variant and location changed, so a stock sync can use the whole Free allowance in a day.