Event Queue

Every real captured event — and every Message Preview test payload — is delivered asynchronously through a queue, not synchronously within the transaction that triggered it. Open it from Setup's Event Queue action.

Each entry shows:

• Table Name / Event Type — which table and which of insert/modify/rename/delete produced it.
• Status — Pending (waiting to be sent, or waiting out a retry delay), Processing (currently being sent), Sent (delivered — pruned by the recurring sweep about 15 minutes later, so the list stays focused on what's still in flight or has failed; see How delivery works), or Error (gave up — see Reading the error messages below).
• Modified At — when the underlying record actually changed.
• Processing Started At — when this entry was last claimed for sending.
• Retry Count / Retry After — how many retriable failures this entry has had, and the earliest time it'll be attempted again.
• Error Message — why the last attempt failed, once one has. Just plain text — unlike a Send Test Payload failure, it's never a clickable link to Setup or Extension Management.

For RabbitMQ specifically, Sent only means the message was successfully handed to the RabbitMQ Management API — not that it reached a queue. RabbitMQ's own response reports whether the message was actually routed (i.e., whether the exchange had a matching queue binding for it at that moment), but Event Bridge treats a successful hand-off as delivery either way — an unrouted message still shows Sent, not Error, since routing is a broker configuration concern, not something Event Bridge failed to do. If a table and endpoint are configured correctly but nothing arrives on the RabbitMQ side, check the exchange's queue bindings and routing key before assuming Event Bridge isn't sending.

How delivery works

Business Central runs a background task per source table that drains its queue as soon as an event is enqueued, so there's no user-facing wait and nothing to configure per table. A failure that looks transient (a network error, or an HTTP 5xx, 408, or 429 response) is retried automatically, honoring the endpoint's Retry-After header if it sends one, or after a 1-minute default delay otherwise — up to Max Retry Attempts before the entry is marked Error. Any other failure (e.g. a 4xx other than 408/429, a bad credential, a missing Setup value) is marked Error immediately without retrying, since retrying wouldn't fix it.

As a safety net on top of that per-table task, run Schedule Automatic Retries on Setup once — it creates a recurring job queue entry (every 5 minutes) that resets any entry stuck in Processing for more than 15 minutes (e.g. after a session was interrupted mid-send), picks up any table whose background task was lost, and deletes Sent entries once they're about 15 minutes old so the queue doesn't grow forever. Without it scheduled, none of that cleanup runs on its own — entries still send, but stuck/lost recovery and pruning of completed entries only happen when this job fires.

Actions

• Retry Failed Entries — resets every Error entry back to Pending (and its retry count to 0) so it's attempted again. Use this once you've actually fixed the problem — retrying without fixing the cause just fails the same way again.
• Flush Failed Entries — permanently deletes every Error entry without resending them. Use this to clear out failures you've decided not to chase.
• Reset Stuck Tasks — cancels the tracked background task for every source table and schedules a fresh one for any table with pending entries. Use this if entries stay Pending without ever moving to Processing or Sent.
• Clear Queue — permanently deletes every entry regardless of status and cancels all tracked background tasks. Events already captured are lost and can't be resent — this only affects what's currently queued, not future events.

Who can use this

The Event Queue needs the same Event Bridge Admin access required for Setup and Event Tables — see Licensing and access.