Titanium Error Intelligence Tutorials

10 practical ways to turn WordPress PHP errors into clearer local diagnostics.

These step-by-step tutorials cover first-time setup, the Monitoring Self-Test, grouped error behavior, Request Impact, source-version lifecycle, the log viewer, live wp-admin alerts, private log storage, file tools, Multisite and the plugin's seven-day local retention model.

Get Free Version Plugin Overview

Grouped critical errors
Request Impact Map
Monitoring Self-Test
Local by default

Step-by-step PHP error monitoring tutorials.

Start by making sure WordPress can write a debug log, then verify the pipeline before relying on the intelligence cards. Use the behavior and impact evidence to narrow a problem, and only then move into the raw log or file tools when deeper inspection is needed.

BehaviorTiming

How to interpret Spike, Periodic, Burst, Persistent, New and Quiet labels

The behavior engine uses bounded recent occurrence timestamps and retained day activity. Labels describe observed timing and frequency evidence; they do not invent a root cause that the log did not prove.

Read the labels in context

Treat Spike as a sharp recent increase relative to the retained preceding rate, not simply as a single severe error.
Treat Periodic as an approximate stable repeat interval. Compare it with known scheduled jobs, but do not assume cron caused it without other evidence.
Treat Burst as many matching errors concentrated inside a short recent window.
Treat Persistent as a matching error active across multiple days and still seen recently.
Use New to focus on failures first introduced recently, especially after a deployment or configuration change.
Use Quiet to recognize a retained error that has not recurred recently. Stable rate means no stronger behavior label is currently supported.

Evidence shown beside labels

Titanium can show the number of matching occurrences in the last 15 minutes.
Periodic errors can show an approximate repeat interval in minutes or hours.
More than one label can apply to the same grouped error at the same time.
A periodic pattern describes timing only; it does not identify the scheduler or plugin responsible by itself.
Behavior changes as old evidence expires and new occurrences arrive.

Example: An error can be both Periodic and Persistent when it repeats at a stable interval across several days. That combination is more informative than the raw total alone.

Start with logging, then verify the pipeline before interpreting the dashboard.

The most reliable order is simple: enable or confirm the debug log, run the self-test, wait for real matching errors, inspect behavior and impact, then use the raw log only when you need deeper evidence.

Get Free Version

Need the complete feature overview?

Read the Titanium Error Intelligence plugin page for grouped error behavior, Request Impact, source lifecycle, Monitoring Self-Test, live wp-admin alerts, private log storage and the authenticated log tools in one place.

View Plugin Overview