Every event stream gives you two places to check on its health: the Logs tab, where you can browse the messages that have passed through it and see who is consuming them, and the Usage tab, where you can see which automations depend on it. Together they help you confirm that publishing worked, that consumers are keeping up, and that nothing downstream will break if you change the stream.
Overview
Open any event stream and go to its Logs tab to see a running history of messages, the number of active subscribers, and — for streams with a dead letter queue enabled — which messages failed and whether they've been recovered. The Usage tab, next to Logs, lists every automation that publishes to or subscribes from the stream, so you always know what depends on it before you make a change.
Browsing stream messages
The Logs tab opens with two headline numbers: Total Count, the number of messages currently in the stream, and Total Subscribers, the number of consumers currently subscribed. Below them is a table of recent messages with a column for the message key, one column for each field in the stream's schema, and a Published Time column. Click any row to inspect the full payload of that message. As you scroll, more messages load automatically, so you don't need to page through results manually.
If the table instead shows "No logs found," nothing has been published to the stream yet, or everything that was published has already aged out under the stream's retention setting. Trigger the automation that publishes to the stream and refresh the page — messages should appear shortly after.
Subscribers and consumer lag
Click Total Subscribers to open a drawer listing every consumer subscribed to the stream. For each one you'll see its partition, how many messages it has consumed, and its lag — how far behind the newest published message it currently is. A lag that stays low or trends toward zero means the consumer is keeping pace; a lag that keeps climbing means it's falling behind and worth investigating. If the drawer shows "No subscribers found," no automation is currently consuming from this stream.
DLQ message statuses
If a stream has its dead letter queue enabled, any event that fails during processing is routed to a companion stream named after the original stream with "(DLQ)" appended. Open that companion stream's Logs tab and you'll see an extra Status column: messages start out Pending, meaning they failed and haven't been retried yet, and switch to Republished once you've sent them back through.
Republishing failed events
On a DLQ stream, if you have publish permission, you can retry failed messages individually or in bulk:
One message at a time: open the row menu and choose Republish Event. This opens a Publish Event panel where you can edit the event data — using either a form or raw JSON — before sending it back through the original stream.
Multiple messages at once: select the rows you want to retry and click Republish. The selection count updates as you check rows so you can confirm exactly how many you're about to resend.
A successful retry shows a confirmation that the event was re-published; a failed one shows the reason so you can fix and try again. Messages that have already been republished are protected from being sent twice — trying again returns a message telling you it was already republished.
Dependent automations
Before changing or removing a stream, check the Usage tab to see what relies on it. It lists every dependent automation with its name, its trigger, the apps it uses, and whether it publishes to or subscribes from this particular stream. Click any row to open that automation directly. Two additional columns — when the dependency was created, and who last updated it — are hidden by default; open the columns menu to show them, and your choice will be remembered the next time you visit. If nothing appears here, no automation currently uses the stream.
Notes
Messages are removed from the Logs view once they age out under the stream's retention period, even though they may have already been processed successfully.
Rising consumer lag is the earliest sign that an automation subscribed to the stream is struggling to keep up — check it before assuming a downstream automation has simply stopped.
Republishing sends the event through the original stream again, so any automation subscribed to that stream will process it exactly as if it had just been published.
You need publish permission on a stream to republish DLQ events from it.