External Troubleshooting
How To Use This Page
Section titled “How To Use This Page”Pick the tab that matches what you are seeing in WordPress or in TMXIO. Each tab walks through the most common version of that symptom: most likely cause, how to verify it, and how to fix it. If your symptom does not match any of the tabs cleanly, choose the closest one — most of these problems share underlying causes (network, credentials, edge auth) and the fixes overlap.
If you are starting from a “site is disconnected” alert and are not sure where to begin, start with the Connection tab. If the site loads fine in a browser but TMXIO disagrees, the Status Drift tab is usually the right place.
Symptoms
Section titled “Symptoms”The plugin is installed but the site is not configured
Section titled “The plugin is installed but the site is not configured”Most likely cause: the connection setup was never completed. The plugin is installed and active, but no credentials were saved, so heartbeats never started.
How to verify: open the TMXIO plugin page in WordPress and confirm whether it is asking you to create an account, enter an API key, or finish the connection flow. If you see the two-choice “create account / enter API key” screen instead of a connected state, the setup is genuinely unfinished.
How to fix: complete the current connection flow in the plugin. Follow Connect a WordPress Site end to end, paying particular attention to the workspace-selection step if your account can reach more than one workspace.
Test Connection fails
Section titled “Test Connection fails”Most likely cause: the site cannot reach TMXIO normally, the connection state is incomplete, or the credentials are no longer valid.
How to verify: retry the test once to rule out a transient network blip. If it still fails, confirm the site has outbound HTTPS access by loading any external resource from the WordPress host, and check whether the site sits behind extra authentication that might intercept the call.
How to fix: depending on the failure wording, either fix the outbound connectivity, relax the edge protection in front of /wp-json/, or reconnect the site with a fresh API key. If the wording is generic and gives you nothing to work with, contact support with the exact text the plugin shows.
TMXIO is unreachable
Section titled “TMXIO is unreachable”Most likely cause: the site cannot reach TMXIO from its current host or security layer.
How to verify: run Test Connection and compare the failure mode with the host’s general outbound posture. A host that cannot reach any external service will fail every test; a host that can reach most services but not TMXIO is almost always being filtered.
How to fix: confirm the site can make outbound web requests and is not blocked by an extra protection layer. If the host has an outbound allowlist, add TMXIO’s API hostname to it.
My API key is rejected
Section titled “My API key is rejected”Most likely cause: the key is invalid, copied incorrectly, or belongs to a different account than expected.
How to verify: copy the key again from TMXIO. Paste it into a plain text editor first to confirm there is no trailing whitespace, no truncation, and no smart-quoted character introduced by a chat client. Then validate it in WordPress.
How to fix: use a fresh key from the correct TMXIO account and workspace. If the same key works elsewhere but not on this site, the failure is on the connection path itself rather than the credential, and you should move on to the Connection tab.
Site limit exceeded or backup capacity is exhausted
Section titled “Site limit exceeded or backup capacity is exhausted”Most likely cause: the account or workspace has hit an allowed limit, so a new credential cannot register a new site.
How to verify: compare the visible plugin or TMXIO message with the plan or capacity state of the account. Capacity-related rejections are almost always called out explicitly in the failure wording.
How to fix: review the workspace’s current plan and capacity with your account owner. Free up capacity (by disconnecting a retired site, for example) before retrying, or upgrade the plan.
The site loads in a browser but TMXIO says it is disconnected
Section titled “The site loads in a browser but TMXIO says it is disconnected”Most likely cause: heartbeats are being silently blocked between the WordPress host and TMXIO. The site itself is fine; the outbound call is what’s being interrupted.
How to verify: run Test Connection from inside WordPress admin. If it fails, the outbound call is being blocked. If it succeeds, the dashboard should refresh to healthy within a minute or two.
How to fix: review any edge protection (Cloudflare, AWS WAF, Wordfence country rules, .htaccess deny rules) that could intercept outbound calls, and review host-level egress firewalls. Whitelist TMXIO’s outbound path.
Status flaps between healthy and degraded
Section titled “Status flaps between healthy and degraded”Most likely cause: the WordPress host’s outbound connectivity is unstable, or the host is so saturated that the plugin’s cron occasionally fails to run.
How to verify: check the host’s CPU and memory utilization over the same window the flaps happen in. If the host is consistently near saturation, the cron is the symptom, not the root cause.
How to fix: stabilize the host. Either resize the host, address the workload that is saturating it, or migrate the site somewhere with steadier outbound networking.
The site is behind HTTP auth
Section titled “The site is behind HTTP auth”Most likely cause: a protected staging or prelaunch site requires extra credentials before WordPress can complete the connection path cleanly. The classic version of this is an .htpasswd wall in front of the entire site, including /wp-json/.
How to verify: ask whether the site uses HTTP authentication in front of WordPress. Confirm by trying to load https://example.com/wp-json/ from a browser with no credentials. If you get a Basic Auth challenge, the wall is what is in the way.
How to fix: either move the auth wall so it does not protect /wp-json/tmxio/, or whitelist TMXIO’s IPs at the auth layer. If neither is acceptable for the staging environment, you can temporarily disable the wall for the connection step and re-enable it afterwards — the connection itself is stateful and will keep working once established, provided heartbeats can also pass.
Cloudflare Access or similar SSO is in front of the site
Section titled “Cloudflare Access or similar SSO is in front of the site”Most likely cause: an SSO layer is challenging every request, including the plugin’s outbound call, with a login page that the plugin cannot satisfy.
How to verify: load the site in a clean browser session with no SSO cookies. If you are bounced to an identity provider before reaching WordPress, every outbound call from the plugin sees the same thing.
How to fix: add a Cloudflare Access policy bypass (service token or IP bypass) covering the heartbeat endpoint, or relax the policy for the WordPress API namespace.
Disconnect fails
Section titled “Disconnect fails”Most likely cause: the remote cleanup did not finish even though the local action started. The plugin recorded the disconnect intent on the WordPress side but TMXIO never received or processed the corresponding API call.
How to verify: refresh the plugin page and compare the local state with TMXIO. If the plugin shows disconnected but TMXIO still shows the site as connected, the states have drifted.
How to fix: contact support with the site URL and the approximate disconnect time if the states do not reconcile on their own within a refresh cycle. Do not repeatedly toggle the disconnect button — that tends to make the drift worse, not better.
TMXIO still shows the site after the plugin was deleted
Section titled “TMXIO still shows the site after the plugin was deleted”Most likely cause: the plugin was deleted from WordPress without going through a clean disconnect first. TMXIO has no way to learn that the plugin is gone except by watching heartbeats stop.
How to verify: wait through the disconnected timeout window. After ten missed heartbeats the site should transition to disconnected on its own.
How to fix: if you want it removed from the dashboard sooner than the natural timeout, contact support with the workspace and site URL.