> For the complete documentation index, see [llms.txt](https://docs.digibee.com/documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.digibee.com/documentation/troubleshooting/deployment-issues/interpret-event-publishing-and-delivery-alerts.md). # How to interpret event publishing and delivery alerts Learn how to interpret the logs and alerts related to event publishing and delivery on the Digibee Integration Platform, and what to do about each one. ## **Overview** Pipelines that use Event Publisher and Event Trigger communicate through the platform's messaging layer. To help you identify configuration issues before they affect production, the platform surfaces two types of signals: * **Runtime logs**, recorded when a pipeline publishes an event during execution. * **Deploy-time alerts**, shown when you deploy a pipeline, before the event is ever published. None of these signals indicate a delivery failure by themselves. They're diagnostic: use them to confirm that a Publisher and its corresponding Subscriber are correctly matched and deployed. ## **Log entry** ### **Event published without a subscriber** When a pipeline publishes an event and no pipeline is subscribed to consume it, the platform records a log entry indicating that the event was published without a subscriber. ``` Event pipeline-name was published but reached no consumer. ``` This log doesn't indicate a failure: the event is published normally. It's meant to help you identify cases where a subscription is missing or where the Subscriber pipeline hasn't been published yet. #### **What to check** * Confirm that a pipeline with Event Trigger is configured to consume the event, and that the **Event Name** property matches the event name set in Event Publisher exactly. * Confirm that the Subscriber pipeline is published and running. * Redeploy the Publisher pipeline if the Subscriber pipeline was recently redeployed. ## **Deploy-time alerts** When you deploy a pipeline with Event Publisher or Event Trigger, the platform may display one of the following alerts. None of them block the deployment and you can still deploy after reviewing the warning. ### **"This event currently has no active deployed consumers"** This alert appears when the **Event** parameter uses a static (fixed) event name and no pipeline with a matching Event Trigger is currently deployed and active for that event. #### **What to check** * Confirm that a pipeline with Event Trigger exists for this event, and that its **Event Name** property matches exactly. * Confirm that the Subscriber pipeline is deployed and active, not just saved as a draft. ### **"The event name could not be determined at deploy time and was not verified"** This alert appears when the **Event** parameter uses a Double Braces expression instead of a static name, for example: ``` Event Publisher -> {{ DEFAULT(message.eventName, "new-event") }} ``` Because the event name depends on runtime data, the platform can't verify at deployment time whether an active Subscriber exists for it. This is expected for dynamic event names and doesn't necessarily indicate a missing Subscriber. #### **What to check** * Because dynamic event names can't be verified at deploy time, the platform also can't confirm whether any consumer of this event is still on the legacy event flow. As a precaution, redeploy any pipeline you know consumes this event to make sure it's on the new event flow. ### **"There are consumers of this event still running on the legacy event flow"** This alert appears when one or more pipelines still consume this event on the legacy event flow. The alert lists each affected event and Subscriber pipeline, for example: ``` orders -> order-notifier-v1.0 orders -> order-audit-v2.3 ``` A single event can have multiple consumer pipelines listed if more than one of them is still on the legacy event flow. #### **What to check** * Identify the Subscriber pipeline (or pipelines) shown in the alert and redeploy them so they receive this event on the new event flow. {% hint style="info" %} If the two sides are temporarily misaligned, event delivery keeps working, but the timeout and redelivery (Allow Redelivery Of Messages) settings may not apply until both pipelines are redeployed. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.digibee.com/documentation/troubleshooting/deployment-issues/interpret-event-publishing-and-delivery-alerts.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.