Automation Rules are not triggering via Incoming Webhook.

[Jacob Beatty]

Hello, 

I use multiple POSTs during my build pipeline to trigger Automation Rules. I can see that the Webhook URL is being reached with a 200 result, and I have confirmed this in my pipeline and through Postman, but the rule is not running. I have tested regenerating the URL and secret, running only a send email event after the incoming webhook and still no rule is running. 

Thanks,

Jacob

[Jayesh Raghuvanshi]

@Jacob Beatty 

A 200 OK on the incoming webhook endpoint does not guarantee the rule fired; confirm execution in the rule’s audit log and ensure the secret token is passed correctly with each POST.​
Always validate using the audit log, not the HTTP status, when diagnosing incoming webhook triggers

For Jira Cloud

• Send the secret with X-Automation-Webhook-Token in the header or append /<secret> to the webhook URL if your caller cannot add headers, otherwise the rule won’t trigger even if you see 200
• A null body with HTTP 200 is normal; verify the rule actually ran in the automation audit log for confirmation
• Copy the current webhook URL and Secret from the trigger and update all callers; recent platform updates require using the new format/secret in your pipeline and Postman
• If the rule doesn’t need an issue, set Work item criteria to “No issues from the webhook”; if it expects an issue, include the issue key/fields in your payload

For Jira DC

• Check the rule’s audit log and atlassian-jira.log; proxies/WAFs commonly strip headers/bodies causing silent drops before the trigger fires
• Use Atlassian’s webhook troubleshooting flow: enable DEBUG for com.atlassian.webhooks and org.apache.http, and capture a RequestBin to verify payload and headers end‑to‑end
• Align the rule’s Work item criteria with your payload (use “No issues from the webhook” if you’re not passing an issue) to prevent the rule from idling after a 200 response

Thanks
Jayesh R

[Rick Westbrock]

I think that once the option to add authentication to incoming webhooks was added if you pass invalid credentials the rule will still return an HTTP 200 response.

[Marc - Devoteam]

Hi @Jacob Beatty 

Whenever you ask for help with an Automation Rule it will help us to help you if you provide:

1. what type of project is this (e.g., company-managed, team-managed, etc.), 

2. images that show your complete rule.

3. images showing the details of any relevant actions/conditions/branches.

4. images showing the Audit Log details for the rule execution.

5. Explain where the issue is.

These questions are not for not willing to help, but to have community members understand on how automation works.

[Darryl Lee]

Hi @Jacob Beatty and welcome to the Community!

I would strongly suggest filing a support ticket, because one of the lingering effects of the AWS outage on Monday was delayed Automation executions, and I wonder Webhook URL triggers are still having issues that Atlassian isn't aware about.

This was supposedly resolved at Oct 22, 06:47 UTC:

Oct 22, 2025

Delay in execution of Automation rules

Resolved - Our teams have identified and fixed the root cause of the issue that caused delay in executing Automation rules. This was caused due to scaling issues following on from the recent AWS outage.
This issue is marked as resolved.
Oct 22, 06:47 UTC

Identified - Atlassian team has identified the cause of the issue that led to delay in execution of Automation rules. This is a follow-on effect of the recent AWS outage.
We shall keep you informed of the progress every hour, if not sooner.
Oct 22, 06:34 UTC

Investigating - We understand that our customers are experiencing delay in execution of Automation rules. While our team is investigating further on this, it looks like a follow-on effect of the recent AWS outage.
We continue to investigate further on this and we shall keep you informed of the progress every hour if not sooner.
Oct 22, 06:20 UTC

Confluence: https://confluence.status.atlassian.com/incidents/wn25kdl448xp

Jira: https://jira-software.status.atlassian.com/incidents/x8vw6z01p2q8

(Reports are identical.)