DebugBundle

DebugBundle helps you understand what went wrong when a WordPress site breaks. Instead of piecing together PHP logs, browser errors, request details, and plugin or theme context by hand, the plugin sends the important debugging evidence to your DebugBundle project.

Use it when you want a clearer answer than “something broke.” DebugBundle gives the developer or AI agent fixing the site the backend and visitor-side context around an incident, so they can see what happened, where it happened, and what evidence is available.

DebugBundle is built for agent-first debugging workflows. If you use an AI coding agent, DebugBundle reports give the agent structured incident evidence instead of a vague error message or copied log snippet. That helps the agent investigate plugin, theme, integration, and frontend failures with the same context a developer would need.

Setup stays simple: install the plugin, paste your DebugBundle project token, and run the built-in test buttons. You do not need Composer, npm, shell access, CDN scripts, or a custom relay setup.

Useful for:

• production PHP errors, fatal errors, and uncaught exceptions
• browser exceptions that visitors hit on public pages
• failed or slow first-party requests seen by the browser
• recent visitor actions and page changes that help explain a frontend error
• WordPress, PHP, service, environment, and SDK version context for developers or AI coding agents
• AI-assisted debugging workflows where an agent needs structured incident evidence instead of copied logs

What gets captured:

• PHP errors allowed by error_reporting(), uncaught exceptions, fatal shutdown errors, request metadata, and logs at or above the configured level
• frontend browser exceptions from public pages
• error-only browser breadcrumbs such as clicks, route changes, and first-party request failures
• service, environment, WordPress, PHP, and SDK version context useful for debugging

How delivery works:

• backend events are sent server-side through debugbundle/sdk-php
• backend batches do not send during capture; one small best-effort request-end attempt prioritizes exceptions and may briefly occupy a PHP worker or lose events during an outage
• browser events are posted to /wp-json/debugbundle/v1/browser and forwarded server-side
• transient browser relay delivery failures are retried through a bounded local spool
• the browser SDK is served from this plugin package, not from a third-party CDN

What it does not do:

• it does not contact DebugBundle until an administrator saves a project token or defines DEBUGBUNDLE_PROJECT_TOKEN
• it does not expose the project token to page JavaScript
• it does not capture wp-admin traffic by default
• it does not add incident browsing, billing, account management, or dashboard features inside WordPress
• it does not let an agent change WordPress settings, content, users, plugins, or themes

External services

This plugin connects to the DebugBundle service at https://api.debugbundle.com to send production incident telemetry and to fetch SDK capture configuration for the connected DebugBundle project.

The plugin only sends data after a site administrator enters a DebugBundle project token in the plugin settings and saves it. Backend PHP/WordPress incidents may include sanitized exception, request, response, environment, service, log, and WordPress context needed for debugging. Browser incidents are posted to a same-origin WordPress REST route first and then forwarded server-side to DebugBundle, so the project token stays server-side and is never exposed to page JavaScript. Browser JavaScript is served from this plugin package, not from a third-party CDN.

The service is provided by DebugBundle:

• Service: https://debugbundle.com
• Terms of Service: https://debugbundle.com/terms
• Privacy Policy: https://debugbundle.com/privacy