Skip to main content
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.

​
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: 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 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.
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 and 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.
  • 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 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

Messages not sending

The fixes behind a send_failed row.

Automation not triggering

Why a bot stayed silent, and what to change.

Known issues

Things that behave differently from how they look.

Channels

Reconnect or re-authorise the channel a row is complaining about.