Jira Cloud webhooks suddenly became unreliable starting April 20, 2026

[Davyd Melnychuk]

Hello Atlassian Community,

We are investigating a severe and unexpected issue with Jira Cloud webhook delivery that began on Monday, April 20, 2026.

Our application depends on Jira webhooks to receive ticket updates from boards in our internal system. Before that date, webhook callbacks were delivered almost instantly and consistently. Starting April 20, delivery dropped dramatically, in some cases to nearly zero. We now receive only an occasional webhook over a long period of time, even though the webhooks were successfully created and the callback URL is reachable.

We are using the official Jira Cloud webhook APIs, including:

• Get dynamic webhooks for app
• Register dynamic webhooks
• Delete webhooks by ID
• Extend webhook life

Relevant documentation:

• Jira Cloud REST API webhook group: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-webhooks
• Jira Software webhook guide: https://developer.atlassian.com/cloud/jira/software/webhooks/

We also attached a screenshot showing the webhook is present and properly configured.

 

What we have already verified

No configuration was changed on our side when the issue started. We also verified that:

• the webhook was created successfully through the REST API,
• it is present and active,
• the configured events and JQL filters match what we intended,
• the callback endpoint is publicly reachable,
• our service is returning successful responses for incoming requests,
• we are not using deprecated REST API behavior for webhooks,
• the experimental Get failed webhooks endpoint returned no failed webhook data (used manually in Postman to validate whether any webhook-related errors could take place),
• Atlassian status pages showed Jira and related products as operational, with no webhook-related incident reported.

Common questions we checked in advance

Registration and quota restrictions
According to Atlassian documentation, OAuth 2.0 apps have webhook limits, and legacy Connect apps have different limits. In our case, this does not appear to be the issue because we use only one webhook per board/user context, and we are not approaching any quota boundary. We also tested both older long-lived webhooks and freshly created ones, and the issue reproduces in both cases.

Network and URL constraints
Our callback endpoint is public, uses HTTPS, and is reachable. Since some webhook requests still do arrive, this does not look like a certificate, firewall, redirect, or port-related problem.

JQL filtering constraints
We are following the supported JQL filtering recommendations and are not relying on unsupported filtering behavior. We do not believe JQL filtering is the cause of the missing deliveries.

Concurrency and throughput limits
Our usage is very light. We generally receive only one request per change, and our handler responds in under a few seconds. We are far below any expected concurrency or throughput limit.

Retry policy
We are not seeing signs of failed delivery or retry behavior on our side. The endpoint is reachable and responding, so this does not look like a retry-loop or timeout issue.

Observed behavior

The key symptom is that webhook delivery suddenly became extremely sparse starting April 20, 2026. Some events still appear, but the majority do not. From our perspective, this looks like deliveries are being skipped or not sent at all, rather than simply delayed.

Questions for the community

Has anyone else seen a similar drop in Jira Cloud webhook delivery starting around April 20, 2026?

Could this be related to any backend change, delivery issue, or undocumented behavior on Atlassian’s side?

Are there any additional diagnostics we should check to determine whether events are being dropped before delivery?

Any guidance would be greatly appreciated.

[Arkadiusz Wroblewski · Accepted solution]

Hello @Davyd Melnychuk 

Based on what you’ve shared, I wouldn’t worry about your JQL or webhook registration for now. Your filter looks solid, the webhook is active, and the expiration hasn’t passed yet.

The key thing to remember is that the "failed webhooks" log only tracks attempts that Jira actually tried to deliver but ultimately gave up on after several retries. If that log is empty, it doesn't necessarily mean Jira is sending everything; it just means it hasn't logged any specific delivery failures.

Since you're dealing with standard issue events (create, update, delete), these should be consistent even with light traffic. The best way to troubleshoot this is to register the exact same webhook to a second endpoint, something like a request bin. If both endpoints miss the same events, you have a very strong case that the issue is on Atlassian’s side. If the second endpoint receives them, the problem is likely somewhere in your current delivery path or server configuration.

One thing to keep in mind is that since you're on a Free site and posting in the Community, no one here has the "under the hood" access to inspect Atlassian's webhook pipeline or your specific tenant logs. Once you have that side-by-side test finished, your next move should be to take those results directly to Atlassian Support.

[Davyd Melnychuk]

Hi @Arkadiusz Wroblewski , thanks a lot for the suggestions, really appreciate it.

Just to clarify, we’ve already tested this with multiple endpoints, and the behavior is the same everywhere. Some expected webhook events are still not being delivered, and there are no failures logged. Because of that, it doesn’t look like an issue on our side and it’s most likely something on the Atlassian side as you stated earlier.

[UX Software]

Hi @Davyd Melnychuk 

This pattern — deliveries silently dropped with no failure entries — is one of the toughest scenarios with native Jira webhooks, because the platform does not surface “the delivery never happened” anywhere visible to you. The “Get failed webhooks” endpoint only shows attempts Atlassian actually made and then gave up on after retries. Events the platform never tried to fire are invisible there.

One thing worth checking first: Atlassian has a separate developer platform status page, which tracks Forge, Webhooks, Product Events, and API health independently from the main Atlassian status page. Jira itself may look green while webhook delivery is degraded.

As of May 12, that developer status page shows Webhooks and APIs in a degraded state, with an active “Delay in Jira Webhook Delivery” investigation, mainly reported in EU-West. The pattern Atlassian describes — delayed and sparse delivery without explicit failures — matches what you are seeing. It is also worth comparing your incoming-events timeline with the developer status history around April 20.

Beyond that, I would check a few things:

1. Test with no JQL filter briefly. Even if the filter has not changed, custom field ID changes, archived projects, or permission scheme changes around April 20 could make the JQL evaluate differently and reduce the matched event volume.

2. Capture one known event end-to-end. Manually transition one issue and check whether the webhook fires. This separates “Atlassian did not fire the event” from “delivery failed somewhere later”.

3. Add a parallel delivery surface for comparison. Create an Automation for Jira rule with “Send web request” for the same event family. If Automation also delivers sparsely, the issue is likely upstream of webhook fanout. If Automation delivers normally and native webhooks do not, the issue is probably specific to the admin webhook delivery path.

4. Inspect the timing of the events you do receive. If they arrive in clusters or batches, it points to upstream throttling or delayed processing. If they are randomly thin, it may be delivery decisioning or filtering.

Disclosure: I work on Webhooks Pro for Jira Cloud, a Forge-based outbound webhook layer on the Atlassian Marketplace. We added per-delivery logs specifically because the native admin webhook surface does not expose the “was this delivery even attempted?” signal. Mentioning this for completeness — the diagnostic steps above apply regardless of the tool you use.