Why Your IFTTT Applet Fires Late: Polling, Webhooks, and What the Delay Actually Means

You connect a "new email arrives" trigger to a "log a row in Google Sheets" action, send yourself a test message, and stare at the spreadsheet. Nothing. Five minutes later the row appears. The applet isn't broken — it's polling, and understanding that distinction is the single most useful thing you can learn about how IFTTT actually works under the hood.

The takeaway: IFTTT triggers come in two flavors — periodic polling and webhook push — and they have very different latency, reliability, and quota characteristics. Knowing which one your applet uses tells you what delay to expect, why it sometimes misses events, and when IFTTT is the wrong tool for the job.

Polling triggers: IFTTT asks, on a schedule

Most service triggers (new Gmail message, new RSS item, new row in a sheet, weather changes) work by polling. IFTTT's servers call the third-party API at intervals and ask, essentially, "anything new since last time?" The connector then compares the response against stored state and fires the action only for genuinely new items.

Two consequences follow. First, latency is bounded by the poll interval, not by when the event happened. Depending on the service and your plan tier, that interval can range from roughly a minute to an hour — IFTTT doesn't publish exact per-service intervals, so treat any specific number you see quoted online with suspicion. Second, if the third-party API is down or rate-limited during a poll window, the trigger silently waits for the next cycle. Nothing in your dashboard will scream about it; the run just appears later.

Webhook triggers: the event pushes to IFTTT

The Webhooks service flips the direction. You (or a device, or a script) make an HTTP request to a unique IFTTT URL, and IFTTT evaluates the applet immediately. This is the low-latency path, and it's also the escape hatch for connecting things IFTTT doesn't natively support — a home sensor, a CI pipeline, a cron job on your own server.

A concrete example: you have a small script that checks whether a nightly database backup succeeded, and you want a phone notification only on failure. Create an applet with the Webhooks "Receive a web request" trigger (event name backup_failed) connected to the Notifications action. Then, from the machine that runs the backup — with whatever user owns the cron job — call:

curl -X POST \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"value1\":\"prod-db\",\"value2\":\"exit code 2\"}' \\\n  https://maker.ifttt.com/trigger/backup_failed/with/key/YOUR_KEY

Replace YOUR_KEY with the key from the Webhooks service documentation page in your IFTTT account. The three value1–value3 fields become ingredients you can drop into the notification text. The risk to know about: anyone with that URL can fire your applet, so treat the key like a password and don't commit it to a repository. If it leaks, regenerate it in the Webhooks settings.

Verification is straightforward: after firing the curl, check the applet's activity feed in the IFTTT dashboard. You should see a run entry with a timestamp within seconds of your request, and the notification should arrive in the same window. If the dashboard shows the run but the notification never landed, the problem is on the action side (device notification permissions, app sign-in), not the trigger.

Filter code: the conditional layer between trigger and action

On paid tiers, IFTTT lets you insert JavaScript filter code between trigger and action. This is where the "conditional" part of the engine gets real: instead of firing on every trigger event, the applet evaluates your code and can skip the action entirely.

The classic use case is time-of-day gating — "only notify me about motion detection between 11pm and 6am." Filter code receives the trigger's ingredients as variables and calls If Notifications.sendNotification.skip() (the exact call depends on your action) to suppress the run. Two things worth knowing before you rely on it:

• Filter code runs in a sandboxed environment with a short execution limit. It's for branching logic, not data processing — no external HTTP calls, no heavy computation.
• A skipped run may still count toward your usage depending on plan terms, so check your account's current quota rules rather than assuming skips are free.

Quotas and the trade-off you actually sign up for

IFTTT enforces per-account execution limits, and the free tier's caps are tight enough that a chatty trigger (an RSS feed that publishes fifty items a day, say) can exhaust your allowance while your important applets queue behind it. Plan tiers, applet counts, and multi-action support change over time, so verify current limits on IFTTT's pricing page before designing around them — don't trust any blog post, including this one, for numbers.

The deeper trade-off is architectural. IFTTT's connectors handle OAuth flows, retries, and error classification for you, which is genuinely valuable — you never write token-refresh logic. In exchange, you give up control over timing, ordering, and failure handling. There is no dead-letter queue, no replay, and no guarantee a polling trigger observed every intermediate state. A sheet row that was created and deleted between polls effectively never existed as far as your applet is concerned.

Deciding whether IFTTT fits your problem

IFTTT is a good fit when the event is low-frequency, the latency tolerance is minutes-to-hours (or you're using webhooks), and a missed event is annoying rather than costly. It's a poor fit when you need guaranteed delivery, sub-second reaction, or an audit trail you control — that's when you point the source system at your own endpoint or a queue instead.

The actionable step: pick one applet you already rely on, open its activity feed, and compare a few trigger timestamps against the actual event times in the source service. That gap — seconds, minutes, or an hour — tells you which trigger type you're on and whether the tool matches the job you thought you gave it.