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.

Self-TestSafe Check

How to verify the complete local monitoring pipeline without generating a fake PHP error

The Monitoring Self-Test checks the pieces Titanium depends on. It uses a harmless uniquely identified marker through the PHP error-log channel instead of deliberately crashing the website.

Run and read the self-test

Open Titanium Error Intelligence and find Monitoring Self-Test.
Press Run self-test and wait for the local checks to finish.
Verify WP_DEBUG and WP_DEBUG_LOG report the expected state for the site.
Confirm the configured log directory is writable and the harmless marker can be written through PHP's error-log channel.
Confirm Titanium can read the same marker back from the configured log.
Check that the five-minute monitor is scheduled, intelligence storage is writable and the local Site Watch health API is available.

If one check fails

A WP_DEBUG or WP_DEBUG_LOG failure means new log intelligence may not be produced.
A directory-write failure usually points to filesystem ownership or PHP permission problems.
A marker-write or marker-read failure means the configured PHP error log and the path Titanium reads are not behaving as expected.
A missing background schedule means the automatic five-minute scan needs attention.
The self-test marker itself is not recorded as a critical error by the intelligence scanner.

Best practice: Run the self-test after moving the debug log, changing server permissions or migrating the website to a different host.

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