Jira Cloud Org Events API

Question

Hi folks,

We are currently building a data pipeline to pull Jira org events into our environment via Airflow (DAG running on a 5-minute schedule).

While verifying the ingested records, we observed data discrepancy caused by late-arriving events:

* Current Implementation: For a run at 24/09/2026 05:50 PM, the DAG queries the window 05:45 PM – 05:50 PM.
* Issue: Re-triggering the API request for that exact same time window (05:45 PM – 05:50 PM) several hours later (or the following day) yields more records than the initial run captured.

We checked the official documentation but couldn't find details regarding event indexing latency or data consistency SLAs for this endpoint. Could anyone please clarify:

* Data Consistency SLA: When is a given event time window guaranteed to be complete and static?
* API Indexing Lag: Is there a standard propagation delay between when an event occurs and when it becomes queryable via the API?
* Recommended Buffer: What time offset/lag should we apply to our DAG execution window to ensure 100% event capture?

Thanks!

Sami Shaik · Answer

@Maksim Luchinkin ,

@Christos Markoulatos -Relational- is right that no latency figure is published for the organisation events API, and the audit log docs only say activities "may take a few minutes" to appear. So the design question is how to build a pipeline that is correct without that number, and the pattern is standard for any eventually consistent event source:

* Query with an overlapping lookback, not a strict window. Every 5-minute run asks for from = now - 60 minutes (or longer), to = now, and follows the cursor to the end. The 60 is a guess you tune, not a promise from Atlassian; late arrivals inside the lookback are caught on a later run without any special handling.
* Make the write idempotent. Upsert on the event id. Then the overlap costs nothing: an event seen three times is stored once, and you never have to know exactly when a window became final.
* Keep the watermark on event time, not run time. Persist the maximum event time you have fully processed, and treat the lookback as max(watermark - 60 min, ...) so a slow or failed DAG run does not skip anything.
* Reconcile daily. One run per day re-reads the previous 24 to 48 hours and counts against what you stored. The day the counts stop drifting tells you the real settling time on your org, which is the number you asked Support for, measured rather than promised. On 24 September you already have one data point: the re-run hours later found more events, so the lag on that day was at least several minutes and at most a few hours; the daily reconcile narrows it.
* If you are on a plan that exposes the events stream endpoint, prefer it: a cursor over an ordered stream avoids the time-window problem entirely, and you resume from the last cursor instead of re-deriving windows.

Do open the Support ticket as Christos suggests, and bring the reconcile numbers with you; a request that says "we observe a 40-minute settling time, is that expected" gets a more precise answer than one that asks for an SLA.

Christos Markoulatos -Relational- · Answer

Hi @Maksim Luchinkin,

The docs don't give you an answer to this. The Events API page has no latency or consistency SLA, and the audit log docs only say "It may take a few minutes for new activities to appear in the audit log."

I'd open a ticket with Atlassian Support at https://support.atlassian.com/contact/ in your case and ask them directly. Include what you posted here:

* the endpoint you're calling (/events or /events-stream)
* the example window (24/09/2026 05:45 PM to 05:50 PM) and the record counts from the first run and the re-run
* your three questions: when a window is final, the expected lag, and the buffer they recommend

They're the only ones who can confirm how the pipeline behind the API works.

https://support.atlassian.com/security-and-access-policies/docs/view-audit-log-activities/