DEV Community: Marcin Szterling

Two Monolog majors, one PHP class: adding exception-log monitoring across Magento 2.4.7-2.4.9

Marcin Szterling — Fri, 18 Sep 2026 19:28:45 +0000

I just shipped a new signal in Watchtower, my Magento monitoring tool:
application_errors, which watches for a rising rate of caught exceptions
your own code is logging, before that shows up anywhere else, like checkout.
The feature itself is simple. Getting there across three supported Magento
versions was not, and the two bugs I hit only showed up under live
verification, not unit tests. Here's what happened.

The goal: count exceptions without reading a log file

Every existing signal in my connector observes Magento's event bus or polls
a status table. This one is different: I wanted to know when a store's own
code starts throwing more than usual, at the point Magento's logger actually
logs it.

The obvious approach is tailing exception.log. I rejected it early: log
rotation, file permissions, and offset tracking are all real failure modes,
and none of them should ever be able to produce a false anomaly. Instead I
hook Magento's own Monolog handler stack directly, via di.xml, so I
intercept each log record in memory at the moment it's dispatched, the same
moment Magento's own Handler\System and Handler\Exception do. I never
open, read, or track an offset into any file. Whatever happens to the
physical log afterward has zero effect on the counter.

Bug 1: Monolog 2 vs Monolog 3

Magento 2.4.7 ships Monolog 2.x, where a handler's $record is a plain
array. Magento 2.4.8 and 2.4.9 ship Monolog 3.x, where it's an immutable
LogRecord object. HandlerInterface's method signatures are incompatible
between the two majors, so one PHP class cannot implement both.

My first attempt was the obvious one: two concrete classes, class_alias()'d
to a common name at runtime depending on which Monolog major was loaded.
That worked fine under normal autoloading. It fataled under
bin/magento setup:di:compile.

The reason: Magento's compiler eagerly requires every class file in every
module for reflection (repository/proxy/interceptor generation), regardless
of whether anything actually references that class. Both concrete handler
files declared a top-level class ... implements HandlerInterface, and PHP
interface-checks a top-level class declaration the moment its file is
parsed. So the "wrong" file, whichever Monolog major wasn't installed where
compilation ran, always fataled immediately. The class_alias() gate never
got a chance to run, because compilation never went through it at all.

The fix: put both implementations in one file, each declared inside its own
branch of a runtime
if (class_exists(\Monolog\LogRecord::class)) { class Handler ... } else { class Handler ... }.
PHP hoists and interface-checks a top-level class statement immediately,
but a class declared inside a conditional block is bound only when that
branch actually executes. The untaken branch is never checked against
whichever HandlerInterface happens to be loaded, compiler included. Both
branches declare the literal same class name, so di.xml's reference
resolves correctly either way, no alias needed.

Bug 2: di.xml doesn't merge the way you'd expect

Magento's app/etc/di.xml is the primary bootstrap configuration, and it
already registers three core handlers on
Magento\Framework\Logger\Monolog: system, debug, syslog. My first
working version of the module's own di.xml declared only my new handler as
a fourth array item, assuming Magento would merge it into the existing three
by item name, the normal behavior for a per-module di.xml.

It doesn't, at this specific precedence boundary. A module-level
<argument name="handlers"> replaces app/etc/di.xml's array wholesale
rather than merging into it. My first version silently dropped system,
debug, and syslog. I confirmed it live with
Monolog\Logger::getHandlers(): one handler instead of four. That would
have disabled exception.log, system.log, and debug.log for every
install running this version.

No unit test caught it. PHPStan didn't catch it. What caught the bug was
running the module against a real Magento install and counting handlers,
not trusting a green test suite. Fixed by explicitly redeclaring all four
items.

What shipped

application_errors is now my 10th tracked signal: install-scoped (a
logged exception has no reliable store-view attribution), one-directional
(a quiet hour is never anomalous, only a spike is), and classified with the
same median/MAD dispersion baseline my three rate-based signals already
use. It only counts records carrying exception context at Warning level or
above, mirroring the same condition Magento core's own Handler\System
uses to route a record to exception.log in the first place. It never
reads the exception message or stack trace, count only.

Both bugs here were invisible to static analysis and to a green PHPUnit
suite. The thing that found them was doing the boring thing: installing the
actual module on actual Magento 2.4.7, 2.4.8, and 2.4.9 containers and
checking what really happened.

Why I stopped trusting uptime monitors for Magento stores

Marcin Szterling — Sat, 22 Aug 2026 11:23:57 +0000

I have been working with Magento for about a decade now, across agency and freelance work, and I have lost count of how many times a client called me in a panic over a store that was, according to every monitoring tool they had, perfectly healthy.

