> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://fyno.io/docs/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://fyno.io/docs/_mcp/server. # Debugging Notification Failures with Sent Log Details > Deep dive into Fyno log components like Trace, Summary, and Placeholders. Understand the platform-wide notification delivery lifecycles across email, SMS, and messaging apps. **Log Details** is the pop-up that opens when you click a notification log on the **Sent Logs** page. It brings together everything about that log, organized into these areas: | Area | What it shows | | -------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | [Trace](#debugging-notification-hops-with-log-trace) | Each hop the notification took, the time each hop took, and the final status. | | [Summary tab](#reviewing-notification-trace-and-summary-logs) | Key details of the log, such as the Message ID, channel, provider, and template. | | [Placeholders tab](#debugging-template-placeholders-in-logs) | The placeholders, or replaceable parameters, in the template that was used. | | [Content tab](#understanding-log-content-details) | The content sent in the notification, such as the message text or the email subject and body. | | [Response tab](#analyzing-provider-api-responses-in-logs) | The exact response received from the provider, including any error code. | | [Delivery tab](#tracking-notification-delivery-status-in-logs) | The delivery report received from the provider, for providers that share delivery status. | | [Notification Route](#notification-route) | The full path the notification took across channels and providers. | ### Debugging Notification Hops with Log Trace The **Trace** appears on the left side of the Log Details pop-up. It summarizes each hop the notification took, how long each hop took, the total time, and the final status of the notification. ![](/docs/_fern-img/40afd39041f9869e609023b447495bd43dffe6f196cf7322719b844d4e897423.webp) | Hop | What it shows | | ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Request Received** | The time the API was triggered and Fyno received the request for processing. | | **Sent To** *provider name* | The date and time the request was sent to the provider, and how long Fyno took to process it. The provider shown depends on the routing and notification event that were triggered. If integration-level throttling delayed the notification, this hop also shows **Throttling Enabled**. Click **View Details** next to it to see each delayed attempt. | | *Provider name*'s **Response** | The date and time the provider's response was received, and how long the provider took to respond. | | **Final Status** | The final status of the notification, such as **Success**, and the total time taken for its entire lifecycle. | | **Delivery Status** | The time the provider shared the delivery status. This hop appears only when the provider sends a delivery response. | In the example above, the notification was sent through the Simulator, so the Trace shows **Sent to Simulator** and **Simulator's Response**. The **Sent to Simulator** hop shows **Throttling Enabled**, which means Fyno held the notification before submitting it to the provider. The notification was then sent, and the **Delivery Status** hop shows when the delivery status was received. Clicking **View Details** next to **Throttling Enabled** opens the **Throttling details** panel, which lists each delayed attempt with its date and time and the total number of attempts. > **Tip** > > Click **View Response** on the **Final Status** hop to go straight to the tab with the details of the final response. ### Reviewing Notification Trace and Summary Logs When you open Log Details, the **Summary** tab is shown first, next to the **Trace**. It lists the key details of the log. ![](/docs/_fern-img/60c34ca754d8b4d020a1b60921fbbc96485247fad1b6126effbf3ed6d1d6530d.webp) | Field | What it shows | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Message ID** | The unique identifier of the message sent through a specific provider. If a notification fails with one provider and is sent through a failover provider, each attempt gets its own log and Message ID. | | **Request ID** | The unique identifier of the request triggered through Fyno. Every log created by the same request shares one Request ID, even when the notification goes through multiple providers. | | **Channel** | The channel used for the notification: Messaging (SMS), WhatsApp, Email, Chat, or Push. | | **Provider Name** | The provider used to send the notification you're viewing. This can vary with your routing and notification event configuration. | | **Destination** | The recipient's details, such as a phone number, email ID, or chat channel ID. | | **Date** | The date you triggered the notification through the Fyno App. | | **Time** | The time you triggered the notification through the Fyno App. | | **Integration Custom** | The name you gave the integration when you created a provider under a channel. | | **Routing** | The routing you created under the **Integrations** section. | | **Template** | The name of the template used in the notification, created under the **Templates** section. | | **Notification Event** | The name of the notification event that triggered the notification and created this log, created under the **Notification Events** section. | | **Retry** | The attempt number of the notification within the notification event, starting at 0. | For example, if a notification event has 2 providers configured, and the notification fails with the first provider but is delivered by the second, there are 2 logs. The failed attempt shows **Retry** as 0, and the delivered attempt shows **Retry** as 1. To see both attempts together, open the [Notification Route](#notification-route). > **Request ID and Message ID are linked!** > > A Message ID starts with the Request ID of the request that created it. Its last 4 characters are unique to each provider. > **Tip** > > To see every log created by one request, such as when the routing or notification event uses multiple providers, search for its **Request ID** in **Filters**. ### Debugging Template Placeholders in Logs The **Placeholders** tab shows the details of all the placeholders, or replaceable parameters, in the template used to trigger the notification event. > **No details in Placeholders?** > > If the **Placeholders** tab is empty, the notification's content had no replaceable parameters to display. > **Note** > > If a placeholder or base64 attachment is larger than 1 MB, you'll see `content omitted due to size`, because Fyno doesn't store content larger than 1 MB. ### Understanding Log Content Details The **Content** tab shows the details of the content sent in the notification. What you see depends on the channel: | Detail | What it shows | | ------------------- | ----------------------------------------------------------------------------------------------------- | | **Message content** | The static text of the message, along with any replaced parameters. | | **Type of Message** | The message type, such as Unicode, plain text, or a media type, depending on the content and channel. | | **Template ID** | The Template ID, for SMS notifications that have one. | | **Subject** | The subject line, for email notifications. | | **Body** | The content of the email body, for email notifications. | > **Note** > > If a placeholder or base64 attachment is larger than 1 MB, you'll see `content omitted due to size`, because Fyno doesn't store content larger than 1 MB. ### Analyzing Provider API Responses in Logs The **Response** tab shows the exact response Fyno received from the provider for the notification. This includes any error code, the final status of the notification, and the message content and trace details. ### Tracking Notification Delivery Status in Logs The **Delivery** tab shows the delivery response Fyno received from the provider used to send the notification. Because this information comes from the provider, the tab is available only for providers that send delivery status. > **Info** > > If Fyno hasn't received any delivery status from the provider, the **Delivery** tab isn't shown. Providers fall into three groups, depending on whether and how they share delivery status. #### Delivery Status Sent, No Extra Configuration These providers share the delivery status without any webhooks or callbacks configured on their end. | Channel | Providers | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Messaging (SMS) | [Exotel](./sms-exotel), [Kaleyra Global](./sms-kaleyra-global), [Kaleyra.io](./sms-kaleyraio), [MessageBird](./sms-messagebird), [Plivo](./sms-plivo), [Twilio](./sms-twilio), [ValueFirst](./sms-valuefirst) | | WhatsApp | [Freshchat](./whatsapp-freshchat), [MessageBird](./whatsapp-messagebird), [Twilio](./whatsapp-twilio), [ValueFirst](./whatsapp-valuefirst) | | InApp | InApp | | Push | [Expo](./push-expo), [FCM](./push-fcm), [Mi Push](./push-mi-push), [OneSignal](./push-onesignal) | #### Delivery Status can be Sent, Configuration Needed These providers share the delivery status once they're configured to do so. After that, the **Delivery** tab shows up in logs. | Channel | Providers | | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Messaging (SMS) | [Gupshup](./sms-gupshup), [Karix](./sms-karix), [MSG91](./sms-msg91), [RouteMobile](./sms-route-mobile), [Syniverse](./sms-syniverse) | | WhatsApp | [Connectly](./whatsapp-connectly), [Kaleyra.io](./whatsapp-kaleyraio), [Gupshup Enterprise](./whatsapp-gupshup), [Meta (by Facebook)](./whatsapp-meta) | | Email | [Mailchimp (Mandrill)](./email-mailchimp), [Mailgun](./email-mailgun), [Netcore](./email-netcore), [PostMark](./email-postmark), [SendGrid](./email-sendgrid), [SES](./email-ses) | #### Delivery Status Not Sent, Configuration not available These providers can't share the delivery status, so the **Delivery** tab isn't shown for them. | Channel | Providers | | -------- | ----------------------------------------------------------- | | WhatsApp | [AiSensy](./whatsapp-aisensy) | | Email | [Gmail](./email-gmail), [Outlook](./email-outlook) | | Chat | [Slack](./chat-slack), [Teams (by Microsoft)](./chat-teams) | > **Note** > > A few other providers don't share delivery status either, so Fyno can't fetch it for them. Check with your provider for details. ### Notification Route To see the full path a notification took across channels and providers, click the route icon (the branching arrow) to the right of the tabs in the Log Details pop-up. This opens the **Notification Route**, which displays the path as a flow of blocks that begins at **Start**. Each block represents one attempt to send the notification through a channel and integration. ![](/docs/_fern-img/3f46c1aa5f1ea5f4297b5c8d046618b2f222986b76df34504b7f1925dc730867.webp) For example, if a notification is sent on WhatsApp but isn't delivered, and your route then sends it by email, the Notification Route shows two blocks: a WhatsApp block marked **Undelivered**, connected to an email block marked **Delivered**. You can open each block to see what happened during that attempt. #### Reading Blocks and Connectors Each block shows its channel, the integration used, and the status of that attempt, such as **Delivered** or **Undelivered**. Blocks are joined by connectors, and each connector's label shows why the notification moved on to the next block. | Connector label | What it means | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **on success** | The attempt in the previous block met the success criteria set in your route. | | **on failure** | The attempt in the previous block failed or didn't meet the success criteria set in your route. | | **wait for** | The wait time configured in your route, such as how long Fyno waits for a delivered or read status before following the success or failure path. It can appear alongside an **on success** or **on failure** label. | To learn how success criteria and wait times are set up, see [Omnichannel Routing](./omnichannel-route-creation). #### Clicking on a Block to See Log Details Click a block in the route to view details of that log. The block you're viewing is highlighted, and its channel and integration appear at the top of the **Trace**. The **Trace** and the tabs, such as **Response** and **Delivery**, then show the details for that attempt. > **Tip** > > To find out why an attempt failed, click its block and open the **Response** tab. It shows the provider's response for that attempt, including the error code if there is one.