Logs - Centralized error tracking and runtime diagnostics for WordPress.

Documentation

Logs

The Logs module captures and organizes WordPress runtime events inside wp-admin — giving you a centralized operational view without relying on server-side debug.log files.

Enabled by default
Local storage — stored in a dedicated database table
Read-only — does not change site configuration

Overview

Logs is enabled by default. It provides an operational view of what happened recently on your site — helping you detect issues early, prioritize fixes, and communicate clearly with your team or clients.

Logs dashboard overview: a single place to filter by severity, scan patterns, and review recent events.

Optional: AI insights

Enable AI in All DashAI → Settings → AI to get explanations and suggested fixes for log entries.

Tip: Use AI to transform raw logs into client-friendly explanations and clear next steps.

What Logs captures

  • PHP runtime events — errors, warnings, notices, deprecated calls, and other operational signals when available.
  • Database errors (wpdb) — last error and query details when exposed by WordPress.

The goal is to store actionable operational signals with enough context to speed up diagnosis and resolution.

How it works

  • Logs captures runtime events during WordPress requests and stores them in a dedicated database table.
  • Fatal errors can also be captured during shutdown to avoid missing critical failures.
  • Storage: table {prefix}_dashaiwp_logs (example: wp_dashaiwp_logs).
  • Read-only: Logs does not modify site configuration.
  • Retention: older entries are trimmed automatically.
  • Safe by default: Logs is safe to keep enabled and does not impact site behavior.

Storage & retention details

  • Where it’s stored: entries are written to a dedicated database table ({prefix}_dashaiwp_logs), not to filesystem log files.
  • What’s stored per entry: a message, severity, timestamp, and (when available) the PHP file path + line number extracted from the event.
  • Why it’s safe: Logs does not change WordPress configuration. It only stores operational signals for review inside wp-admin.
  • Automatic trimming: older entries are periodically removed to keep storage bounded.
  • Retention policy: the system keeps a rolling window (for example: a maximum table size and a maximum age in days) so the table doesn’t grow indefinitely.

Note: Some events may not include file/line details (this depends on what the runtime exposes), but the message content usually still identifies the responsible plugin/theme/component.

Severities

Error
Breaks functionality or impacts users (high priority).
Warning
Signals potential issues that can grow into breakage.
Notice
Informational, but may indicate bugs or bad assumptions.
Deprecated
Compatibility warnings (especially important before PHP upgrades).
Debug / Info
Operational signals when available.

Best practices

  • Review Logs weekly on plugin-heavy sites.
  • Reduce deprecated warnings before upgrading PHP.

Troubleshooting

  • No logs are showing — This can be normal on stable sites. Trigger a test warning to confirm capture, and check whether your environment suppresses runtime errors.
  • Logs appear without file or line information — Some events do not expose file and line details. Messages often still identify the responsible component.
  • Spike in deprecated warnings — Prioritize plugins or themes generating the most entries. Update or replace problematic components.