← Back to all posts
6 min read

The free-plan ops math

Make.com's free plan hands you 1,000 operations a month. That sounds generous until you learn what actually costs one.

I learned it while planning an automation that posts my GitHub commits to a Facebook Page. The design died on a spreadsheet before I built a single module — which is exactly where bad designs should die.

What costs an operation

Every module execution counts as an operation. The part that surprises people: a polling trigger consumes at least one operation per cycle even when it finds nothing. An empty check-in is not a free check-in. Failed and incomplete runs count too. Your budget doesn't care whether the work succeeded; it cares that work was attempted.

The arithmetic

Take the most natural-sounding setup: watch a repo for commits, polling every 15 minutes because "instant-ish" feels right.

Polling trigger, 15-minute interval:
4 checks/hour × 24 hours × 30 days = 2,880 cycles/month
→ dead on arrival. Over budget before a single commit exists.

Polling trigger, hourly:
1 × 24 × 30 = 720 cycles/month
→ fits, but idling eats 72% of the entire monthly budget.

Webhook trigger:
idle cost = 0 operations
one push ≈ 2 operations (trigger + action)

Same outcome, three architectures, two orders of magnitude apart. The 15-minute version isn't slightly over budget — it's nearly 3× the entire plan before the first real event fires.

The real-world decision

Back to the GitHub-to-Facebook scenario. Two options were on the table:

  • Watch Commits trigger (polling): zero extra setup, but hourly — the only affordable interval — spends ~720 ops/month just looking at repos that changed maybe twice a week.
  • Custom webhook: paste a URL into each repo's settings once, then every push delivers itself instantly for about 2 operations. Idle cost: zero.

The webhook won without hesitation. It required ten minutes of manual setup in GitHub's settings panel; the polling alternative would have burned most of a month's budget watching empty repos. Put differently: one quiet afternoon of actual commits costs less than one idle hour of 15-minute polling.

The decision rule

  • Need instant reaction? Webhook, always — even on paid plans, latency for free beats latency for $9.
  • Source offers webhooks? Take them. A little one-time setup buys permanent zero-idle cost.
  • Forced to poll? Stretch the interval to the longest tolerable delay, and prefer a daily batch sweep over frequent checks whenever latency tolerance exists.
  • Before building anything: multiply cycles-per-month × modules × expected runs. If that number makes you wince, redesign now — the spreadsheet is cheaper than the bill.

This travels beyond Make

n8n plays the same game: polling triggers have undocumented default intervals — a Gmail trigger with no explicit schedule quietly polls roughly hourly. I've been bitten by exactly that. Zapier counts "tasks" the same way. The platforms differ; the math is identical everywhere.

On paid plans, sloppy intervals are a rounding error. On free plans, they're the whole bill. Architecture is budget.

Want the producer side of this story — building payloads cheap enough to matter? Read Feeding Make.com from Python.