> ## 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 page to find out why a message, bot or integration didn't do what you expected.
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 is
a read-only record: you can search it and filter it, but you can't edit, delete or export it.
Open it from the sidebar: **Configurations → Logs**, the last item in the group. Unlike most of
the messaging sections, Logs opens even with no channel connected — though there is little to
see until one is.
**Logs only shows you the channel you currently have selected.** Once you have any channel
connected, the list, the search and the three counters at the top are all 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, switch the selected channel and come back.
This matters more than it sounds, because some entries aren't attached to a channel at all —
and those are invisible in every view. See [the blind spots](#the-blind-spots).
## 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 ever recorded* for
this channel, not the last day. Since DMLY never deletes log entries, those two numbers only ever
climb. 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**.
* **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.
Three of the **Event** options — **Broadcasts**, **Delivery** and **System** — 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.
**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. Don't spend time on
those filters.
## 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** | `Outbound WhatsApp reply to …` with the contact's number or name |
| **An automation step never sent its message** | **Errors** + **Error** | `send_failed` — open it for the reason from WhatsApp or Meta and which step it was |
| **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 any channel but **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 |
`send_failed` is the single most useful row on this page. It is written when a send fails
permanently — an expired token, a missing permission, a number that can't be messaged — and it
carries the raw reason from Meta. It is 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
Some things DMLY records aren't tied to a channel, and because the list is always narrowed to
your selected channel, **you will never see them here.** If you are chasing one of these, Logs
cannot help and you'll need support to look:
* **Webhook deliveries to your own systems** — both the successes and the failures, recorded per
attempt. See [webhooks](/api-reference/webhooks).
* **Manual webhook tests**, including who on your team fired them.
* **Store syncs.**
* **Inbound messages that crashed while being processed** — as opposed to being cleanly dropped,
which *is* visible.
A few more limits worth knowing:
* **Incoming Live Chat messages are never logged.** Every other channel writes a **Success** row
for each message received; **Live Chat** writes nothing. Silence under **Messages** + **Success**
on a Live Chat widget tells you nothing about whether messages are arriving — check the
[Inbox](/inbox/overview) instead. Replies you send to a Live Chat contact *are* logged as normal.
* **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 kept forever.** Nothing in DMLY prunes, archives or expires them, and there is
no delete button and no export. Everything ever recorded for your workspace is still there, which
is why **Warnings** and **Errors** are lifetime counts and why **Date range** is doing the real
work whenever you use this page.
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.
Things that behave differently from how they look.
Reconnect or re-authorise the channel a row is complaining about.