Use webhooks when you need to react quickly and the sender supports them, and use polling when you need certainty or the sender has no webhooks. Most reliable security automations combine both: webhooks for speed, a scheduled poll to catch anything missed.
How each works
A webhook is pushed to you when an event occurs. Polling means your code asks the API on a schedule, "what changed since last time?".
Decision table
| Question | Webhook | Polling |
|---|---|---|
| Need to react in seconds | Good fit | Delay equals the interval |
| Sender supports webhooks | Required | Not needed |
| Your receiver can be reached from the internet | Required | Not needed |
| Missed events would be costly | Risky alone | Safer, you control the cursor |
| Many events in bursts | Needs a queue | Naturally paced |
| Behind a firewall with no inbound access | Hard | Easy, outbound only |
Why webhooks alone are not enough
Deliveries can be lost or delayed. Atlassian's Jira documentation says a failed webhook is retried up to five times with randomized back-off of 5 to 15 minutes, that duplicates are possible, and that if a recipient keeps failing for 30 minutes Jira limits it to one attempt per webhook until a delivery succeeds. GitHub's guidance says that after an outage you should resend webhooks your server missed. In both cases you need a way to recover, and recovery means asking the API what you missed.
Why polling alone is not enough
Polling adds delay, spends API quota, and can hit rate limits if the interval is short and the data set is large. For an urgent finding on an exposed service, waiting for the next poll may be too slow.
The hybrid pattern
- Receive the webhook, verify the signature, enqueue it, reply 2XX.
- In the worker, fetch the current object from the API. Do not trust the payload as the final state.
- Run a reconciliation poll on a schedule, for example every 15 minutes or hourly, asking for items changed since the last successful cursor.
- Use a stable id so the poll and the webhook do not both create work for the same event.
- Alert if no webhook has arrived for longer than expected. Silence is a signal.
Pick by situation
- Small team, one ticket system, internet reachable receiver: webhook plus hourly poll.
- Strict network with no inbound traffic: polling only, with a short interval for critical items.
- Sender without webhooks: poll, and keep a cursor so you only fetch changes.
Quick check
Can I rely on webhooks only?
Not safely. Deliveries can fail or be throttled, so add a periodic poll to catch missed events.
Why re-fetch the object after receiving a webhook?
The payload may be stale or out of order. Fetching the current object gives you the true state.
Safeguard exposes capabilities through APIs and an MCP server, and offers a free scan at gold.safeguard.sh/scan.
Sources
- Atlassian, Jira Cloud webhooks
- GitHub Docs, Best practices for using webhooks
Last reviewed: 19 October 2026.
