WordPress Debug Tracker: Who Broke What — Stack Traces and Agency Timeline (2026 Guide)

You get a client email on a Tuesday morning: "Checkout hasn't worked since yesterday." You open wp-admin — everything looks fine. Nobody admits activating a plugin. Hosting logs show 500 errors with no author. You grep debug.log — PHP notices, no link to the user who clicked "Update" on a marketing extension at 11:14 PM.

You're not alone. Every week agencies write to us after spending hours deactivating plugins one by one "to see" — without knowing who changed what, or from which PHP file the action originated. Simple History says "Plugin activated." Query Monitor helps on one live request. WP Activity Log charges for JSON export. And the client repeats: "It wasn't us."

This guide exists because we see two extremes: no traceability (blame, guesses, blind rollback), or unreadable logs without stack or AJAX context. The right answer is in the middle: timestamped timeline, attached PHP stack trace, business presets, JSON export without an account, and a clear list of when to cross-check Query Monitor or PUD.

Why read this article? You'll understand what Debug Tracker (DTB) does, how to read a stack trace frame by frame, how to run a 7-step agency investigation, which 4 presets to choose (Developer, Agency audit, WooCommerce, Security), and how DTB honestly compares to Stream, Simple History, WP Activity Log, Query Monitor, WooCommerce Debug Bar, and DebugPress. Comparison tables, error playbook, checklist for this week, FAQ from real support tickets.

What you'll learn: auth/content/ajax/rest categories · stack depth 5/8/12 frames · hook watchlist · synergy with Plugin Usage Detector, PHP Compatibility Checker, and Heartbeat Control Manager · JSON export · WP-CLI wp dtb tail · Slack and webhook integration · US-specific hosting and compliance considerations.

Let's start with the fundamentals — then move to action.

Understanding WordPress hooks — how DTB listens

Before diving into Debug Tracker, you need to understand WordPress hooks. Actions and filters are the backbone of every plugin — and DTB is no exception. The tool registers listeners on key WordPress hooks to capture what happens and when.

How hook-based logging works

When an admin action occurs in WordPress — activating a plugin, saving a post, processing an AJAX request — WordPress fires a hook. DTB attaches callback functions to these hooks. When a hook fires, DTB:

1. Captures the hook name and arguments passed by WordPress
2. Records the current user, timestamp, and request context
3. Grabs a PHP backtrace if the stack is enabled
4. Assigns a severity level based on hook category
5. Stores the event in the database

For example, when a user activates a plugin, WordPress fires activated_plugin. DTB hooks into this action, captures the plugin slug, the user ID, and walks the call stack to see what triggered it — was it the Plugins screen, a bulk activation, a WP-CLI command, or a scheduled plugin update?

The watchlist system

Beyond built-in categories, DTB offers a hook watchlist (connected account or higher). You specify custom hooks like:

• save_post_shop_order — track order saves
• user_register — monitor new signups
• wp_login — log successful logins
• edd_insert_payment — Easy Digital Downloads payments
• profile_update — track role changes
• wp_ajax_* — wildcard AJAX monitoring

Each watchlist entry fires a hook_watch event with the full context. This is how agencies catch custom plugin behavior that the standard categories don't cover.

Category-to-hook mapping

What makes DTB's hook capture different

Most activity log plugins record a message (e.g., "Plugin activated"). DTB records the message plus the call stack. That stack shows you the chain of PHP calls that led to the hook firing. Was the plugin activated through wp-admin by a human, or by a background plugin update cron job? The first three frames tell you.

What is Debug Tracker

Debug Tracker is not a "firewall" blocking bad actions. It's an investigation log: each event captures who (WordPress user), what (category + message), when (timestamp), context (post_id, AJAX action, REST route), and where in code (PHP stack trace).

How capture works

1. You enable DTB from Tools → Debug Tracker (or Volade menu) and apply a preset.
2. DTB listens to configured WordPress hooks: auth, content, plugins, themes, options, AJAX, REST, watchlist.
3. Each event is stored in the DB with severity (info to error) and stack trace when enabled.
4. You filter the Timeline by category, user, severity — or export JSON for the client folder.
5. You fix on staging, then switch to a quieter preset in production if needed.

