StackFirefly – Error Tracking, Monitoring & AI

Find WordPress problems that uptime monitoring misses. StackFirefly provides error tracking and site monitoring for WordPress and WooCommerce. Firefly Agent connects your website to a dashboard for investigating PHP errors, browser JavaScript errors, missed scheduled tasks and email delivery problems—even when your homepage is still online. Built for site owners, developers and agencies, it brings monitoring evidence and recent changes together so you can understand what happened, investigate the cause and verify recovery. A StackFirefly account and connection to the external service are required. Service availability and allowances depend on your account plan. Review current plans at https://stackfirefly.com/pricing before connecting. This plugin is the local connector; monitoring history, incident correlation and AI-assisted diagnosis run in the hosted service. What you can monitor

• PHP error tracking and JavaScript errors: review grouped issues with sanitized messages, file and line details, affected page paths and stack traces where available.
• WP-Cron and scheduled tasks: check cron execution, WooCommerce Action Scheduler failures and overdue background jobs.
• REST API and AJAX connectivity: investigate failed background requests and origin connectivity problems that a homepage uptime check can miss.
• Email delivery monitoring: run user-requested or configured email tests to check whether a test message reaches the monitoring receiver.
• Security monitoring: review known plugin/theme vulnerabilities, security headers, bounded core/uploads file scans and privacy-minimized configuration changes.
• Lighthouse performance monitoring: follow PageSpeed test results, LCP, FCP and other available metrics over time through the hosted service.

AI-assisted suggestions use collected evidence; they are not proof of a cause or recovery. This plugin does not automatically repair your site, edit configuration files or update other plugins. Available evidence varies by error, connection and site configuration. WordPress Multisite is supported through network activation. Pair the main website, then choose which subsites to monitor in StackFirefly. Initial discovery supports up to 100 websites. Selected websites use individual site allowances; shared core/configuration findings appear on the main website. From an error to a next step Repeated reports are grouped into issues so you can review available evidence, follow recent changes, and record your investigation. Acknowledgements, reported fixes and verified recovery stay distinct. Deterministic checks establish recovery; an AI suggestion does not mark a problem as fixed. Connect your AI assistant with MCP Connect StackFirefly to ChatGPT, Claude, Codex or another compatible remote MCP client. Your assistant can review selected sites' issues, available evidence, recent changes and Lighthouse results without copying reports between tools. Choose the workspace, sites and permissions. Connections are read-only by default. Optional permissions allow issue acknowledgements, reported-fix notes and verification requests, not changes to WordPress. Revoke access in StackFirefly at any time; newly added sites are not shared automatically. This optional hosted-service feature requires manual setup and an AI account that supports remote MCP connections. It is separate from StackFirefly's built-in AI diagnosis. Setup guide: https://stackfirefly.com/docs#ai-connections External services and data StackFirefly — https://stackfirefly.com Pairing explicitly connects the site to StackFirefly over HTTPS. Before pairing, the plugin does not upload monitoring telemetry. Clicking the account/setup link passes the site's home URL, WordPress installation URL and display name to StackFirefly to prefill setup. Paired sites send authenticated heartbeats (normally every five minutes) and bounded batches of observations; inventory is sent periodically or when changes are detected. Retries are bounded. Reliable scheduled delivery requires working WordPress cron or a host-managed cron runner. Data may include site URLs and name, Agent/platform versions, PHP and web-server information, installed component names/slugs/versions and update state, status codes and timings, scheduler counts/ages, sanitized error messages, relative file/asset paths and line numbers, bounded stack frames, safe public page paths, third-party resource hostnames, file fingerprints and recognized configuration-setting change categories. Browser collection is served locally, is rate-limited and does not create visitor tracking identifiers. Requested PHP traces are bounded and omit function arguments. Passwords, API secrets, cookies, authorization headers, form contents, order/customer records, raw request bodies and complete response bodies are not intentionally collected. File contents and private configuration values stay on the site. Diagnostic sanitization limits the detail available; not every error includes a trace or page location. StackFirefly uses this data for monitoring, issue history, notifications and requested diagnosis. Its external probes request configured public pages. Performance tests, when requested or scheduled in the service, submit the public test URL to Google PageSpeed Insights. The plugin itself does not call Google PageSpeed Insights. AI-provider processing is described in the service privacy notice. If you authorize an external AI client through MCP, the selected monitoring context is shared with that client under your chosen permissions and the AI provider's own terms and privacy settings. MCP tools do not return Agent credentials or pairing keys; the plugin does not connect to those AI clients directly.

