Reading the Logs page

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 five, alongside Team, Appointments, Finance and CSAT. Unlike most of the messaging sections, Logs opens even with no channel connected, though there is little to see until one is.

​

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 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: 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.

​

Exporting

Every applied filter, including the date range and search keyword, carries into the export.

​

Symptom → what to look for

This is the fastest way to use the page. Find your symptom, apply the filter, read the row.

​

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), 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. One kind of event is still genuinely invisible: an inbound message that crashes while being processed, as opposed to one that’s cleanly rejected (which is visible, as a dropped Error). A crash like that writes nothing to Logs at all: not a missing filter, an actual gap. If you suspect this is happening, that’s a support conversation, not something to chase here. 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 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) 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