Tailwatch – Security, Backups, Monitoring & Management

Yes. Core features run locally on your WordPress site with no paid subscription required.

No. An account is only required for optional features like push notifications and license/account sync.

No. Tailwatch uses lazy loading, caching, and scheduled background processing for performance efficiency.

Only when you enable optional features such as: – Push notifications – License verification – Optional feedback submission Core features remain fully local. See the "External Services" section below for the full breakdown of each transmission.

Yes. Every module in Tailwatch can be individually enabled or disabled.

When you request a login link from an already-authenticated Tailwatch session (the mobile app or the connected dashboard), the plugin issues a single-use link that expires within one hour and signs in only the administrator who requested it. The link is stored hashed, so a copy of your database reveals no usable link, and it is invalidated the moment it is opened. Because it is a passwordless login you start yourself, opening the link signs you straight in — like a password-reset link, it is an alternative to typing your password rather than a second prompt.

The optional Performance Optimizer feature can add a "Tailwatch Performance Settings" block to your site's root .htaccess — but only if you apply PHP configuration settings from that feature and your server runs Apache with mod_php (the plugin probes for support first). It uses WordPress core's insert_with_markers() function, which scopes the change to a single BEGIN/END marker block and preserves every other line in the file; the plugin never rewrites the whole file. After writing, it verifies your site still responds and automatically removes the block if anything fails. You can clear these settings at any time from the feature. The optional File & Directory Access hardening options (under Files & Permissions) can add a separate "Tailwatch File Access" block to your root .htaccess when you turn them on — for example to block direct web access to sensitive files such as wp-config.php, disable directory browsing, or stop PHP execution inside the uploads folder. That block uses the same WordPress core insert_with_markers() function (scoped to its own BEGIN/END markers, every other line preserved), is only written when the .htaccess file is writable, is verified with a loopback request, and is automatically removed if your site stops responding; turning the options off removes it. Separately, Tailwatch writes deny files (.htaccess, index.php, web.config) inside its own storage folders under uploads/tailwatch/ and wp-content/tailwatch/ to keep their contents unreachable over the web; it makes no other changes to your .htaccess.

During a heavy operation you start — a malware scan, file-integrity check, hardening audit, or backup — Tailwatch may temporarily raise PHP limits (memory_limit, max_execution_time) for the duration of that request so the operation does not fail on constrained hosts. This is a runtime-only adjustment: nothing is written to any file, it never lowers a limit your host already sets higher, and it has no effect outside the running scan.

The optional Network Logs feature (off by default) records lightweight metadata about internal WordPress traffic — REST API, admin-ajax, cron, and XML-RPC requests — so you can review recent activity, status codes, and slow responses. For REST requests it reads the already-parsed request through WordPress's own rest_post_dispatch hook; for the others it reads only the sanitized action and request parameters. It stores the endpoint/route, HTTP method, status code, response time, and the requesting user and IP. Before anything is saved, credential, token, and nonce values are redacted, cookies are never captured or stored, and every value is length-capped. Raw request bodies and response bodies are never stored, and none of this data is sent anywhere — it is kept in your own database and can be cleared at any time from the feature. The feature only records while you have it switched on.

Yes. For extra defense in depth you can define TAILWATCH_JWT_SECRET_KEY, TAILWATCH_APP_SECRET_KEY, and TAILWATCH_ENCRYPTION_KEY in your wp-config.php file (seed each with a fresh value from https://api.wordpress.org/secret-key/1.1/salt/). When these constants are set, Tailwatch uses them for token signing and encryption instead of generating and storing a key in the database, which keeps the secret out of database backups, staging clones, and read-only SQL exposure, the same way WordPress keeps its own security keys and salts in wp-config.php. This is entirely optional: if you do not set them, Tailwatch automatically generates a strong random key and stores it in a non-autoloaded option, the same approach WordPress core uses for its own fallback salts.