Yes. SleekView queries wp_simple_history for the event header and joins context keys from wp_simple_history_contexts. The plugin keeps writing events through its own pipeline; SleekView only reads from the tables and renders the grid, so the audit chain remains intact.

Yes. Any context key written by a logger can be promoted to a column and then used as a filter, a sort field, or a group. That includes the keys built-in loggers write — post_type, option_name, plugin_slug — and any keys custom loggers add.

Custom loggers are picked up automatically because SleekView reads the same tables Simple History writes to. Their context keys appear under the contexts join the moment they record an event, so no SleekView reconfiguration is needed when a developer adds a new logger.

Yes. Filtered rows export as CSV with only the columns currently on screen. Exports respect the active filter, the sort, and the pagination range, so the file matches what the reviewer just signed off on.

SleekView paginates server-side and uses the indexes Simple History maintains on date and logger. Even sites with years of history stay fast because the grid requests one page at a time with the active filter; the whole table is never loaded into memory.

Yes. Capability checks follow Simple History's own settings, so only users with permission to see the log can open the SleekView grid. Saved views can carry a tighter capability requirement when the underlying data is sensitive.

SleekView is read-first, so destructive actions like clearing the log are still handled by Simple History's own settings. The honest workflow is to use SleekView for investigation and exports, and let Simple History's purge schedule handle retention.

Query Monitor and a custom query work for one-off questions, but neither produces saved, shareable audit views with annotations. SleekView is built for repeatable investigation: define the columns once, save the view, and the next person on rotation opens the same grid without rebuilding the query.