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 account sync.

Tailwatch is built to keep its impact small: it uses lazy loading and caching, and runs long tasks such as backups, restores and scans in the background in small steps. While those tasks run they use your server's CPU, memory and disk like any other work, so their effect depends on your hosting.

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.

Tailwatch stores all logs and operational data locally in your WordPress database (custom tables {prefix}tw_settings, {prefix}tw_logs, {prefix}tw_filemon_baseline, and {prefix}tw_filemon_scans) and on disk under uploads/tailwatch/tailwatch-logs/ (logs and generated data) and wp-content/tailwatch/tailwatch-backup/ (backup archives). While a restore runs, it prepares the backup's files and sets the site's replaced files aside in wp-content/tailwatch/tailwatch-restore/, and removes them when it finishes. These directories are sealed with deny files (.htaccess, index.php, web.config) so their contents are not reachable over the web. Data stored locally: – Activity logs — login/logout events, failed login attempts (including the username submitted and the originating IP address), registrations, password reset events – HTTP error logs — 4xx / 5xx responses captured during the request lifecycle – Email logs — SMTP send results for outbound site mail – Backup metadata — backup catalogue entries (filenames, sizes, timestamps); the actual archives live in wp-content/tailwatch/tailwatch-backup/ – File integrity baselines — file path + hash snapshots used to detect added / modified / deleted files – Broken link / redirection records — URLs detected on your site and any redirects you have configured – System configuration data — every plugin feature toggle, schedule, and threshold lives in {prefix}tw_settings – Client IP addresses — captured for security-relevant events (failed logins, rate-limited requests, redirection hits) so the dashboard and audit trail can show where the event came from – Login Defender state — IP addresses temporarily locked out after repeated failed logins, throttling counters, and the per-IP activity history that drives the lockout decisions – Geo-blocking lists — IPs and IP ranges you have explicitly allow-listed or block-listed via the Geo-blocking screen, plus the timestamp and admin who created each rule – Visit / usage telemetry — a local-only counter in the tailwatch_visit_data option, used to drive in-dashboard onboarding hints; never transmitted No user data, logs, or PII is transmitted to external servers unless an optional feature is explicitly enabled by the site administrator. The full list of outbound transmissions is documented in the "External Services" section below.

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; this feature 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. There is one case where Tailwatch does replace your root .htaccess rather than adding a marker block to it: while a restore or a site migration is running, and only then. Replacing the whole site's rewrite rules is the point — the site has to stop serving visitors from a database and a set of files that are being swapped underneath it. Before the file is replaced, your original is copied to .htaccess.tailwatch-migration-bak in the same folder, and Tailwatch also writes a tailwatch_maintenance.php file in your site's root to serve the "Site Under Maintenance" page. When the restore or migration finishes — or fails, or is abandoned — both are removed and your original .htaccess is put back exactly as it was. The maintenance file also removes itself and restores your .htaccess if it is left behind for more than 30 minutes without the job that created it checking in, so a crashed job cannot leave your site closed. You only ever get here by starting a restore or a migration yourself.

Only in these two cases:

• Performance Optimizer (optional): when you apply PHP settings from that feature (memory limit, execution and input time, upload and post size, number of uploads), Tailwatch applies the ones PHP allows to change at run time on each request with ini_set(), and writes all of them to your server's own configuration so the rest take effect too: the "Tailwatch Performance Settings" block in your root .htaccess on Apache with mod_php (see above), or the same-named block in a .user.ini file in your site root on PHP-FPM, FastCGI, LiteSpeed and CGI servers (PHP picks up .user.ini changes within about five minutes). Only that block is changed; every other line in .user.ini is kept. Clearing the settings from the feature removes the block. Deactivating the plugin does not, so clear the settings first if you no longer want them.
• Tailwatch's own long tasks: while a backup, restore, file integrity check, hardening audit or (with Tailwatch Pro) malware scan runs, Tailwatch raises PHP's memory limit and maximum execution time for that request only, through WordPress's wp_raise_memory_limit() and set_time_limit(). It never lowers a limit, nothing is saved, and the next request starts from your site's own limits again.

Only when it brings in a database. Right after the database is switched over, Tailwatch switches off the plugins that could lock you out of the restored site: login-hiding, firewall, captcha and domain-mapping plugins and, on a site without HTTPS, forced-SSL plugins and settings (such as a shop's forced secure checkout). They are listed at the end of the restore and stay installed, so you can switch them back on from the Plugins screen. Developers can change or empty the list with the tailwatch_restore_deactivate_plugins filter. During every restore Tailwatch also adds a small temporary must-use file, 0-0-tailwatch-restore-guard.php. If a must-use plugin crashes the site while it starts up, the guard renames that plugin's file (adding .tailwatch-disabled) so the next page loads, and the restore lists it at the end. The guard is removed when the restore finishes, fails or is given up on, and deletes itself on the next page load once it is more than 30 minutes old if anything leaves it behind.

During a heavy operation you start — a malware scan (with Tailwatch Pro), 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.

Tailwatch is 100% open source and distributed under GPL-2.0-or-later. The complete, human-readable source code — including the React source and the Create React App / Webpack build tooling used to produce the admin dashboard bundle that ships with this plugin — is publicly available at: https://github.com/tailwatch/tailwatch The React source for the admin dashboard lives under admin-app/ in that repository. To reproduce the compiled bundle that ships in this plugin, from the repository root: npm run build That installs the pinned dependencies, builds the React app, and copies the compiled bundle into Admin/View/Static/. Prerequisites are Node.js 20 or later and npm 10 or later. Full reproducibility notes — the exact Node/npm versions used for the shipped build, every runtime dependency, and its license — are documented in README.md at the repository root. Bug reports and pull requests are welcome via GitHub Issues: https://github.com/tailwatch/tailwatch/issues