> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dmly.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Reading the Logs page
> Use the Logs tab on Reports to find out why a message, bot or integration didn't do what you expected, or to see business activity across your workspace.
When something didn't happen (the bot stayed silent, a message never left, a contact never
reached your CRM), **Logs** is where DMLY writes down what it tried and what went wrong. It also
carries workspace activity that isn't about messaging at all: an invoice sent, a payment that
failed, a new appointment, a new Google review. It is a read-only record: you can search it,
filter it, and export it as CSV or PDF, but you can't edit or delete an entry.
Open it from the sidebar: **Configurations → Reports**, then select the **Logs** tab, the last of
six, alongside **Team**, **Appointments**, **Finance**, **Ads** and **CSAT**. Reports opens on
**Team**, so Logs is one click along from there. Unlike most of the messaging sections, Logs
opens even with no channel connected, though there is little to see until one is.
This is not the same thing as the workspace **audit log** under **Settings → Audit log**. The
audit log is a permanent, append-only record of *who changed what* for a set of high-value
account actions (deleting a contact, changing a role). **Logs** here is a shorter-lived
activity feed of what the system tried to do: sends, bot runs, integrations, and the business
events above. See [Read the workspace audit log](/account/audit-log) if that's what you're
after.
**Logs still narrows the messaging entries to the channel you currently have selected.** Once
you have any channel connected, the channel-scoped rows (inbound and outbound messages, bot
activity) are silently narrowed to the active one, and there is no control on the page to
widen it back out to the whole workspace. To check another channel's messages, switch the
selected channel and come back.
Business activity, webhook deliveries, manual webhook tests, store syncs and **System** entries
aren't tied to any one channel, so they show up regardless of which channel you have
selected. That is true of the list on screen only; an export drops them, so read
[Exporting](#exporting) before you rely on a file. See
[the blind spots](#the-blind-spots) for the one kind of event that genuinely never appears.
## What the page gives you
**Three counters across the top.** **All events (24h)**, **Warnings** and **Errors**: they are
buttons, not just numbers. Select **Warnings** or **Errors** to filter the list to that status,
and select it again to clear it. **All events (24h)** clears the status filter and gives you the
whole list back; the 24-hour bound applies to its number, not to what the list shows you.
Only that number is time-bounded. **Warnings** and **Errors** count everything currently kept
in this view (the selected channel plus workspace-wide business activity), not just the last
day; see [Retention](#retention) for how far back that goes. A big number there is not a signal
that something is wrong right now; the **Date range** filter is what tells you that.
**A table of five columns:** **Status**, **Event**, **Platform**, **Profile** and **When**. The
**Event** cell also carries a small chip naming the category the entry belongs to.
**Status is one of three things:**
| Status | Means |
| - | - |
| **Success** | It worked. An inbound message writes one, and so does a reply you send from the Inbox that went out. A message your bot sends writes nothing here unless it fails permanently: a send that will be retried doesn't appear at all. |
| **Warning** | It didn't happen, but on purpose or for a known reason. A bot start that was deliberately suppressed, a flow left waiting too long. |
| **Error** | It failed. This is the column you scan. |
**Select any row** to open its detail. You get the error in full at the top if there was one,
then the **Type**, **Platform**, **Profile** and **When**, then the complete technical details
the entry was recorded with. The details are raw: you're not expected to understand every field,
but they are what you paste to support.
## Filtering
Select **Filters** to open the filter row.
* **Search events**: a keyword search. It searches the **Event** text only, not the details
inside a row. Searching for an error message you saw in the detail panel won't find anything;
search for the thing the event is *about* instead.
* **Event**: the category, despite the name. **Messages**, **Broadcasts**, **Bots**,
**Automations**, **Webhooks**, **Integrations**, **Delivery**, **System**, **Errors**,
**Finance**, **Appointments** and **Reputation**.
* **Status**: **Success**, **Warning**, **Error**.
* **Platform** and **Date range**: **All time**, **Last 24 hours**, **Last 7 days**,
**Last 30 days**.
**Date range plus Status** is the combination that earns its keep: set **Errors** and **Last 24
hours** and you are looking at today's actual problems rather than a lifetime of them.
**Finance**, **Appointments** and **Reputation** are the business-activity categories: they
mirror the same events that ring the notification bell (an invoice sent, a payment received or
failed, a new appointment booked, a new Google review), so the same activity shows up in both
places. Muting a notification in your alert settings does not stop it being logged here; the two
are independent.
Two of the **Event** options (**Broadcasts** and **Delivery**) never return anything. Nothing
in DMLY writes entries in those categories, so choosing them always shows *No log entries
match your filters.* That is the filter, not a sign that broadcasts or delivery are broken.
For broadcast results, use [Broadcasts](/broadcasts/overview) itself.
**System** holds three kinds of entry. The first is a daily WhatsApp access-token warning. In
the week before a token lapses you get a **Warning** row reading
`WhatsApp connection "…" expires …`, and once it has lapsed an **Error** row reading
`WhatsApp connection "…" needs reconnecting`. Both name the connection and when its token
expires or expired, and both tell you to reconnect the number. One row per connection per day,
never a duplicate. See [Connect WhatsApp](/channels/whatsapp). The second is a contact-limit
**Warning**: `Contact added over the contact limit ()` when someone who messaged you is
let in over your plan's cap, or `Contact not added — contact limit reached ()` when a
store sync is refused. The third is a record of Shopify privacy (compliance) requests. An empty
**System** list is the healthy state.
**Platform** and **Profile** are near-constant in practice: the list is already narrowed to
your selected channel, so nearly every row will show the same two values. Business-activity
rows (Finance, Appointments, Reputation) carry no platform or profile at all, so they show a
dash in both columns. Don't spend time on those filters.
## Exporting
Every applied filter, including the date range and search keyword, carries into the export.
**The export is narrower than the list you're looking at.** The list shows the selected
channel's rows plus everything that isn't tied to a channel: business activity (**Finance**,
**Appointments**, **Reputation**), webhook deliveries, manual webhook tests, store syncs and
**System** entries. Both the CSV and the PDF keep only the selected channel's rows, so
those workspace-level entries are missing from the file even though you can see them on
screen. If you need them, read them in the list or copy them from a row's detail panel.
Every matching log row for the selected channel: **When**, **Status**, **Type**, **Event**,
**Platform**, **Profile**. Capped at the most recent 5,000 rows.
A formatted activity-log report for the selected channel: four counters (**Total events**,
**Last 24h**, **Warnings** and **Errors**), a breakdown by status and by category, and a
table of the matching rows. That table stops at the most recent 120 rows, far short of the
CSV's 5,000, and prints *Showing the most recent 120 events.* underneath when there were
more. The counters and the breakdowns cover every row in the PDF's own scope, so they stay
right when the table is cut short. They count only the selected channel's rows, so the PDF's
**Warnings** and **Errors** can come out lower than the same two counters at the top of the
page, which also count the workspace-level entries. Use the CSV when you need the rows
themselves.
One PDF of *some* of the other Reports tabs, sharing a single date window: CSAT, Team
performance and Appointments, plus a [Finance](/analytics/finance-report) section when your
role can view Finance, and an [Ads](/analytics/ads-report) section, on its own page, whenever
the workspace has ad-referred conversations in the 30 days the document covers. Those last
two are gated differently: Finance on your permissions, Ads on whether there is anything to
report. **Logs is never in it**, so use this tab's own CSV or PDF for the log itself. It also
ignores the filters set here and always covers the trailing 30 days. See
[Exporting reports](/analytics/exporting-reports).
Exporting needs the separate **Export reports** permission, on top of whatever lets you view
Reports in the first place. See [Roles and permissions](/account/roles-and-permissions).
## Symptom → what to look for
This is the fastest way to use the page. Find your symptom, apply the filter, read the row.
| What you saw | Filter to | What the entry looks like |
| - | - | - |
| **A reply you sent from the [Inbox](/inbox/overview) failed** | **Messages** + **Error** | `Failed WhatsApp send to …`, with the reason from WhatsApp or Meta appended after a dash |
| **An invoice, booking confirmation, AI reply, notification or broadcast message failed to send** | **Messages** + **Error** | `Failed send to …`: the same shape as above. Anything sent automatically (not typed by an agent) surfaces here, not just Inbox replies |
| **An automation step never sent its message** | **Messages** + **Error** | `send_failed`: open it for the reason from WhatsApp or Meta, the flow run's ID and the step's node ID (it does not name the automation) |
| **The bot didn't reply at all** | **Automations** + **Warning** | The start was suppressed on purpose; the row's details name the reason and the automation |
| **A flow started, then stopped halfway** | **Automations** + **Warning** | `Flow run expired — session idle`, followed by the automation and contact names: the flow waited for a reply that never came |
| **The channel is connected but nothing arrives** | **Messages** + **Error** | `Inbound WhatsApp webhook dropped`: the details carry the reason it was rejected |
| **Are inbound messages arriving at all?** | **Messages** + **Success** | `Inbound WhatsApp message from …`: one per message received, on every channel including **Live Chat**. No rows here at all means the problem is upstream of DMLY |
| **A contact never reached your CRM or mailing list** | **Integrations** | `Auto-synced to …` on success, `Auto-sync to … failed` on failure |
| **A flow's Google Sheets / HubSpot / Slack / SMS step did nothing** | **Integrations** | One entry per step run, with the provider's own error if it failed |
| **You want one feed of invoices, payments, appointments or reviews** | **Finance**, **Appointments** or **Reputation** | A plain-language line mirroring the notification bell: `Invoice sent`, `Payment received`, `New appointment booked`, `New Google review` and so on |
| **A WhatsApp channel is about to stop sending** | **System** | `WhatsApp connection "…" expires …`: reconnect the number before its access token lapses |
A row reading `send_failed` or starting with **Failed** is the single most useful kind of row
on this page. Both are written when a send fails permanently (an expired token, a missing
permission, a number that can't be messaged) and carry the raw reason from Meta or the
channel. That's what turns "the bot is broken" into a specific thing you can fix. See
[messages not sending](/troubleshooting/messages-not-sending) and
[automation not triggering](/troubleshooting/automation-not-triggering) for the fixes
themselves.
## The blind spots
Most of what used to be invisible here now shows up. **Webhook deliveries to your own systems**
(both successes and failures; see [webhooks](/api-reference/webhooks)), **manual webhook
tests** (including who on your team fired one), and **store syncs** aren't tied to a channel, so
they appear under **Webhooks** and **Integrations** regardless of which channel you have
selected; you don't need to hunt across channels to find them any more.
**An inbound message that crashes while being processed** is visible too. Once its retries run
out, it writes an **Error** row under the **Errors** category, such as `Inbound WhatsApp
processing failed`, with the error in its details. Set **Event** to **Errors** to find it. Only a
crash that succeeds on a retry leaves no row.
A few more limits worth knowing:
* **Incoming Live Chat messages are logged like any other channel's.** Each one writes a
**Success** row reading `Inbound Live Chat message from …`, so silence under **Messages** +
**Success** on a [Live Chat widget](/channels/livechat-widget) does mean nothing is arriving.
Open a row and its details carry the message text, or `[media]` and the file name when the
visitor sent an attachment, since that has no text of its own.
* **Sandbox and test sends are excluded** from failure logging by design, so a demo number
produces a quieter log than a live one.
* **If you reload a filtered page or open a filtered link, the filter boxes render empty even
though the list is still filtered.** The results are right; the controls just don't show what
they're set to. Select **Filters** and set them again if you need to be sure what you're
looking at. **Platform** is the exception: it always shows your selected channel's platform,
whether or not you set it.
## Retention
**Log entries are not kept forever, and the window is short: DMLY keeps the newest 300 entries
per workspace and trims everything older once a day.** That keeps the feed a recent-activity view
rather than an ever-growing table. There's no delete button (you can't remove one yourself), but
you also don't need to worry about the list growing without bound.
The trim is count-based, not date-based: a quiet workspace keeps its whole history, while a busy
one only keeps its most recent activity, however far back that reaches. Be clear-eyed about what
300 buys you: inbound messages, Inbox replies, failed sends, bot runs, invoices, appointments and
reviews all write rows into the same 300, so a busy workspace can produce that many inside a
single day. When the next daily trim runs, yesterday is gone.
So **Warnings** and **Errors** are not true lifetime counts (they're counts of what's currently
kept), and this is another reason **Date range** does the real work whenever you use this page.
If you need a permanent record of something here, export it (see [Exporting](#exporting)) the day
you see it, not next week.
The practical consequence: never judge health by the size of a number here. Judge it by what
turns up under **Last 24 hours**.
## Next
The fixes behind a `send_failed` row.
Why a bot stayed silent, and what to change.
Another Reports tab: response rate, average score and satisfaction.
Another Reports tab: assignments, replies and response times per teammate.
Every CSV and PDF export across Reports, in one place.
Things that behave differently from how they look.
Reconnect or re-authorise the channel a row is complaining about.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.
## Filtering
Select **Filters** to open the filter row.
* **Search events**: a keyword search. It searches the **Event** text only, not the details
inside a row. Searching for an error message you saw in the detail panel won't find anything;
search for the thing the event is *about* instead.
* **Event**: the category, despite the name. **Messages**, **Broadcasts**, **Bots**,
**Automations**, **Webhooks**, **Integrations**, **Delivery**, **System**, **Errors**,
**Finance**, **Appointments** and **Reputation**.
* **Status**: **Success**, **Warning**, **Error**.
* **Platform** and **Date range**: **All time**, **Last 24 hours**, **Last 7 days**,
**Last 30 days**.
**Date range plus Status** is the combination that earns its keep: set **Errors** and **Last 24
hours** and you are looking at today's actual problems rather than a lifetime of them.
**Finance**, **Appointments** and **Reputation** are the business-activity categories: they
mirror the same events that ring the notification bell (an invoice sent, a payment received or
failed, a new appointment booked, a new Google review), so the same activity shows up in both
places. Muting a notification in your alert settings does not stop it being logged here; the two
are independent.