A website doesn't have to be down to have a serious problem. PHP warnings can appear above an otherwise normal WordPress site, a failed deployment can expose a stack trace, or a database error can make its way into the response. The server may still respond normally, but something is clearly wrong.

Sentinel can now detect these server-side errors automatically as part of normal website monitoring, helping you catch application problems that might otherwise go unnoticed until you or a client happens to visit the site.

Why I built server error detection

The idea came from something I saw on a real website. I opened the site and found a PHP deprecation warning sitting above the page:

Deprecated: preg_match_all(): Passing null to parameter #2 ($subject)
of type string is deprecated in /home/…/wp-content/plugins/…/Shortcodes.php
on line 525

The website itself still loaded, but visitors were being shown a PHP warning that included information about the server's filesystem and the plugin generating the error. It's exactly the kind of problem that can sit unnoticed until a developer happens to visit the page or, worse, a client reports it first.

That got me thinking about how Sentinel could catch this automatically, without requiring someone to anticipate the exact error beforehand. The result is a new layer of Sentinel's HTTP monitoring: automatic server error detection.

What Sentinel detects

When server error detection is enabled, Sentinel examines the response body for patterns associated with actual server-side errors. It can currently detect:

  • PHP warnings, notices, deprecations, and fatal errors
  • PHP stack traces
  • WordPress critical error pages
  • WordPress database connection errors
  • SQLSTATE and MySQL errors
  • Python tracebacks
  • Laravel exception and debug pages
  • Symfony errors
  • Yii and Craft CMS debug output
  • ASP.NET server error pages

You don't have to configure individual error messages or maintain a list of keywords. Sentinel knows what these errors typically look like and checks for them automatically as part of the normal HTTP check.

This isn't simple keyword matching

Sentinel already supports response assertions, including checking whether a response contains or doesn't contain specific text. That's useful when you know exactly what you want to monitor. For example, you could tell Sentinel to alert you whenever a page contains Fatal error.

Server error detection solves a slightly different problem. You shouldn't have to predict every PHP, database, framework, or application error that might eventually appear on a website, so Sentinel looks for recognizable error signatures instead.

A word like warning appearing somewhere on a page isn't enough to trigger an incident. Output structured like this, however, is much more likely to represent a genuine PHP warning:

Warning: [message] in /path/to/file.php on line 123

The same approach is used to identify stack traces, SQLSTATE errors, framework exception pages, WordPress errors, and other common server output. This makes detection broad enough to catch unexpected problems while reducing false positives from ordinary page content.

What happens when an error is detected?

When Sentinel identifies a server error, it creates a warning-severity incident containing information about the detected error and sends an alert through your configured notification channels. When the error disappears, Sentinel automatically resolves the incident and sends a recovery notification.

This gives application errors the same basic lifecycle as an outage while still distinguishing between a website that's unavailable and one that's responding but displaying an application error.

Why this matters for WordPress

WordPress is an especially good example of why this type of monitoring is useful. A plugin update, theme update, PHP version change, configuration issue, or deprecated function can introduce warnings or errors without necessarily taking the entire website offline.

You might end up with an otherwise usable page displaying something like:

Deprecated: Creation of dynamic property ... is deprecated

Or:

Warning: Undefined array key ...

In more serious cases, you might get:

Fatal error: Uncaught TypeError ...

If you're responsible for one website, there's a reasonable chance you'll eventually notice. If you're responsible for 50 or 100 client websites, manually checking every site after every update or deployment isn't realistic. That's where automatic server error detection becomes much more useful.

Server errors can expose sensitive information

Visible server errors aren't just a presentation problem. They can disclose information about the application and infrastructure running behind a website.

A PHP error may expose filesystem paths such as /var/www/example.com/public/wp-content/plugins/..., while a stack trace can reveal application internals, package names, classes, methods, and execution paths. Debug pages from application frameworks can potentially expose even more information.

None of this is something you generally want displayed publicly on a production website. Server error detection can therefore catch both an application problem and a potential information-disclosure issue.

Another layer of website monitoring

Uptime is still important. If a server stops responding or starts returning HTTP 500 errors, you want to know immediately. But application monitoring shouldn't stop with HTTP availability.

Sentinel already supports response assertions for checking that expected content exists or that unwanted content doesn't appear. Server error detection adds another layer by automatically looking for recognizable application-error patterns, including problems you didn't know to configure an assertion for ahead of time.

We've also written about the broader problem of websites that return a successful HTTP response even though something is clearly broken. If you want to dig deeper into that side of monitoring, read Your Site Can Return 200 and Still Be Down.

Available on every Sentinel plan

Server error detection is available on every Sentinel plan, including Free, and is automatically enabled when you create a new HTTP monitor. For existing monitors, you can enable it from the monitor settings. Sentinel doesn't automatically turn it on for existing sites because some older applications may already contain warnings or deprecated code that you aren't ready to treat as incidents.

Once enabled, Sentinel checks for server errors during its normal HTTP monitoring. There's no separate monitor to configure, no custom error signatures to create, and no list of keywords to maintain. It's simply another way for Sentinel to catch a problem before your users or clients do.