The signals live in different places
Site Health, query monitors, cron screens, log files and database metrics each hold part of the answer and none of the context.
Your site got slower.
Find out what actually changed.
Diagnosing a slow WordPress site normally means opening six screens and holding the numbers in your head. Talos reads all of them in one pass — Site Health, object cache and autoload pressure, database metrics and table sizes, cron backlog, loopback latency — and tells you which one is actually out of line. Then it can diff two snapshots to show what moved.
WNorthstar Studio+ New
Howdy, Alex
Why "the site is slow" is hard to answer
Autoload bloat is invisible
Thousands of stale transients and autoloaded options load on every single request. Nothing in the admin UI makes that obvious.
You cannot see what changed
Without a baseline, every investigation starts from scratch and "it feels slower than last month" stays unfalsifiable.
What actually happens.
Read every signal in one pass
Site Health direct tests, object cache state, autoloaded option size, database connection pressure, largest tables, cron backlog and a bounded loopback timing check.
Rank findings by actual impact
Talos reports the numbers that are out of line and explains why they matter here, rather than restating generic best practice.
Fix the safe, bounded things
Clearing expired transients, trimming autoload bloat and resetting an overdue cron event are all captured in a reversible change set.
Snapshot, then compare
Take a diagnostic snapshot before and after, and diff them. You get a concrete before-and-after rather than an impression.
The exact tools it uses.
Talos does not improvise. Each of these is a defined tool with validated inputs, a declared risk level and its own policy setting.
Every diagnostic read is bounded and redacted. Database access is limited to read-only SELECT, SHOW, DESCRIBE and EXPLAIN, with secrets stripped from results.
See the full tool cataloginspect_site_health
ReadRuns bounded WordPress Site Health direct tests and returns structured findings.
inspect_cache
ReadObject cache state, transients and autoloaded-option pressure.
inspect_database_health
ReadDatabase server metrics, connection pressure and the largest prefixed tables.
inspect_database
ReadTable, column and index metadata. No row data.
inspect_cron
ReadWP-Cron events, overdue items, schedules and unusually frequent hooks.
inspect_http
ReadOne bounded same-site loopback or REST check, reporting status, latency and size.
compare_diagnostics
ReadDiff two diagnostic snapshots to show what actually moved.
query_database_readonly
ReadBounded SELECT, SHOW, DESCRIBE and EXPLAIN. Dangerous SQL is blocked and secrets redacted.
create_chart
ReadInline bar, line, area and pie charts built from real site data.
Or set it once and forget it.
Any of this can become a workflow. You write the prompt, choose the trigger, and lock the permissions before it ever runs.
How workflows workDaily health snapshot
WorkflowTrigger
Daily · 05:00 · site timezone
Prompt
“Take a diagnostics snapshot covering Site Health, cache and autoload pressure, database metrics and cron. Compare it to yesterday. Only email me if something moved materially in the wrong direction.”
Pre-authorized scopes
- site:read
- email:send
Delivery
Exception-based email. Silence means nothing regressed.
The outcome.
One pass across every diagnostic surface
Autoload and transient pressure quantified, not guessed at
Before-and-after snapshot diffs
Safe cleanups tracked and reversible
Before you rely on it.
Is this a page speed tool?
No. It diagnoses server-side and database-side health from inside WordPress: autoload pressure, cache state, cron backlog, database metrics, loopback latency. For front-end waterfalls and Core Web Vitals, use Lighthouse or a real-user monitoring tool alongside it.
Can it run database queries against my data?
Only read-only ones. query_database_readonly permits bounded SELECT, SHOW, DESCRIBE and EXPLAIN, blocks dangerous SQL outright, and redacts known secrets from results. inspect_database returns schema metadata with no row data at all.
Will it change things while investigating?
Not in Ask mode, which is inspect-only and has no access to write tools at all. That is the right mode for a diagnosis you just want to read.
Keep reading
Use case
Debug a broken site
White screen, 500 error, failing checkout or emails that never send. Talos reads your error logs, cron and HTTP responses to find the cause with evidence.
Read moreUse case
Update plugins safely
Talos reviews what an update changes, applies it inside a tracked change set with checksums, verifies the site afterwards, and rolls back if it went wrong.
Read moreUse case
Scan a hacked site
Suspect your WordPress site is compromised? Talos scans plugin and theme source for injected code, cites the exact file and line, and captures every cleanup step for rollback.
Read morePut an agent to work in WordPress.
Spend less time clicking through admin and more time moving your site forward.