Hi,
I am observing a strange behavior with Auth0 Event Streams and I need to understand the internal mechanism:
-
Backlog Storm: Whenever I enable my Webhook, it immediately starts sending a large volume of events for various users. These seem to be old events that occurred while the stream was disabled. Is there an internal buffer that flushes upon enablement?
-
Delayed Real-time Events: When I perform a “User Update” on my test user immediately after enabling the stream, the event does not appear. I have to wait for a long time (maybe 1-2 hours) for the “old” events to finish processing before I start seeing my test user’s real-time events.
-
Missing Events: If I perform a User Update within the first 1-2 minutes of enablement, these specific events do not appear to be delivered at all.
My questions:
-
Does Auth0 Event Streams buffer events while a stream is disabled or failing? If yes, for how long?
-
Is there a way to “clear” the backlog before enabling a stream so I can focus on real-time testing?
-
Why is there a significant delay before new events are processed after a period of inactivity?
Many thanks
Hi @tu.nguyent
Welcome to the Auth0 community!
Auth0 utilizes an internal buffer and cursor system for Event Streams, which is responsible for the backlog storm and the subsequent delay in real-time events. However, Auth0 does not buffer new events while a stream is paused or disabled; it only buffers events that previously failed to deliver prior to the pause. To clear this backlog and immediately focus on real-time testing, you cannot simply flush the queue—you must delete the existing Event Stream and create a brand new one .
Because Auth0 does not expose a “Purge Queue” or “Skip to Present” button for Event Streams, the only way to bypass the backlog is to abandon the old cursor entirely.
To reset your testing environment:
- Delete the currently disabled Event Stream in the Auth0 Dashboard.
- Create a brand new Custom Webhook Event Stream pointing to your URL.
Creating a new stream generates a fresh internal cursor starting at the exact moment of creation. The old retry backlog is permanently bypassed and discarded, and any User Update actions you perform immediately afterward will be delivered in near real-time without the backlog storm.
If you have any other questions, let me know!
Kind Regards,
Nik