Tools → Debug Tracker  →  WooCommerce preset  →  reproduce bug  →  filter ajax  →  read stack  →  fix

Categories — quick definition

What DTB protects (don't break this)

• Agency traceability: timestamped JSON export = contractual "who did what" deliverable.
• Transparent stack: file + line frames — not a black box "plugin X".
• Ignored users: exclude your internal accounts from client noise.
• Automatic prune: retention by tier — DB doesn't grow without limit.

What DTB does not do

• No Query Monitor replacement for profiling SQL/hooks on the current request.
• No blocking — observation only; no automatic rollback.
• No plugin fleet audit — for that, Plugin Usage Detector; DTB says who activated the plugin, PUD says if it's still used.
• No infinite stack on free tier — 5 frames often enough; 8–12 for deep WooCommerce AJAX.

Concrete example

An agency manages a WooCommerce store. Checkout broken since Saturday. WooCommerce preset enabled Friday morning. Timeline filter ajax: dozen calls to woocommerce_update_order_review. Stack frame 2 points to a client mu-plugin hooking woocommerce_cart_calculate_fees — activated the day before via plugin_activated at 10:03 PM, user "staging-freelance". Fix in 40 minutes — without deactivating half the stack "to test."

"Does this apply to me?" — 5 signs

1. You inherit a site with no documentation and "ghost" regressions.
2. The client asks "who edited the homepage?" with no answer.
3. You debug WooCommerce checkout or admin-ajax with no clear author.
4. You must deliver a billable incident report (security, unauthorized change).
5. Simple History or Stream aren't enough — missing stack or AJAX detail.

If at least two apply: read the stack trace section — then the 7-step workflow.

US-specific use cases for Debug Tracker

Debug Tracker solves problems that US agencies face daily. Here are the scenarios where it earns its keep in the American market.

E-commerce Black Friday / Cyber Monday post-mortem

US e-commerce runs on WooCommerce. A store owner calls on the Tuesday after Cyber Monday: revenue dropped 40% because a "minor" plugin update broke the checkout. Debug Tracker's WooCommerce preset captures every woocommerce_checkout_process, woocommerce_update_order_review, and payment gateway callback. You filter by the timeline window, find the exact hook that started returning errors, and trace it to a shipping calculator plugin updated at 3 AM Monday. Export JSON, present to the client, fix on staging, push live before lunch.

HIPAA logging for healthcare sites

US healthcare sites running WordPress need access logs that demonstrate who touched what and when. DTB's Security preset captures auth events, content changes, and sensitive option modifications. While DTB is not a replacement for a full HIPAA compliance suite, it provides the activity trail that auditors ask for: "Show me every change to patient-facing content in the last 30 days." JSON export serves as deliverable evidence.

Multi-location franchise sites

Agencies managing 20+ franchise locations on a WordPress multisite network need centralized logging. DTB V+ Premium offers multisite_central — one dashboard to see events across all subsites. When a franchisee's manager changes a theme setting and breaks the local menu, you see the theme or option event with the stack trace — no guessing which of 20 sites changed what.

Membership site debugging

LearnDash, MemberPress, TutorLMS, and Paid Memberships Pro are popular in the US market. These plugins fire complex AJAX chains during checkout, course access, and subscription management. DTB's Developer preset with wp_ajax_* watchlist captures every AJAX call. When a student reports "I paid but didn't get access," you filter by that user's timestamp and see the exact AJAX handler that failed — often a conflict between the membership plugin and a caching plugin.

US hosting environment nuances

• WP Engine: their firewall blocks certain admin-ajax patterns. DTB logs the AJAX call before WP Engine blocks it, so you can distinguish "plugin bug" from "hosting block."
• Kinsta: their MyKinsta analytics show server-level errors. DTB's stack trace shows the PHP-level cause. Cross-reference both for the full picture.
• Pantheon: their multidev workflow means changes can come from any environment. DTB on the live environment catches changes that weren't deployed through the proper workflow.
• Cloudways / DigitalOcean: standard LEMP stacks. DTB's PHP capture (V+) catches fatal errors that server logs miss.

Agency-client dispute resolution

In the US market, agencies commonly face clients who deny making changes. DTB's JSON export is a timestamped, user-attributed, stack-traced proof. It doesn't prevent disputes — but it ends them. Several US agencies report that presenting a DTB export during a "who broke the site" call cuts resolution time by 70%.

"

We support 12 WooCommerce stores on retainer. Before DTB, every "checkout is broken" call meant a full plugin audit — hours of work. Now we open the timeline, filter by the reported timeframe, and know exactly which plugin update caused it. Average time to identify root cause dropped from 4 hours to 25 minutes.

— E-commerce agency — Austin, TX (anonymized feedback, April 2026)

The PHP stack trace — how to read it without mistakes

The stack trace is Debug Tracker's signature. Each frame = a PHP function call: file, line, function. Reading a stack means tracing from symptom to code author.

Anatomy of a DTB stack

Depth by Volade access

Practical interpretation — scenarios

Stack vs message — which to trust?

The message says what (Plugin activated: foo/bar.php). The stack says how we got there (mu-plugin, admin cron, AJAX). For a fix, the stack wins; for a client deliverable, message + user + time often suffice.

When not to stop at DTB alone

The timeline is a help, not the only tool. Here are cases where we recommend cross-checking other signals.

List — complement DTB with

Presets to treat carefully for ongoing production

• Developer: high AJAX noise — staging or active incident only.
• Security with log_options: sensitive options — document CCPA/GDPR and retention.
• Hook watchlist woocommerce_*: high volume — limit observation window (24–48 h).

PUD, PCC, and HCM synergy

Typical agency workflow: DTB incident → fix → PUD if doubtful plugin → PCC before PHP → HCM if heavy admin-ajax.

Step-by-step — agency investigation (7 phases)

This section is the central tutorial. Block 1 to 3 hours for a checkout incident or "who touched what" audit. Don't skip JSON export.

1Framing (15 min)

1. Define goal: incident / audit / WooCommerce / security.
2. Note bug time window (since when?).
3. Install Debug Tracker by Volade on staging or production if urgent.
4. Create client folder /client-debug/YYYY-MM-DD/.

2Apply preset (5 min)

1. Tools → Debug Tracker → one-click preset.
2. Verify capture enabled.
3. Reproduce bug (or wait 30 min representative traffic).
4. Confirm first event in Timeline.

❝Without a Volade account, logging, 5-frame stack, JSON export, 4 presets work. Free account: advanced filters, CSV, watchlist, 2,000 events. V+ Premium: 50,000 events, PHP capture, scheduled digest, central multisite.

3Filter timeline (30 min)

1. Category filter: ajax for checkout; content for pages; auth for access.
2. Severity filter: security and warning first.
3. User filter if suspect identified.
4. Open event closest to bug time.

4Read stack trace (20 min)

1. Note frame 0 — file + line.
2. Identify plugin or theme (wp-content/plugins/ or themes/ path).
3. Cross-check JSON context (action, post_id, route).
4. If stack truncated at 5 frames — connect Volade account or V+ for 8–12.

5Staging fix (30 min – 2 h)

Recommended order:

1. Deactivate or fix identified component — not half the stack.
2. Reproduce path (checkout, form, key page).
3. Check Timeline — no linked error / warning events.
4. If false positive — widen filters, targeted watchlist (connected).

6Export and Volade stack (20 min)

1. JSON export: admin button or wp dtb export --file=client.json.
2. If doubtful plugin: Plugin Usage Detector scan before removal.
3. If PHP error: PHP Compatibility Checker on remaining stack.
4. Optional: Heartbeat Control Manager if AJAX noise persists.

7Client deliverable and watch (30 min)

• Report: timeline, author, cause, fix, stack summary.
• DTB JSON archived + final preset (often Agency or Security).
• 7-day watch: new login_failed, plugin_activated.
• Bill as investigation package — reproducible deliverable.

"

Tickets that drag on 90% of the time lack the JSON export at moment T. Without a snapshot, the client denies the event a week later. Export before fixing.

— Volade support team

DTB presets — Developer, Agency, WooCommerce, Security

Debug Tracker offers four dynamic presets for the most requested agency workflows.

Developer preset — "Technical debug"

For: developers, staging, obscure AJAX/REST incidents.

Workflow: reproduce bug → filter ajax → stack → fix → switch to Agency in prod.

Agency audit preset — "Who changed what"

For: client sites, readable deliverables, recurring maintenance.

WooCommerce preset — "Store stack"

For: checkout, orders, store admin, WC webhooks.

Security preset — "Access and integrity"

For: post-incident, access audits, role changes, compliance.

Bonus: Developer preset JSON export

Import the JSON preset from this article's resources to align the whole team on the same capture flags.

Your options in 2026

Not every site needs the same tool. Here are honest approaches.

Option 1 — Server logs + debug.log

For: sysadmin teams, pure PHP errors.

Option 2 — Stream

For: teams already on the Stream ecosystem, connectors.

Option 3 — Simple History

For: small sites, minimal readable log.

Option 4 — WP Activity Log

For: enterprise, heavy compliance, SIEM integrations.

Option 5 — Query Monitor

For: runtime debug — queries, hooks, per-page perf.

Option 6 — WooCommerce Debug Bar

For: WooCommerce-specific log reading.

Option 7 — DebugPress

For: developers used to integrated debug panel.

Option 8 — Debug Tracker by Volade (recommended for agencies)

For: agencies, WooCommerce, JSON deliverable — stack + 4 presets + timeline.

We built Debug Tracker because agencies deserve to prove who broke what — not guess on a Friday night.

Full comparison table

Setup and configuration guide

Getting DTB running takes under 5 minutes. Here's the full walkthrough.

Installation

1. Download from Volade CMS or install via Plugins → Add New in wp-admin.
2. Activate the plugin — no configuration needed at activation.
3. Navigate to Tools → Debug Tracker (or the Volade menu item).

WP-CLI install:

wp plugin install debug-tracker-by-volade --activate
wp dtb status

First-run experience

On first visit to the Debug Tracker page, you'll see:

1. A preset selector — choose Developer, Agency, WooCommerce, or Security
2. A capture toggle — enabled by default after preset selection
3. An ignored_users field — add your agency accounts here immediately
4. An event counter — shows 0 until actions are logged

Critical first steps:

1. Apply a preset before doing anything else — this sets all capture flags consistently.
2. Add your agency user IDs to ignored_users so your testing actions don't pollute client data.
3. Test with a simple action — save a draft post. You should see a content event appear within 30 seconds.
4. Set retention — configure how many days to keep events (default: 30 days free, 90 days V+).

WP-CLI reference

wp dtb status              # Check if capture is running
wp dtb tail                 # Live-tail recent events (like `tail -f`)
wp dtb export --file=log    # Export all events as JSON
wp dtb prune --days=30      # Prune events older than 30 days
wp dtb preset --name=agency # Apply a preset via CLI
wp dtb watchlist --add=save_post_shop_order  # Add hook to watchlist

Multisite configuration

Per-site logging works out of the box — each site in the network has its own timeline. For centralized network view, V+ Premium enables multisite_central — one dashboard showing all subsite events. Useful for agencies managing franchise networks or educational institutions.

wp dtb multisite --enable   # Enable centralized view (V+)
wp dtb multisite --site=3   # Filter by specific subsite

Database management

DTB stores events in wp_dtb_events (prefixed by your $table_prefix). The table stores:

• id — auto-increment
• user_id — WordPress user who triggered the event
• category — auth / content / plugin / theme / option / ajax / rest / hook / php
• message — human-readable description
• severity — info / warning / error / security
• stack_trace — serialized PHP backtrace (JSON)
• context — serialized extra data (post_id, action, route, etc.)
• created_at — timestamp

On free tier, the table is pruned to 100 most recent events. Connected accounts retain 2,000 events. V+ retains 50,000 events with configurable pruning.

Integration with other tools

DTB works well in isolation, but its real power shows when you integrate it into your existing workflow.

Slack notifications

Connected account users can configure Slack webhooks for critical events. Example: send a notification to #incidents when a security event is logged or when a plugin_activated event occurs.

Configuration:

1. Create a Slack webhook URL from your Slack workspace
2. Add it to DTB settings under Notifications → Slack
3. Select severity threshold (e.g., only security and error)
4. Test with a manual event

GitHub / GitLab issue creation

For agencies that track incidents in GitHub Issues or GitLab, DTB's JSON export can feed into automated issue creation:

wp dtb export --file=incident-2026-07-13.json

Then pipe into your CI/CD system to create an issue with the JSON attached. Third-party tools like Zapier can automate this end-to-end.

Sentry breadcrumbs

For teams using Sentry for error tracking, DTB events can be passed as breadcrumbs. When Sentry captures a PHP error, the preceding DTB events provide context — "user X activated plugin Y 5 minutes before the fatal error." This correlation is the difference between "server 500" and "this plugin update caused the crash."

New Relic / Datadog custom events

Enterprise agencies using New Relic or Datadog APM can pipe DTB events as custom metrics. Log a plugin_activated event to New Relic and create a dashboard showing plugin activation frequency per site. Datadog users can set monitors: "alert if more than 3 plugin activations in 1 hour on production."

Zapier / Make webhooks

DTB's outgoing webhook sends a JSON payload for each event to any Zapier or Make webhook URL. This enables:

• Create a Trello card when a security event fires
• Log events to a Google Sheet for monthly reporting
• Send SMS via Twilio for critical errors
• Create a HubSpot ticket for unauthorized changes

Volade ecosystem integration

The Volade suite works together out of the box:

1. DTB identifies who activated a plugin during an incident
2. Plugin Usage Detector tells you if that plugin is still needed
3. PHP Compatibility Checker scans for breaking code before PHP upgrades
4. Heartbeat Control Manager reduces AJAX noise when DTB reveals the source

Workflow: DTB finds the culprit → PUD validates removal risk → PCC checks upgrade safety → HCM silences noisy AJAX.

Performance impact

Every plugin has a cost. Here's what DTB adds to your WordPress site.

Database storage

Each event occupies approximately 1.5–2.5 KB depending on stack depth and context size. Real-world estimates:

At 50,000 events, the wp_dtb_events table is still smaller than most wp_options tables. DTB's automatic pruning keeps it manageable.

Query overhead

DTB adds one INSERT query per captured event. On a typical WooCommerce checkout (which fires 15–30 hooks), that's 15–30 INSERTs per transaction. For context:

• WordPress core itself fires 100+ hooks per page load
• The database write happens after the response is sent to the user (shutdown hook)
• Under the Agency preset, most page loads generate 0–2 events

Benchmarks (real-world staging tests)

Caching and CDN considerations

DTB only fires for authenticated admin requests. Public page loads — even cached ones — generate zero DTB events. CDN (Cloudflare, Fastly, KeyCDN) behavior is unaffected because logged-in users bypass full-page cache by default in most setups.

PHP execution time

Each event capture adds approximately 0.5–2 ms of PHP execution time (including stack trace generation). For context:

• A typical WordPress page load is 200–800 ms
• DTB adds at most 1–2% overhead on pages that generate events
• Admin pages (where events fire) are already slower than public pages — the overhead is negligible

Recommended hosting specs

DTB runs on any WordPress-compatible hosting:

• Shared hosting: works, prune regularly (free tier auto-prunes)
• Managed WP (WP Engine, Kinsta, Flywheel, Pressable): no issues, DTB respects their caching layers
• VPS / Cloud (DigitalOcean, Linode, AWS): full power, especially with V+ for 50,000 event retention
• Enterprise (Pantheon, WordPress VIP): DTB's WP-CLI integration fits deployment workflows

Pruning strategy

Pro tip: set retention to match your incident response SLA. If you typically investigate within 7 days, prune at 14 days. If you offer monthly reports, set 45 days.

Real US case studies

These anonymized reports from US agencies show DTB in action across different industries.

Case study 1: Brooklyn agency — 50 WooCommerce stores

Setup: Digital agency managing 50+ WooCommerce stores on a WordPress multisite network. Each store runs different plugins. When one store breaks, the clock is ticking on revenue loss.

Incident: A recurring "cart is empty after login" bug across 8 stores. The client assumed a hosting issue.

Investigation: DTB WooCommerce preset enabled with multisite_central (V+). Timeline filtered for ajax events around the reported timestamps. Stack frames revealed a membership plugin hooking woocommerce_get_cart_from_session — version 3.2.1 had a known bug that was fixed in 3.2.2, but the auto-update had failed silently on those 8 sites.

Result: Batch-updated the plugin on all 8 sites. Total investigation time: 1.5 hours. Without DTB, the agency estimates 2–3 days of per-site debugging. Blocked 30+ support tickets from forming.

Key takeaway: DTB's multisite central view caught a pattern across stores that per-site debugging would have missed.

Case study 2: San Francisco SaaS — LearnDash membership site

Setup: B2B SaaS company using LearnDash for customer onboarding. 15,000+ active users. Intermittent "access denied" errors after payment.

Incident: Users reported paying for a course tier but being locked out. The error appeared randomly — sometimes right after payment, sometimes 24 hours later.

Investigation: DTB Developer preset with wp_ajax_* watchlist. For three affected users, filtered the timeline to their payment timestamps. Each showed a wp_ajax_learndash_process_payment event followed by a REST route failure. Stack trace showed a caching plugin flushing the wrong cache group after LearnDash updated user meta.

Result: Adjusted the caching plugin's rules to exclude LearnDash user meta keys. Fix took 2 hours including testing. Prior to DTB, the agency had spent a week trying to reproduce the issue in staging.

Key takeaway: DTB's stack trace on AJAX events made a "random" bug reproducible and solvable.

Case study 3: Austin DTC brand — WooCommerce + Subscriptions

Setup: Direct-to-consumer brand selling subscription boxes via WooCommerce + WooCommerce Subscriptions. 5,000+ active subscribers.

Incident: New subscribers stopped receiving "Welcome" emails. The email marketing plugin showed no errors, and SendGrid logs showed the emails were delivered.

Investigation: DTB WooCommerce preset. Filtered hook_watch for woocommerce_subscription_payment_complete. Stack frame 2 pointed to a custom mu-plugin that attached to the same hook but called wp_die() on a validation failure — blocking the email plugin's callback from executing.

Result: The mu-plugin (written by a former developer) had a loose if (! defined('ABSPATH')) guard that ran unconditionally in certain request contexts. Removed the guard. Fix: 30 minutes.

Key takeaway: DTB revealed a PHP execution order conflict that no log file could have shown. The stack trace proved that Plugin A was running before Plugin B on the same hook.

Case study 4: Chicago healthcare system — HIPAA content audit

Setup: Regional healthcare system with a WordPress patient portal (custom theme, HIPAA-scoped). 50+ content editors across 3 hospitals.

Incident: Compliance audit required a report of "all content changes in the last 90 days" — who, what, when, and why.

Investigation: DTB Security preset with log_options enabled. Timeline exported weekly for 13 weeks. Exported JSON was ingested into the compliance team's reporting pipeline.

Result: Full 90-day audit trail delivered in 2 hours of work (vs. estimated 2–3 days of manual log grepping). The DTB export satisfied the auditor's requirement for "user-attributed content change history."

Key takeaway: DTB isn't a HIPAA compliance tool by itself, but its JSON export provides the activity trail auditors require. Combined with server access logs and backup verification, it closes a common compliance gap.

Case study 5: Los Angeles media site — high-traffic publishing

Setup: Digital media publication with 2M+ monthly visitors. 20+ authors, editors on a custom editorial workflow.

Incident: A scheduled post published 6 hours late. The author blamed the editor, the editor blamed the scheduling plugin, the scheduling plugin's support blamed WordPress core.

Investigation: DTB Agency preset. Filtered content events for the post ID. Timestamp showed save_post at the scheduled time — but the wp_cron event that should have triggered it was delayed. Stack trace revealed a resource-intensive SEO plugin's crawl process was queued on the same cron schedule, blocking the publish event.

Result: Moved the SEO crawl to a separate schedule using WP-Cron controls. Investigation: 45 minutes.

Key takeaway: DTB's hook-level detail proved the code path — the cron job fired, but an earlier cron event consumed the available execution time. Without DTB, this would have been a "random delay" with no clear fix.

Common mistakes and how to avoid them

Even with a good preset, these problems return in most investigations.

"Empty timeline — DTB doesn't work"

Why: capture disabled, or your agency account in ignored_users by mistake, or Security preset without expected event.

How to avoid:

• Check enabled and wp dtb status
• Test simple action (save draft) — expect content event
• Temporarily remove ignored_users on staging

"Too many events — I can't see anything"

Why: Developer preset in production on Black Friday, or endless woocommerce_* watchlist.

How to avoid:

• Switch to Agency audit or Security post-incident
• Limit watchlist to precise hooks (save_post_shop_order)
• Category + severity filters before reading

"Stack stops in the middle"

Why: depth 5 frames — mu-plugin deeper.

How to avoid:

• Volade connected account (8 frames) or V+ (12)
• Cross-check Query Monitor on live reproduction
• Check frame 0 — often already the culprit plugin

"I deactivated ten plugins — bug still there"

Why: investigation without stack — roulette.

How to avoid:

• Read frame 0 before any deactivation
• One plugin per hypothesis on staging
• JSON export proof for client

"Client refuses logging — privacy concerns"

Why: no contractual maintenance framing.

How to avoid:

• Limited Agency preset, documented retention (CCPA compliance note included)
• JSON export = incident proof, not permanent archive
• Restricted admin access — maintenance contract clause
• For California clients, reference CCPA exemption for business security monitoring

"JSON export doesn't load in their SIEM"

Why: older SIEM tools expect specific schemas.

How to avoid:

• DTB JSON uses a flat, documented schema
• Use wp dtb export --format=csv for legacy systems
• Connect account enables CSV export natively

"Watchlist hooks aren't firing"

Why: hook name typo or the hook fires before DTB initializes.

How to avoid:

• Verify hook name with wp dtb watchlist --test=hook_name
• DTB initializes at init priority 10 — hooks firing earlier (muplugins_loaded, setup_theme) may not be captured
• Use must_use category for mu-plugin-related events

FAQ — questions we get most

Does Debug Tracker block user actions?

No. DTB observes and records — no action is prevented. Deliberate so client admin flow isn't broken. If you need action blocking (e.g., prevent plugin deactivation by non-admin roles), pair DTB with a role management plugin like User Role Editor or WPFront.

How is DTB different from Query Monitor?

Complementary. Query Monitor = live request debug page by page — SQL queries, hooks, enqueued assets, all for the current page load. DTB = action history with stack trace — who activated the plugin yesterday, who edited the homepage last week. Use both: DTB for historical author attribution, QM for live performance profiling.

DTB vs Simple History — when should I use each?

Simple History is great for clients who need a simple, readable change log with zero configuration. It records post saves, plugin changes, and user logins. But it has no stack trace, no structured AJAX/REST capture, and no WooCommerce presets. Use Simple History for basic auditing; add DTB when you need to investigate an incident and prove root cause.

Can DTB help with CCPA / HIPAA compliance?

Indirectly yes. DTB provides the user-attributed activity trail that compliance auditors request. JSON export can be archived as evidence of content changes and admin actions. For CCPA, DTB's ignored_users helps exclude employee activity from logs. For HIPAA, combine DTB with proper server logging, backup verification, and access controls. DTB is a logging tool — not a compliance framework — but it fills the "who changed what" gap that many compliance programs miss.

Does DTB work with page builders (Elementor, Divi, WPBakery, Beaver Builder)?

Yes. Page builders fire standard WordPress hooks (save_post, wp_ajax_*, REST routes) that DTB captures. With page builders, look for:

• ajax events — Elementor's live editing uses AJAX extensively
• rest events — Divi and Beaver Builder use the REST API for saving layouts
• content events — final post saves appear here
• Stack trace frames often show the page builder's PHP callback as frame 0 or 1

What happens to DTB logs if I uninstall the plugin?

Events are stored in a custom database table (wp_dtb_events). When you deactivate and delete the plugin, you have two options:

1. Export before uninstall — use wp dtb export --file=dtb-archive to save all events as JSON. Re-importable if you reinstall later.
2. Database cleanup — the uninstall routine optionally drops the table. By default, DTB asks before deleting.

Recommendation: always export before uninstalling. You don't want to lose the incident trail when a client disputes something six months later.

Can DTB forward events to my SIEM (Splunk, ELK, Datadog Logs)?

Indirectly. DTB exports JSON and CSV. You can:

• Use wp dtb export in a cron job to pipe events to your SIEM's ingestion endpoint
• Configure the Zapier / Make webhook to send events in real-time
• Use the Slack integration to alert on critical events

Native SIEM connectors (Splunk HTTP Event Collector, Logstash) are planned for V+ 2026. For now, the JSON export and webhook provide programmatic access without requiring direct database queries.

For agencies — what should I bill for DTB investigation work?

Document an incident runbook (checklist + JSON + timeline). Bill as WordPress maintenance or investigation package — typically $200–600 for a standard incident, $800–1,500 for complex cases involving multiple sites or custom code. The DTB export transforms "hours of guesswork" into "documented 90-minute investigation."

For ongoing monitoring, include DTB setup and monthly JSON export in your maintenance retainer. V+ Pro (5 sites) or V+ Agency (unlimited) for long history and PHP capture across the Volade catalog typically pays for itself in one saved incident.

Your action plan this week

Use this checklist as an execution layer — print it, share internally.

WordPress Debug Tracker checklist

• Investigation goal documented (incident / audit / WC / security)
• Debug Tracker installed — staging first if possible
• Preset applied: Developer / Agency / WooCommerce / Security
• Ignored_users configured (agency accounts)
• Bug reproduced or 24 h observation window
• Timeline filtered (category + severity + user)
• Stack trace read — frame 0 identified
• Staging fix tested (checkout / forms if WC)
• JSON export archived client folder
• Plugin Usage Detector if suspect plugin to audit
• PHP Compatibility Checker if PHP error (V+ / logs)
• Production preset adjusted (Agency or Security)
• Client report + 7-day watch
• Slack / webhook notification configured (if connected account)
• Retention policy set matching your SLA

Recommended tools

• Debug Tracker by Volade
• Plugin Usage Detector by Volade
• PHP Compatibility Checker by Volade
• Heartbeat Control Manager by Volade
• Query Monitor — runtime debug complement
• Volade V+ pricing — 50k history, PHP capture, multisite

Resources & PDF guide

Download public checklists and Developer preset JSON from this article's resource panel. Members unlock the 12-page complete guide with stack matrices, 7-phase workflow, integration diagrams, and technical FAQ.

Conclusion — prove before accusing

Sites break because WordPress makes changes easy — not traceability. When the client says "it wasn't us," you're not condemned to log grep or mass deactivation.

Debug Tracker was built for the moments that define an agency's reputation: the Friday night emergency, the "this never happened before" dispute, the post-Black Friday post-mortem. With a timestamped timeline, PHP stack traces that point to the exact file, four business presets tuned to real agency workflows, and JSON export that serves as contractual proof, DTB transforms debugging from guesswork into forensic investigation.

The difference between "we think it was the last plugin update" and "this plugin was activated at 10:03 PM by user 'staging-freelance', frame 0 points to `/plugins/email-marketer/includes/class-hooks.php:147" is the difference between a billable investigation and a stressful, unpaid argument.

Our final recommendation for US agencies:

• This week: install DTB on a pilot staging site, apply Agency audit preset, trigger a test change (draft + dummy plugin activation), read the stack, export JSON.
• Next month: roll out DTB across all managed sites. Add your agency accounts to ignored_users. Set up JSON exports in your monthly reporting.
• First incident: use the 7-phase workflow. Export before fixing. Present the JSON to the client. Watch how quickly "it wasn't us" turns into "OK, what's the fix?"
• Scale: add Plugin Usage Detector for plugin audits, PHP Compatibility Checker for upgrade safety, and Heartbeat Control Manager for AJAX optimization.

If you choose Volade: welcome. We built this tool because agencies deserve to show proof, not assume. Your timeline — and your Friday nights — will thank you.

---

Article updated July 13, 2026. Sources: Volade field tests, Stream / Simple History / WP Activity Log / Query Monitor / WooCommerce Debug Bar / DebugPress comparison, DTB 1.0 documentation, US agency feedback from NY, SF, Austin, Chicago, and LA.