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, 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
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