• StackFirefly terms: https://stackfirefly.com/terms
• StackFirefly privacy: https://stackfirefly.com/privacy
• Google terms: https://policies.google.com/terms
• Google privacy: https://policies.google.com/privacy

WordPress.org checksum service — https://api.wordpress.org/core/checksums/1.0/ After pairing, WordPress's checksum API may be used during scheduled core integrity checks. WordPress version and locale are sent to retrieve reference checksums. WordPress.org receives the requesting server's connection metadata. No local file contents are sent to that service.

• WordPress.org privacy: https://wordpress.org/about/privacy/
• WordPress.org terms: https://wordpress.org/about/terms-of-service/

Updates The WordPress.org package uses native WordPress plugin updates. Earlier direct-download packages use StackFirefly's signed release channel. Both use the same plugin folder and saved connection settings. Do not delete/uninstall the old plugin to migrate; use WordPress's upload-and-replace flow using the directory package. See the FAQ.

1. Install and activate Firefly Agent. For Multisite, network-activate it.
2. Open Settings → StackFirefly (Network Admin → Settings for Multisite).
3. Click "Connect to StackFirefly" and keep the WordPress tab open.
4. Sign in or create an account, verify your email, and approve the displayed website. Choose a workspace if prompted.
5. Return to the WordPress tab. It connects automatically and shows an Open dashboard link.

If you start in StackFirefly, save your website first, then follow the installation steps above. Your existing unpaired site is reused. Older installations can use "Connect another way (pairing key)". Connection requests expire after 30 minutes; start again if needed.

0.24.10

• Clarify the plugin name and directory description, including error tracking, scheduled tasks, email, security and performance monitoring.
• Add practical feature FAQs and refine the directory tags. No monitoring or connection behavior changes; existing sites stay connected.

0.24.9

• Configure smaller local file-scan batches and daily scanning windows from StackFirefly. Requires the matching app deployment and this Agent update.
• Preserve scan progress and respect selected hours for manual/automatic rechecks. Short windows can delay findings and recovery verification; other monitoring continues.

0.24.8

• Report bounded PHP statement edits with line ranges while keeping code, custom names and secrets local.
• Show approved literal memory limits and environment type. Requires the matching app update and two observed file versions; older details cannot be reconstructed.

0.24.7

• Make pairing-key setup more visible and automatically show errors after a failed pairing attempt.
• Show a clear connection notice on the Plugins screen while unpaired and add a Settings action link.

0.24.6

• Show actionable missing-encryption/storage notices and guard unsupported runtimes.
• Enqueue connection scripts only on the Agent settings page.
• Avoid cache-provider calls during activation and before connection.

0.24.5

• Allow quiet per-site multisite activation with a network-activation notice.
• Enforce browser request limits atomically and use WordPress file deletion helpers.

0.24.4

• Approve connections from WordPress without copying a key. Manual pairing remains available. Keep the WordPress tab open until connected.

0.24.3

• Simplify setup to a pairing key. The StackFirefly service address is automatic and cannot be changed in the setup form.

0.24.2

• Store database-error buffers encrypted in the runtime uploads directory, isolated per site. Single-site buffers migrate; old unscoped multisite buffers are retired.

0.24.1

• Remove the duplicate optional author URL from plugin metadata for WordPress.org submission.

0.24.0

• Guided account setup remembers website details through registration and workspace creation.

0.23.3

• Exclude identifiable browser-extension failures and extension frames from new JavaScript reports. Website and third-party script errors remain monitored.
• Update the Agent to apply filtering; existing reports are unchanged.

0.23.2

• Identify individual known wp-config constants and .htaccess directives that changed, including first declaration line numbers. Values and rule contents remain private.
• Finer comparisons start after this Agent observes both file versions; old reports cannot recover missing details.

0.23.1

• Expand wp-config.php and .htaccess change summaries with safe setting and directive categories; private values and category hashes stay on the site.
• Allow requested PHP traces to wait up to 24 hours for one matching error, with capability negotiation for older Agents.

0.19.2

• Adds content-free configuration change summaries for recognized settings and rule groups. Requires a backend accepting the optional configuration review fields.

0.19.1

• Schedules a fresh bounded core integrity scan immediately after a completed WordPress core update.
• Leaves failed or non-core updater operations on the normal daily schedule.

0.19.0

