Turn PHP error logs into behavior, impact and lifecycle intelligence.
Titanium Error Intelligence – PHP Error Monitor & Diagnostics groups supported critical WordPress errors instead of leaving you with thousands of disconnected log lines. It detects spikes, recurring patterns, bursts and persistent failures, shows where requests were affected, tracks source-version changes and keeps the diagnostics local to your WordPress installation.
- 7-day grouped error intelligence
- 5-minute background monitoring
- Privacy-reduced Request Impact Map
- Local diagnostics by default
A focused Free WordPress diagnostics plugin.
Install the WordPress.org version and use the complete feature set included in the plugin: local error intelligence, debug-log tools, monitoring diagnostics, Request Impact, version lifecycle, self-test and live wp-admin alerts.
Understand how errors behave, not only what one log line says.
Titanium fingerprints supported critical failures, keeps a bounded recent history and adds practical context around frequency, timing, affected request areas and locally installed source versions.
Grouped critical errors
Fatal, parse, recoverable fatal, uncaught and WordPress database errors are normalized into grouped fingerprints so repeated failures stay together.
Behavior detection
Recognize sudden spikes, stable recurring intervals, short bursts, multi-day persistence, newly introduced errors and failures that have gone quiet.
Request Impact Map
Correlate available fatal-style context with frontend, REST API, AJAX, cron, login, wp-admin and WP-CLI execution without storing raw query-bearing URLs.
Version-aware lifecycle
See the locally installed plugin, MU-plugin, theme or WordPress version where an error was observed and whether it continued after a version change.
Monitoring self-test
Verify WP_DEBUG, WP_DEBUG_LOG, directory access, marker write/read, the five-minute monitor, intelligence storage and the local Site Watch health API.
Live wp-admin alerts
Optionally show newly appended PHP errors and warnings inside authorized wp-admin pages, with configurable visibility time and alert position.
Log viewer and file tools
Search, filter and auto-refresh loaded log lines, then safely download, rename, empty, delete or edit supported files when server permissions allow it.
Private log location
Keep an existing private WP_DEBUG_LOG path or let Titanium create a dedicated private log location outside the public web root and move the active log there.
A short local pipeline from log entry to useful diagnosis.
The background monitor reads only newly appended log data, groups supported critical failures and adds lightweight intelligence instead of repeatedly rescanning an entire log file.
WordPress writes the error
Use the normal WordPress debug-log pipeline. Titanium detects the configured WP_DEBUG_LOG path, including supported custom paths.
The monitor reads new data
A lightweight five-minute scanner follows a saved cursor and processes the newly appended part of the configured log.
Errors become intelligence
Supported errors are fingerprinted, grouped and analysed for recent rate, recurrence, bursts, persistence, source version and available request context.
You investigate the pattern
Use behavior labels, impact evidence, source lifecycle, the log viewer and the self-test to narrow the problem before changing code or plugins.
Behavior labels that add meaning to repeated failures.
One occurrence can be noise. A repeated pattern can be a signal. Titanium uses retained timing and frequency evidence to describe what a grouped error is doing now.
Recent activity is sharply higher than the retained preceding rate and meets the minimum recent-occurrence thresholds.
Enough recent occurrences follow a sufficiently stable interval for the plugin to report an approximate repeat timing.
Many matching errors arrive inside a short recent window, helping distinguish concentrated failures from occasional background noise.
The same grouped failure remains active across multiple days and has still been seen recently.
The grouped error was first observed recently, which can be useful when a deployment or configuration change just happened.
The error is still inside the retained history but has not been seen recently, helping show that a problem may have stopped recurring.
Diagnostics around the error, not data collection for its own sake.
Request and version context are intentionally bounded. The goal is to answer practical troubleshooting questions while avoiding unnecessary personal or secret request data.
Request Impact Map
When a fatal-style failure occurs after the plugin is running, Titanium can correlate a privacy-reduced request snapshot with the later grouped log record.
- Separates frontend, REST API, AJAX, cron, login, admin and CLI contexts.
- Stores normalized route shapes rather than raw query-bearing URLs.
- Replaces numeric IDs, email-like values, UUIDs, long hashes and token-like path values with placeholders where detected.
- Can show the most frequently affected normalized local route shapes for a grouped error.
Source version lifecycle
Version observations help answer whether the same grouped failure continued through a local plugin, theme, MU-plugin or WordPress update.
- Shows the first observed source version when available.
- Shows the version associated with the most recent matching error.
- Marks errors that continued after a source version changed.
- Can show that the installed source version changed and no recurrence has yet been seen on that version.
Debug-log tools for the same workflow.
The raw log still matters. Titanium keeps an authenticated viewer and file controls next to the intelligence layer so administrators can move from pattern to evidence without leaving the plugin.
Viewer, filters and auto-refresh
Load a bounded tail of large files, search the lines already in the browser and narrow them by common error categories.
- Filters for Error, Fatal, Exception, Cron, Warning, Notice, Deprecated and Database entries.
- Auto-refresh checks for updates every 10 seconds while the viewer is active.
- If the configured log does not exist yet, auto-refresh can wait and load it when WordPress creates it.
- The browser editor is bounded to smaller files and replaces the complete content only when explicitly saved.
Authenticated file operations
Manage supported log and text files only inside the configured directory, with capability checks and bounded file handling.
- Download an allowed log file for complete offline review.
- Rename, empty or delete a supported file when the directory is writable.
- Keep the background-monitor cursor aligned after primary-log edits and file operations.
- No recursive scan of arbitrary subdirectories and no recursive deletion of unrelated private-directory contents.
Local by default.
Error intelligence, grouped history, request-impact metadata and self-test data stay in the WordPress installation. The plugin performs no remote version lookup and does not bundle an external diagnostics service.
titanium_error_intelligence_get_health_summary()
The optional local integration function returns a compact health summary for other installed Titanium components without exposing raw stack traces, SQL queries or absolute server paths.
Frequently asked questions
Clear answers about what Titanium Error Intelligence monitors, what it stores and how the local debug-log workflow works.
Where can I get Titanium Error Intelligence?
Install the Free plugin from WordPress.org or upload its ZIP through Plugins → Add Plugin.
Is this only a debug.log viewer?
No. The viewer is one tool. The main diagnostics layer fingerprints and groups supported critical errors, analyses their frequency and timing, tracks source-version changes and correlates available request-impact context.
Which errors are grouped?
The grouped intelligence supports fatal errors, parse errors, recoverable fatal errors, uncaught errors, uncaught exceptions and WordPress database errors that match the plugin's supported log parsing.
How long is grouped error intelligence kept?
Grouped error intelligence is retained for up to seven days. Recent occurrence timestamps and request-impact metadata are bounded so unusually noisy sites cannot grow the stored history without limit.
How often does the background monitor run?
The built-in background error monitor is scheduled every five minutes. It follows a saved cursor and processes newly appended log data instead of rescanning the whole file on every run.
What does the Request Impact Map store?
When context is available, it can store execution context, HTTP method, a privacy-reduced route shape, logged-in or guest classification, timestamp and bounded local correlation metadata. It does not store IP addresses, query strings, POST bodies, usernames or user IDs.
Why do some grouped errors have no request context?
Context can be attached only when the plugin is already running in that request and PHP reaches the registered shutdown handler. Very early failures, storage failures and old log-only entries may have no matching context.
Does it make remote version lookups?
No. Version-aware lifecycle information comes from the versions installed locally for plugins, MU-plugins, themes and WordPress Core.
Does the self-test deliberately create a PHP error?
No. It writes a uniquely identified harmless marker through PHP's normal error-log channel and verifies that Titanium can read that marker back. The marker is not treated as a critical error.
Can it use a custom WP_DEBUG_LOG path?
Yes, including supported absolute custom paths outside the public web root, provided PHP has the required read permission. File-changing actions also require write permission.
Can it move the debug log outside the public web root?
Yes. Existing private custom paths are preserved. Otherwise an administrator can enable private storage so Titanium creates a plugin-specific private directory and moves the active log there.
What are Live admin log alerts?
When enabled, authorized wp-admin pages use AJAX to check the configured log for newly appended PHP errors and warnings. You can choose how many seconds alerts remain visible and whether they stay at the viewport top or the top of the admin page.
Does the plugin send my error history to an external service?
No. Error history, request-impact data and self-test information stay inside the WordPress installation. The plugin does not bundle an external diagnostics service.
How does WordPress Multisite work?
Because WP_DEBUG_LOG is installation-wide, Titanium Error Intelligence must be network activated. Network-scoped settings and intelligence are shared, request context can be captured across sites and one scanner runs from the main site.
Can plugin data be removed during uninstall?
Yes. Data is kept by default. Administrators can explicitly enable plugin-data removal before uninstall. A private directory created and owned by Titanium can be removed, while unrelated custom private directories are never recursively deleted.
Stop reading critical failures as isolated log lines.
Use Titanium Error Intelligence to group repeated failures, see how their behavior changes, identify affected WordPress request areas, follow source-version lifecycle and keep the raw log tools close when you need deeper evidence.
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.
- 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.
How to install Titanium Error Intelligence and set up WordPress debug logging
Titanium reads the normal WordPress debug-log pipeline. The plugin can help manage WP_DEBUG, WP_DEBUG_LOG and WP_DEBUG_DISPLAY, but it is best to understand the current path before changing anything on a live website.
Set up the first monitoring run
- Install and activate Titanium Error Intelligence – PHP Error Monitor & Diagnostics.
- Open Titanium Error Intelligence in wp-admin and find the WordPress debug logging card.
- Check whether debug logging is already enabled and note whether the site uses a custom WP_DEBUG_LOG path.
- If logging is off, enable debug logging from the plugin. Existing custom WP_DEBUG_LOG paths are preserved.
- Keep Display errors on screen disabled on a normal live website unless you have a specific temporary debugging reason.
- Confirm the configured log location is readable, then continue with the Monitoring Self-Test.
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.
How to read grouped critical errors instead of treating every log line as a separate problem
Titanium normalizes supported critical errors into fingerprints. Matching failures are grouped so the dashboard can show occurrences, behavior, impact, source lifecycle and the last detection time in one row.
Investigate one grouped error
- Open the Critical error behavior from the last 7 days card.
- Start with the Error column: read the normalized type, message, relative file information and source label when available.
- Check Occurrences to understand how much retained activity belongs to the same fingerprint.
- Read the Behavior badges before assuming a high total means the problem is getting worse right now.
- Use Impact map to see whether frontend or API traffic, background execution or admin activity was associated with the error.
- Use Source lifecycle to compare the error with locally installed component versions.
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.
How to use the Request Impact Map to see where a fatal-style error was felt
When context is available, Titanium correlates a small request snapshot captured during the failing request with the grouped error found later in the log. The snapshot is deliberately reduced before storage.
Use impact evidence step by step
- Open the Impact map column for the grouped error you are investigating.
- Check whether the strongest evidence is Frontend, REST API, Login, AJAX, Cron, Admin or CLI.
- Compare the counts across contexts instead of focusing only on the most recent request.
- If a normalized local route shape is shown, use it to identify the affected page or endpoint family without expecting the original query string.
- Compare the request context with the error source and behavior pattern.
- If no request context exists, use the behavior and raw log evidence instead of assuming the plugin failed to monitor the error.
How to tell whether an error continued after a plugin, theme or WordPress version changed
Titanium does not call a remote version service. It records locally installed source versions when matching errors are observed and compares retained observations with the currently installed source.
Read source lifecycle evidence
- Find the grouped error and read its source label. Titanium can identify plugins, MU-plugins, themes, WordPress Core, custom wp-content code or an unknown source.
- Look for First observed on v… to see the earliest retained source version associated with that group.
- Read the latest lifecycle label to see the version where the most recent matching error was observed.
- If the source changed versions and the error continued, treat that as evidence that the update did not stop the same grouped failure.
- If the installed source version is newer than the last-error version, the UI can show that no recurrence has yet been seen on the current version.
- Keep watching the group until enough time has passed to decide whether the update really resolved the pattern.
How to search, filter and auto-refresh the configured WordPress log
The browser viewer complements grouped intelligence. Large files are read as a bounded tail so wp-admin stays usable, while the complete allowed file remains available for download when you need every line.
Inspect the raw log efficiently
- Open the configured log in Titanium Error Intelligence.
- Choose how many recent lines you want loaded, then use Search loaded lines to find a message, file or path fragment.
- Use the All, Error, Fatal, Exception, Cron, Warning, Notice, Deprecated or Database filters to narrow what is shown in the browser.
- Enable Auto-refresh when you are reproducing a problem. The viewer checks for updates every 10 seconds while active.
- If the configured log has not been created yet, leave auto-refresh enabled while reproducing the issue; the viewer can load the file once WordPress creates it.
- Download the complete log when the viewer indicates that only the newest bounded part is being displayed.
How to see newly written PHP errors and warnings while you work in wp-admin
Live admin alerts are optional and authenticated. When enabled, a lightweight AJAX runtime checks the configured debug log only while an authorized admin page is open and shows newly appended errors or warnings inside wp-admin.
Configure the alert behavior
- Open the WordPress debug logging card and find Live admin log alerts.
- Enable live admin alerts. The setting is saved without requiring you to expose errors on the public site.
- Choose how many seconds each alert stays visible. The supported range is 3 to 60 seconds.
- Choose Always visible at viewport top when you want alerts pinned while scrolling, or Top of admin page when they should remain in the page flow.
- Open another wp-admin page and reproduce the issue you are investigating.
- Use the alert as a prompt, then open Error Intelligence or the raw log for the complete diagnostic context.
How to move the active log outside the public web root and manage files safely
Debug logs can contain sensitive technical information. Titanium can preserve an existing private custom path or create its own plugin-specific private location and move the active log there when the server allows the change.
Protect the log and use file actions
- Review the Log location card and check whether the current configured path is inside or outside the public web root.
- If the path is public and wp-config.php is writable, enable Store log outside the public web root.
- After the move, run the Monitoring Self-Test again to verify write and read access at the new location.
- Use Download before destructive cleanup when you may need the old history later.
- Use Rename only when you understand that changing the filename does not change WP_DEBUG_LOG; WordPress can recreate the original configured filename on the next log entry.
- Use Empty Log or Delete File only after confirming the stored history is no longer needed.
How to use Titanium Error Intelligence on Multisite and understand what stays local
WordPress debug logging is installation-wide on Multisite, so Titanium uses network-scoped settings and one scanner. The same local-first design applies to grouped error history, request-impact evidence and the optional health summary.
Set up Multisite correctly
- Install the plugin from Network Admin and network activate Titanium Error Intelligence.
- Use the plugin admin UI from the main site's wp-admin as intended by the network-aware workflow.
- Remember that intelligence data and settings are network-scoped because the debug log is shared across the installation.
- Allow request context to be captured across sites while one five-minute scanner runs from the main site to avoid duplicate processing.
- Review grouped intelligence within its seven-day retention window and download raw logs separately if you need a longer archive.
- If another installed Titanium component needs compact local health data, it can call titanium_error_intelligence_get_health_summary().
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.
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