Andy Whalen

Creates a log file for network/multisite super admin actions.
The following actions are logged for Super Admin users. WordPress action names are listed in parenthesis:
<ul>
<li>change network settings (update_site_option)</li>
<li>grant super admin privileges (granted_super_admin)</li>
<li>revoke super admin privileges (revoked_super_admin)</li>
<li>upgrade blog (wpmu_upgrade_site)</li>
<li>add blog (wpmu_new_blog)</li>
<li>set blog archived (archive_blog/unarchive_blog)</li>
<li>set blog deleted (make_delete_blog/make_undelete_blog)</li>
<li>set blog mature (mature_blog/unmature_blog)</li>
<li>set blog spam (make_spam_blog/make_ham_blog)</li>
<li>delete blog (delete_blog)</li>
<li>delete user (wpmu_delete_user)</li>
<li>delete user (deleted_user)</li>
<li>change other user’s settings (edit_user_profile_update) [NOTE: doesn’t show diff]</li>
<li>change blog setting (updated_option) [NOTE: may occasionally log annoyingly large diffs]</li>
</ul>
The following actions are logged for ANY user:
<ul>
<li>login (wp_login)</li>
<li>logout (wp_logout)</li>
<li>new user (user_register)</li>
</ul>
Some actions that change data will show what the value was before and after.
Below is an example of a log entry when the user ‘smith’ has changed the Network site name from “WP Local Network” to “WP Local Networks”:
<pre><code>[Tue, 03 Sep 2013 13:45:49 +0000] [smith:1] [update_site_option] [1] [site_name] [(WP Local Network)->(WP Local Networks)] [127.0.0.1] </code></pre>
Each line in the log file will roughly follow the below example. Individual actions may log slightly different information, but the DATETIME, USERNAME, USER_ID, ACTION, and IP_ADDRESS sections should always be populated.
<pre><code>[DATETIME] [USERNAME:USER_ID] [ACTION] [AFFECTED_OBJECT_ID] [DATA_TITLE_OR_KEY] [(VALUE_BEFORE)->(VALUE_AFTER)] [IP_ADDRESS] </code></pre>

Observer

Creates a log file for network/multisite super admin actions.

loopj

Automatically detects errors & crashes on your WordPress site using BugSnag to notify you by email, chat or issues system.
All websites crash from time to time, including WordPress sites! Th BugSnag Error Reporting plugin automatically detects crashes, exceptions and other errors in your WordPress PHP code as well as any errors in plugins you are using.
Errors are sent to your <a href="https://bugsnag.com" rel="nofollow ugc">BugSnag Dashboard</a> for you to view and debug, and we’ll also notify you by email, chat, sms or create a ticket in your issue tracking system if you use one. We’ll also show you exactly how many times each error occurred, and how many users were impacted by each crash.

BugSnag Error Monitoring plugin

The plugin is easy to set up; all errors can be monitored via the Bugsnag dashboard. You can also set different log levels and differ between the environments (dev/production) of your website.

Bonus: There are lots of cool integrations like Slack (Push Notifications), GitHub (New Issues) and much more!

Easy error monitoring

Seamless integration with Bugsnag, just perfect.

Works great, people are just dumb

This plugin used to be one of the best tools out there, however, it seems like is not being maintained anymore. 

There is no support for the recent releases of PHP (8.0, 8.1). Recent support requests are not being handled anymore as well.



Abandoned.

Automatically detects errors & crashes on your WordPress site using BugSnag to notify you by email, chat or issues system.

Observer vs BugSnag Error Monitoring plugin