• Enumerates unexpected PHP-like files only inside the WordPress-owned wp-admin and wp-includes directories.
• Reports at most 50 safe core-relative identifiers with MD5 hashes and coarse metadata; never file contents or absolute paths.
• Keeps directory traversal resumable, bounded to two seconds and 10,000 entries, and reports incomplete work as unknown.

0.18.0

• Adds privacy-minimized configuration security observations for wp-config.php, .htaccess, debug display, registration privileges, file editing, and update restrictions.
• Confirms file fingerprint changes in a second background cycle before server-side review or alert decisions.

0.17.0

• Classify only strict, small directory-listing index.php placeholders locally without transmitting file contents.
• Keep server-side security decisions separate from the Agent's minimized content profile.

0.16.0

• Adds a signed, bounded manual integrity rescan command.

0.15.0

• Report up to 50 validated paths relative to wp-content/uploads for detected PHP-like files.
• Continue excluding absolute server paths and file contents.
• Schedule a fresh uploads scan after upgrade so relative-path evidence does not wait for the next daily scan.

0.14.0

• Resume bounded WordPress core and uploads scans across background cycles until their fixed scopes are complete.
• Report safe slice and cumulative progress without sending filenames, file contents, or absolute paths.

0.13.1

• Recognize WordPress.org plugins when the core no-update record omits its optional ID.
• Classify explicit third-party update URIs without exposing the URI.

0.13.0

• Add daily, read-only WordPress core checksum and uploads executable-file observations.
• Limit filesystem work to two seconds and 10,000 entries and report incomplete scans as unknown.
• Send only bounded relative core identifiers, site-scoped uploads path fingerprints, hashes, buckets, counts, and completeness; never file contents.

0.12.0

• Add a bounded daily and change-sensitive WordPress, WooCommerce, plugin, theme, and MU-plugin inventory for centralized vulnerability matching.
• Report only safe type, slug, version, active/update/auto-update state, theme role, provenance, completeness, locale, and a stable inventory fingerprint.
• Keep advisory access, exact affected-range matching, severity, incidents, alerts, and recovery entirely on the StackFirefly server.

0.11.0

• Add privacy-minimized plugin, theme, WordPress, WooCommerce, PHP, Firefly Agent, permalink, site-URL fingerprint, configuration-fingerprint, and administrator-count change history.
• Combine supported WordPress hooks with a bounded hourly inventory comparison so missed lifecycle hooks can be reconstructed without transmitting a complete inventory.
• Report only safe slugs, version/state transitions, aggregate administrator counts, actor classes, and fingerprints; never raw hook arguments, account identities, option values, file contents, or secrets.

0.10.0

• Keep bounded per-fingerprint PHP, database, and browser occurrence totals locally when daily telemetry budgets are exhausted.
• Delay and merge telemetry updates instead of treating transport suppression as lost evidence; report genuine coverage loss separately.
• Label PHP trace provenance as occurrence-time, embedded-stack, or shutdown fallback.

0.8.0

• Aggregate recurring PHP warnings, notices, and deprecations using bounded category-specific thresholds without replacing handlers or enabling debug settings.
• Keep recurring evidence privacy-minimized and rate-limited; warnings may degrade a check while notices and deprecations remain advisory.

0.7.2

• Retain a bounded non-IP third-party resource hostname and sanitized query-free pathname for failed scripts and stylesheets.
• Identify safe WordPress core, plugin, theme, and must-use-plugin asset paths for clearer deterministic diagnostics.

0.7.1

• Load the minimized collector on eligible storefront pages for both signed-in and signed-out visitors, without collecting identity, session, cookie, request-body, or response-body data.
• Keep cached pages valid by obtaining the short-lived signed token from a no-store runtime endpoint, and purge supported page caches after activation, upgrade, deactivation, and pairing.

0.7.0

• Add a lightweight self-hosted collector for minimized public-browser runtime, promise, resource-load, and bounded same-origin request failures.
• Exclude privileged administration and authentication surfaces and enforce signed short-lived collection tokens, strict schemas, privacy sanitization, aggregation milestones, and local rate/telemetry budgets.

0.6.0

• Capture bounded, locally sanitized PHP fatal and uncaught shutdown evidence for upload during the next healthy Agent cycle.
• Enforce per-site PHP error fingerprint and aggregate-event budgets without changing WordPress error handlers or sending during shutdown.

0.5.1

• Fix signed synthetic email command verification.