SleekView reads stored log rows from the database, so the Query Monitor stored logs add-on or any compatible logger that writes to a logs table is required. The default in-memory panel data lives inside a single request and disappears at the end of it, which leaves nothing for the kanban to read.

Yes. Query Monitor lets you set a retention window on the stored logs table, and SleekView reads whatever is inside that window. A common pattern is to keep one week of logs, which is plenty for a triage board, and let older entries roll off automatically without touching the kanban configuration.

Archive is a status change, not a delete. The original log row stays in wp_qm_logs with its full backtrace and an added archived flag, so anyone with read access can still inspect it. Cron-driven retention can prune archived rows later on whatever schedule fits your audit policy.

Yes. SleekView views are configuration only, so you can build one board filtered to WooCommerce components and another to admin requests from the same logs table. Each developer picks a default board, and admins pin shared boards into the WordPress sidebar for the whole engineering team.

SleekView reads the severity column on every page load, so a new value shows up as its own lane at the end of the board. You can drag it into the right position, assign a color, and decide which fields the lane cards should surface, all without writing any code or restarting QM.

Each slow query card opens a side panel showing the full SQL text with placeholders bound, the duration, the calling component, and the backtrace exactly as Query Monitor captured it. Developers triage, archive, or snooze the entry without leaving the kanban for the original QM panel.

Yes. SleekView respects WordPress capabilities, so you can require an admin or custom capability before a card lands in the archived lane for the critical severity. Junior developers acknowledge warnings, but only senior staff close out a critical row with the corresponding audit trail entry.

SleekView reads and writes the existing wp_qm_logs table without adding shadow tables for log data. The triage status sits in a small extension column the kanban manages, and uninstalling SleekView leaves every log row, severity, and backtrace exactly where QM wrote it.