That gap between what a monitor reports and what a merchant actually experiences is what pushed me to start building something new. This article is about the gap itself, not the product, though I will mention what I am building at the end for anyone curious.

The homepage lies

Most uptime monitors work the same way. They ping a URL, usually the homepage, on a schedule. If it returns a 200, everything is green. If it times out or returns an error, you get an alert.

The problem is that a Magento homepage is one of the least demanding pages in the entire store. It is heavily cached, often served straight from Varnish or Fastly without ever touching PHP. It can return a 200 in twenty milliseconds while checkout, three layers deeper in the application, is throwing exceptions on every single attempt.

I have seen this exact scenario more than once. A payment method integration silently breaks after a third party API changes something. The homepage keeps loading fine. The category pages keep loading fine. The only place the failure shows up is at the final step of checkout, which is precisely the page an uptime monitor never checks because it requires a session, a cart, and usually a real transaction to reach.

By the time anyone notices, it is not a monitoring alert that catches it. It is a customer complaint, or worse, a quiet multi hour dip in orders that nobody clocks until someone pulls the daily sales report.

APM tools were not built with Magento in mind

The next instinct is usually to reach for a generic APM tool. These are genuinely useful for a lot of things, response time tracking, error rate monitoring, infrastructure metrics. But they are built to be platform agnostic, which means they have no concept of what actually matters inside a Magento store.

A generic APM will tell you that a request took 400 milliseconds. It will not tell you that the request was a reindex job that stalled halfway through, leaving your catalog in an inconsistent state. It will not tell you that a cron job responsible for order status sync has not run successfully in six hours. It will not tell you that your Redis cache is being invalidated far more aggressively than it should be, quietly increasing database load on every page view.

These are Magento specific failure modes, and they need Magento specific context to detect. A tool that treats every application the same way will always miss the things that are unique to how this platform actually behaves in production.

The failures that matter most, and why they hide

A few patterns I have run into repeatedly, that generic monitoring consistently misses:

Background jobs that fail silently. Magento relies heavily on cron for indexing, order processing, and various scheduled tasks. When a cron job fails, it often does not throw a loud error. It just does not run, or runs partially, and the next scheduled run may or may not recover cleanly depending on what state it left things in.

Index staleness. If reindexing falls behind or fails, customers can see stale pricing, out of stock items shown as available, or search results that do not reflect recent catalog changes. None of this trips an uptime check. The site is up. It is just wrong.

Payment method degradation. Third party payment integrations change their APIs, rotate certificates, or have partial outages. A payment method can go from working to failing for a subset of transactions, which is much harder to catch than a full outage and much more damaging because it looks like normal traffic with a quietly climbing failure rate.

Cache invalidation storms. A misconfigured extension or a bad deployment can cause full page cache to be invalidated far more often than intended. Traffic looks the same. Server load quietly climbs. Nobody notices until response times degrade under peak load.

Every one of these has a common thread. The store is technically up. Nothing in a standard monitoring stack fires an alert. The damage accumulates quietly until it becomes visible in a place nobody was watching, usually the sales numbers or a support inbox full of complaints.

What actual Magento monitoring needs to look like

The conclusion I kept coming back to is that Magento specific problems need Magento specific baselines, not generic thresholds borrowed from a platform agnostic tool.

A fixed threshold, alert if response time exceeds two seconds, alert if error rate exceeds five percent, treats every store the same regardless of its normal traffic pattern, catalog size, or extension footprint. What is normal for a high traffic B2C store with thousands of SKUs is very different from what is normal for a lower traffic B2B store with complex custom pricing.

What actually works is learning what normal looks like for a specific store, and alerting on meaningful deviation from that baseline rather than an arbitrary number picked in advance. A cron job that usually completes in ninety seconds and suddenly takes fifteen minutes is worth flagging even if fifteen minutes would be unremarkable for a different, larger catalog elsewhere.

What I am building

This is the problem I have been working on solving, on evenings and weekends for a while now. It is called Watchtower Commerce, a monitoring platform built specifically for Magento and Adobe Commerce internals rather than a generic APM with a Magento label stuck on it.

It uses a lightweight connector installed on the store, built with a privacy first approach so store data does not need to leave the merchant's infrastructure to be useful. The dashboard surfaces the vitals that actually matter for this platform, and alerting is based on learned baselines rather than fixed thresholds.

It is close to ready, still in testing and polishing. If you run or work with Magento stores and any of this sounds familiar, I would like to hear from you, and I am looking for a few beta testers once it is ready.

Give it a go at https://watchtower-commerce.com

Happy to talk through any of the technical decisions in the comments, particularly around the baseline learning approach or the privacy architecture of the connector.