From WPGraphQL's own query log option (or the custom table on installs that route logs there), plus the GRAPHQL_DEBUG payload when the constant is on. No external APM, no proxy in front of the endpoint.

No. WPGraphQL ships its own query log. Turn it on in plugin settings (or set GRAPHQL_DEBUG to true on staging) and SleekView reads the resulting rows directly.

Yes. operation_name is a sortable column with a text filter, so the table can scope to one operation at a time or to a name prefix shared across a client's queries.

WPGraphQL's logger is optimised for one write per request. SleekView only reads the resulting rows from the admin side, so the table itself adds nothing to the request path. Teams that don't want production logging typically run the audit on staging or a sampled prod log.

Yes. Persisted queries still write a row with the resolved operation name, so they appear alongside ad hoc operations and the pie of operation names shows how much traffic is genuinely persisted.

Log rows are read-only by design, since editing a logged operation in place would corrupt the audit trail. The table is built for inspection, sorting, filtering and CSV export, not for mutating historical records.

Yes. Any filtered set exports as CSV with operation, root type, depth, response time, errors and logged_at. The standard attachment for a regression ticket or a release postmortem.

No. GraphiQL still owns ad hoc query authoring and one-off inspection. SleekView adds a site-wide table on top of the log WPGraphQL already writes, so day-to-day query work and cross-operation auditing stop fighting for the same screen.