Twenty inquiries do not mean twenty checks
Illustrative scenario: a studio receives twenty inquiries a month. One connection waits for a new-form notification. Another checks every fifteen minutes for new submissions. Both can deliver the same twenty inquiries, but the second keeps working overnight when nothing arrives.
A webhook is a notification one app sends another when an event occurs. Polling means the recipient repeatedly asks for changes. A third route schedules the whole workflow, which then searches for new data. The platform may account for these routes differently.
Count checks before choosing a plan
For an illustrative thirty-day month running around the clock:
| Interval | Calculation | Monthly checks |
|---|---|---|
| 15 minutes | 30 × 24 × 4 | 2,880 |
| 5 minutes | 30 × 24 × 12 | 8,640 |
| 1 hour | 30 × 24 | 720 |
These are scheduled-check counts, not automatically billable units or prices. Restricting checks to working hours reduces the count but delays weekend inquiries. Events are not necessarily separate projects either: the same inquiry may be delivered more than once.
For eight operating hours on 22 workdays, a fifteen-minute interval gives 22 × 8 × 60 ÷ 15 = 704 checks. This models a regular interval grid within the operating window; boundary scheduling, timezone changes, or outages can change the actual count.
The exact trigger matters
n8n distinguishes scheduled runs from polling triggers. A Schedule Trigger counts toward the quota each time it fires; a polling trigger counts when it finds new data. Webhook requests have their own accounting rules. Do not use one billing assumption for every trigger type.
In Make, inspect the consumption of the actual modules and your account history. Do not treat the table’s run counts as credit counts: one run can perform several billable steps. Add prices only after checking your plan and its billing rules.
Faster is not always better
A fifteen-minute delay may be acceptable for routine inquiries if the team responds a few times a day. Time-sensitive work may need an immediate event. Choose latency around the human task, rather than the shortest available interval.
A webhook requires the source to support outbound notifications. Check that feature on your actual plan, how the sender is authenticated, and whether a missed event can be retrieved. Do not publish a webhook address in client instructions when it is a private entry point into your process.
The event arrived. Did the work finish?
Receiving a notification does not prove the CRM record was saved. Make’s scenario settings also cover ordered processing, which affects behavior when a run is incomplete. You still need the original source and a way to find missing results.
Write down four answers: how long the task can wait, how a new event is detected, how consumption is counted, and where a missing record can be found. Then enter the assumptions into the total-cost calculator.
n8n accounting rules and Make settings reviewed October 1, 2026. Interval calculations are modeled, not measured consumption or a price comparison between tested accounts.