Message logs

Courier records the delivery lifecycle of every message you send. Logs answer “what happened to this one send”. answer “how is this template performing”. Both read the same status data.

​

How it works

Each entry in the shows status, notification, recipient, and the provider channels the message went through. Open a message to see its timeline: each status change, the provider response, and any error. Filter the list by status, provider, or error to find a specific class of failure.

​

Finding one message

Each message has a message id (requestId), the same value the and return. Use it to match a log entry to an API response or a webhook event.

​

Reading a status

A message’s status only ever advances. Two independent systems drive it. Provider confirmation produces DELIVERED. Courier tracking produces OPENED and CLICKED, so engagement can appear before, or without, a delivery confirmation. For the full status table and the send-time reasons a message never reaches a provider, see .

​

Limits & behavior

• A message stuck at SENT is usually not lost. Courier handed it to the provider but has no delivery confirmation. Usually delivery tracking is not configured for that channel.
• DELIVERED depends on the provider. Not every provider confirms delivery, so a missing DELIVERED is not proof of failure. Treat OPENED and CLICKED as receipt signals.
• Logs are per message, not per recipient group. A broadcast to a list produces one log entry per recipient. Use for the roll-up.
• Retention depends on your plan. Developer and Business keep 30 days of message history. Enterprise keeps 365 days. Searches and reads are clipped to that window, so export anything you need to keep longer. A message’s own event history is capped at roughly 93 days on every plan, so an older message still lists but returns no timeline.

​

FAQ