Two tools answer the question "what state is this site in right now" without visiting your hosting panel, running phpinfo or opening files. Most support tickets close faster when the reports from these two are attached to the first message.
Neither tool changes anything.
They read and display, so running them on a live site at any moment is safe.
#Run Diagnostics before you start
Most people learn this the other way round. Diagnostics is a pre-flight check, and it takes two minutes, so run it before anything heavy:
- Before your first demo import, which is the heaviest thing a site ever does and the operation most likely to hit a server limit.
- Before installing the recommended plugins and integrations.
- Before updating the theme or the Pro plugin on a site you have not touched in a while.
- Once at the very start, on a brand-new install, so you know what you are working on.
You do not have to remember all of that. The Demo Import, Integrations, Updates and Fonts screens each run the relevant checks themselves and show a banner when one of them fails, so a short max_execution_time is named on the page where it is about to matter rather than in the error afterwards.
A passing Diagnostics run saves time for both of us.
If a problem turns up later and the checks were passing, that rules out the causes that come from hosting: memory, execution time, missing PHP extensions, an unwritable uploads folder, a blocked REST API. A support conversation can then start from what is left, which is usually one question instead of five.
It works the other way too. A ticket about a failed demo import on a site where Diagnostics has been showing a red memory_limit for a week gets an answer about the memory limit.
#System Info
A snapshot of the environment, on its own page in the theme dashboard.
#The installation card
At the top, status pills for each component: the theme, the companion plugin and the Pro plugin, each in one of three states: active, installed but disabled, or not installed.
This is the fastest answer to "why do I not have the Pro features". You can see at a glance whether the Pro plugin is present and whether it is switched on.
#The environment card
The PHP version and its limits, the WordPress version, and server details, plus additional blocks that Pro adds. Some rows carry a status, normal or warning, with a tooltip explaining what the value means.
#The copy button
The most useful thing on the page. It collects the whole report as plain text, aligned into columns.
That text is what we ask you to paste into a support request, either in the message or as a text file if it is long.
Paste the copied text instead of a screenshot.
Text can be read, searched and quoted back to you in a reply. A screenshot is hard to read, and half the values are usually cut off.
#The logs card
View and download the framework log. This is a different file from the WordPress debug.log, and neither replaces the other.
#Diagnostics
On the Tools page, under the Diagnostics tab.
It comes with the Pro plugin. On a free build the tab is visible but locked, because the engine behind it is not installed.
#What it does
It runs a set of checks the moment you press the button and shows each one as its own row with a status (passed, warning or failed), a short explanation and a hint about what to do.
The checks are grouped by category:
- Server
PHP version, the PHP extensions the theme needs (
curl,mbstring,gd,zip,fileinfo,domandsimplexml),memory_limit,max_execution_time,max_input_vars, SSL, file permissions, whether the uploads folder is writable, and the upload size limits (post_max_sizeandupload_max_filesizetogether).- WordPress
WordPress version, WP-Cron, and whether the REST API answers.
- Theme
Theme configuration, the state of Pro features, and the integrity of the theme's own settings rows in the database.
- Hub
Connectivity to Hub, checked live, and whether the scheduled license check has run recently enough.
Its copy button works the same way the System Info one does. Attach both.
#The daily history
The same checks run once a day in the background, and each result is kept as a dated snapshot. The history holds thirty days, with older entries pruned on each run, so the panel shows a trend as well as the current state.
#Email notifications
Off by default, enabled by their own setting. The digest goes to the WordPress administrator address.
An email is sent when a check changes state.
Green turning yellow or red sends one; staying red does not, and each check has a 24-hour cooldown so the same problem cannot email you every morning. A quiet inbox means nothing has changed since yesterday, which is not the same as everything being fine.
#A failed check is usually a message for your host
A red row in Diagnostics is almost never a theme bug. It is a value your hosting plan is set to, and the person who can change it works at your host.
So the order is: run Diagnostics, read the hint on the failing row, ask your host for that specific value, and open a ticket with us only if the answer does not help. A ticket that starts with "diagnostics says max_execution_time is 30 and my host will not change it" gets a useful answer right away, because there is a real question in it.
#Common questions
Diagnostics is grayed out
The Diagnostics engine ships with the Pro plugin, so a free build shows the tab locked. System Info works without it and carries most of the same environment data.
My license is having problems. Can I still run Diagnostics?
Yes. Diagnostics does not re-check your license before letting you open it, on purpose: a licensing problem is one of the things you would want to diagnose, and a tool that locks itself when something is wrong fails you when you need it. The Hub category has a connectivity check in it for that reason.
Can running these break anything?
No. Both only read, which is why they are safe on a live site at any time of day.
Where is the framework log stored?
Under your uploads folder, in the theme's own directory. The System Info card shows the path, the size and a download button for it.
Everything passes and my problem is still there
Then the environment is not the cause, which narrows things down. Move on to the debugging steps, then to a ticket with both reports attached.
Neither screen will open
The panel is built on the REST API, so a security plugin blocking it is the first suspect. The WordPress Site Health screen (ToolsSite Health, then the Info tab) carries much of the same environment data and works independently of our panel.
#Still stuck
Open a support ticket and say what you tried and where it stopped. Your product, your domain, a screenshot and the exact message you saw are usually enough to settle it in one reply.
Last updated
