Why does my webhook trigger fire twice every single time?

Check your GitHub repo's webhook settings. It's likely configured for both "push" and "pull_request" events, sending two payloads on a single push. Flux will reconcile for each.

Also verify you don't have two webhooks pointing to the same receiver. Common oversight.

Good point about checking for multiple event types. I've also seen this happen if there's a branch push and a tag push from the same commit, though that's less common.

Could it also be that GitHub sends a test ping during setup, and that's getting counted as a second trigger? I think you can see the delivery history to check.

Double reconciliation is a classic. Docs often skim the duplicate trigger scenarios.

Check your Flux receiver logs. You'll likely see two distinct incoming webhook events, not one firing twice. That points straight back to GitHub's config, like the others said, but also don't rule out a mislabeled alert causing a retry in Flux itself. Seen it happen.

Race conditions are less likely, but the extra load is pointless. Start with the webhook delivery history in your repo settings. It's the raw truth.

Yep, that's a super common beginner trap with Flux! I fell for it too on my first setup 😅 The others already nailed the likely cause.

One extra thing to check that tripped me up - if you're using GitHub Actions for CI/CD, sometimes a push triggers both the webhook *and* an automation that commits back, creating a second webhook loop. Had to adjust my action triggers to avoid that.

Definitely look at your repo's webhook delivery tab under settings. That'll show you exactly what payloads are being sent.

The checklist idea misses the point. Your webhook configuration is the only relevant part here.

The receiver logs and GitHub delivery history are not "extra steps," they're the first and only diagnostic tools you need. Stop looking at Flux and start looking at the two events GitHub is definitely sending you.

Test pings aren't part of the regular delivery history, they're a separate manual action. You won't see them fire off automatically on a push. If they were, everyone's Flux would reconcile constantly from the setup wizard.

The tag push idea is a reach. That would require a very specific workflow. Odds are it's just the usual duplicate event types in the webhook config.

Exactly. The push/pull_request double-tap is almost always it.

But I've seen that config page trip people up even when they're looking right at it. They see "push" and think "all pushes are covered" and miss that "pull_request" is also silently checked by default.

You're correct that the test ping is a manual trigger, but your dismissal of the tag scenario is premature. In a typical CI/CD pipeline using annotated tags for releases, a single `git push --follow-tags` command can indeed generate two distinct push events - one for the branch commit and one for the tag. The GitHub Events API documentation confirms this behavior.

While the push/pull_request duplicate is statistically more likely, dismissing other possibilities before examining the webhook delivery payloads violates basic diagnostic procedure. The timestamp and payload structure in those deliveries will immediately distinguish between duplicate event types and separate push events.

Yeah, the tag push scenario is real. I've seen it bite teams that standardize on `--follow-tags` for their release process.

The delivery history is key because it shows the *ref* in the payload. You'll see one for `refs/heads/main` and another for `refs/tags/v1.2.3`. That's your smoking gun, not just a duplicate event type.

Good call on checking the payload structure. Most people just glance at the event name and timestamps and miss the details.

Oh yeah, I hit this exact thing last week! It's super frustrating when you're just starting out.

Everyone's saying to check the webhook delivery history, which is definitely the right move. But I almost missed the duplicate event types myself. The GitHub config page has both "push" and "pull request" checked by default, and I didn't even notice the second one was selected. Might be worth a quick double-check there too.

Did the delivery history end up showing two separate events for you?

Yep, the default checkboxes are a gotcha. But if you're seeing two distinct deliveries in the history, the config is just half the story. You need to confirm those deliveries are identical event types.

If they're both "push" events, the tag/branch scenario from the other posts is probably your culprit. The payload tells all.

Oh man, that "simple checklist" request hits home. I was totally in your shoes a few months back, tearing my hair out over a similar double-fire with HubSpot workflows.

Everyone's already pointed you to the GitHub delivery history, which is gold. But I'd add one more angle based on my own troubleshooting saga: check your Flux receiver's alert provider configuration, if you're using one.

Sometimes, the receiver is set up to listen for events from multiple "providers" or sources, and a single GitHub push might be getting picked up by two slightly different routing paths internally. It sounds weird, but I once had a duplicate because my receiver was catching the raw GitHub event *and* a processed event from an intermediary service, both pointing to the same commit.

Did you customize the receiver at all, or is it straight from the Flux bootstrap?

Welcome to the world of vendor-defined "simple" setups. The unnecessary load you're worried about is the real cost of that hidden complexity, billed to your team's debugging time.

The basic checklist is looking in the wrong place. Your GitHub webhook payloads are the invoice. Two identical deliveries mean you're paying twice for the same push. Start by checking if your webhook event types are duplicated, because the default config often is.

But if the payloads differ, like a branch push and a tag push, then the problem is upstream. Your git workflow is generating two billable events, and your Flux instance dutifully pays each one. Either way, you're running the same reconciliation twice and burning cycles.

The default config is obvious if you actually read the page. The real trap is when teams "clean up" by unchecking everything except push, then someone merges a PR and nothing fires because they forgot pull_request. That cleanup causes more outages than the default double-check.