@mteu · posts

Notice Before Your Client Does — Exposing health state of custom components in your TYPO3 instance

2026-07-16T00:00:00+00:00

Some TYPO3 installations have no reliable way to tell whether they're actually working. A scheduler task can stop running. A queue can back up. A third-party API a custom extension depends on can go down. None of that shows up in a standard uptime check, because the page still renders fine — it just quietly stops doing its job.

EXT:monitoring</code> tries to close that gap. It aggregates checks on the components you care about into a single status, exposed through a backend dashboard, an HTTP endpoint, and a CLI command.

The project started from a scheduler that had silently stopped running for several days before anyone noticed. What began as one check for that case grew into a small architecture — authorization, caching, push notifications — as more cases came up that needed the same kind of visibility.

Earlier versions secretly matured into what I was finally ready to release as stable today. So here's a look at what it does and what it gives you.

One status, three ways to read it</a>
</h2>
The extension collects results from monitoring providers — small classes that
each check one thing — and aggregates them into a single status: healthy</code>,
degraded</code>, or unhealthy</code>. That status is available through:</p>

An HTTP endpoint (/monitor/health</code> by default), returning structured
JSON for polling by Nagios, Icinga, Uptime Kuma, or similar tools.</li>
A CLI command, for cron jobs, deploy scripts, or manual checks.</li>
A backend dashboard, showing the same status with a wee more verbosity inside TYPO3, and</li>
optional push notifications, for setups where nothing polls the endpoint.</li>
</ul>
All three read from the same source, so the dashboard, the endpoint, and any
notification stay consistent.</p>
Response format</a>
</h2>
curl</span> -</span>H</span> "</span>X-TYPO3-MONITORING-AUTH: <token></span>"</span> https://example.com/monitor/health</span></span></code></pre>{</span></span>
    "</span>status</span>"</span>:</span> "</span>healthy</span>"</span>,</span></span>
    "</span>services</span>"</span>:</span> {</span></span>
        "</span>Scheduler</span>"</span>:</span> {</span></span>
            "</span>status</span>"</span>:</span> "</span>healthy</span>"</span>,</span></span>
            "</span>subResults</span>"</span>:</span> {</span></span>
                "</span>Scheduler Execution</span>"</span>:</span> {</span> "</span>status</span>"</span>:</span> "</span>healthy</span>"</span> }</span>,</span></span>
                "</span>Overdue Tasks</span>"</span>:</span> {</span> "</span>status</span>"</span>:</span> "</span>healthy</span>"</span> }</span>,</span></span>
                "</span>Failed Tasks</span>"</span>:</span> {</span> "</span>status</span>"</span>:</span> "</span>healthy</span>"</span> }</span></span>
            }</span></span>
        }</span></span>
    }</span></span>
}</span></span></code></pre>
The overall status is the worst status of anything underneath it. unhealthy</code>
returns HTTP 503; healthy</code> and degraded</code> both return 200 — degraded</code> means
"operational, but worth a look," not "down." This distinction lets you page on
outages without paging on minor issues.</p>
Providers</a>
</h2>
A provider is a small, focused class:</p>
final</span> readonly</span> class</span> MyServiceProvider</span> implements</span> MonitoringProvider</span></span>
{</span></span>
    public</span> function</span> getName</span>(</span>)</span>:</span> string</span> {</span> return</span> '</span>MyService</span>'</span>;</span> }</span></span>
    public</span> function</span> getDescription</span>(</span>)</span>:</span> string</span> {</span> return</span> '</span>Monitors my custom service</span>'</span>;</span> }</span></span>
    public</span> function</span> isEnabled</span>(</span>)</span>:</span> bool</span> {</span> return</span> true</span>;</span> }</span></span>
    public</span> function</span> isActive</span>(</span>)</span>:</span> bool</span> {</span> return</span> $</span>this</span>-></span>isEnabled</span>(</span>)</span>;</span> }</span></span>
</span>
    public</span> function</span> execute</span>(</span>)</span>:</span> Result</span></span>
    {</span></span>
        try</span> {</span></span>
            //</span> do the check</span></span>
            return</span> new</span> MonitoringResult</span>(</span>$</span>this</span>-></span>getName</span>(</span>)</span>,</span> Status</span>::</span>Healthy</span>)</span>;</span></span>
        }</span> catch</span> (</span>\</span>Exception</span> $</span>e</span>)</span> {</span></span>
            return</span> new</span> MonitoringResult</span>(</span>$</span>this</span>-></span>getName</span>(</span>)</span>,</span> Status</span>::</span>Unhealthy</span>,</span> $</span>e</span>-></span>getMessage</span>(</span>)</span>)</span>;</span></span>
        }</span></span>
    }</span></span>
}</span></span></code></pre>
Providers are auto-discovered via a PHP attribute on the interface — no
manual registration. A provider can report multiple sub-results under one
name, and expensive checks can implement CacheableMonitoringProvider</code> to
avoid hitting a downstream system on every request.</p>
The extension ships one built-in provider: a Scheduler Provider that checks
the Scheduler as a whole — heartbeat, overdue tasks, and failed tasks
together — rather than trusting individual task status, since a cron job
that stops firing doesn't make any single task "fail."</p>
Authorization</a>
</h2>
Two authorizers ship by default:</p>

Token authorization — an HMAC of the endpoint path, generated with
TYPO3's HashService</code>, sent as a header. The Monitoring → Authorizers</em>
backend module shows the ready-to-use token.</li>
Admin session authorization — anyone logged into the TYPO3 backend as
an administrator can open the endpoint directly.</li>
</ul>
Both are evaluated in priority order. Custom authorizers use the same
attribute-based discovery as providers.</p>
Push notifications</a>
</h2>
For setups without external polling, the extension can push status through
reporters — a built-in EmailReporter</code>, with the same extension point for
Slack, Teams, or other channels. Reporters run on demand, typically from a
scheduler task, via a monitoring:report</code> CLI command.</p>
A small state machine tracks whether an outage is new, a reminder is due, or
the system has recovered, and dispatches to reporters based on their
configured threshold. This produces one notification when something breaks,
periodic reminders while it stays broken, and one "all clear" when it's
fixed, rather than an alert on every cron run.</p>
Command line</a>
</h2>
./vendor/bin/typo3</span> monitoring:run</span></span>
 </span></span>
Checking</span> Monitoring</span> status</span></span>
 ✅</span> Scheduler</span></span>
 ✅</span> Solr</span> Cores</span> (cached</span>)</span></span>
 ✅</span> Redis</span> Cache</span></span>
 🚨</span> FancyExternalApiService</span></span>
 ✅</span> LDAP</span> Import</span></span>
 ✅</span> SSO</span> Roundtrip</span></span>
Monitoring</span> status:</span> FAILED</span></span></code></pre>
Standard exit codes (0</code>/1</code>/2</code>) make it straightforward to wire into deploy
pipelines or health-gate scripts.</p>
Getting started</a>
</h2>
composer</span> require</span> mteu/typo3-monitoring</span></span></code></pre>#</span> config/system/settings.php</span></span>
return</span> [</span></span>
    '</span>EXTENSIONS</span>'</span> =></span> [</span></span>
        '</span>monitoring</span>'</span> =></span> [</span></span>
            '</span>api</span>'</span> =></span> [</span></span>
                '</span>endpoint</span>'</span> =></span> '</span>/monitor/health</span>'</span>,</span></span>
                '</span>enforceHttps</span>'</span> =></span> true</span>,</span></span>
            ]</span>,</span></span>
            '</span>authorizer</span>'</span> =></span> [</span></span>
                '</span>mteu\Monitoring\Authorization\TokenAuthorizer</span>'</span> =></span> [</span></span>
                    '</span>enabled</span>'</span> =></span> true</span>,</span></span>
                    '</span>secret</span>'</span> =></span> '</span>your-secure-secret</span>'</span>,</span></span>
                    '</span>authHeaderName</span>'</span> =></span> '</span>X-TYPO3-MONITORING-AUTH</span>'</span>,</span></span>
                ]</span>,</span></span>
            ]</span>,</span></span>
        ]</span>,</span></span>
    ]</span>,</span></span>
]</span>;</span></span></code></pre>
That's enough for a working endpoint. From there, the extension point is
open: write a provider for whatever a project depends on — a search index,
an external api fetch,a payment gateway, a queue, a filesystem mount —
and it slots into the same status, dashboard, and alerting path as everything else.</p>
MonitoringProvider</code>, Authorizer</code>, and Reporter</code> are the whole surface area
of the package. They've been in use in production for about a year, and the
interfaces are now considered stable.</p>
The first stable version of EXT:monitoring</code> was release today. It supports TYPO3 v13 and v14 LTS. Full documentation with advanced examples is available on GitHub: mteu/typo3-monitoring</code></a>.</p>

Type-Safe Extension Configuration in TYPO3 2025-11-25T00:00:00+00:00 If you've spent any time building TYPO3 extensions, you've almost certainly bumped into the same frustration: extension configuration values are stored as strings. All of them. When a site administrator sets maxItems</code> to 25</code> in the backend, your extension receives the string "25"</code>. Need a boolean? You get "1"</code> or "0"</code>. But the string problem is only half of it. Nothing stops a development team from overriding extension configuration values directly in config/system/additional.php</code> — or anywhere else that writes into $GLOBALS['TYPO3_CONF_VARS']</code>. When that happens, all bets are off. That maxItems</code> value could now be an actual int</code>, a bool</code>, null</code>, or something else entirely, depending on who wrote the override and when. Your extension is suddenly dealing with a mixed-type runtime reality it never agreed to. The usual workarounds — custom wrapper classes, on-the-fly casting, is_*</code> guards scattered across your codebase — are repetitive, error-prone, and still don't protect you from unexpected types sneaking in through overrides. That's why I choose to offer a cleaner way to access extension configuration. So here's me shamelessly advertising the TYPO3 extension Typed Extension Configuration v1.0 release: EXT:typed_extconf</code></a> provides a somewhat type-safe extension configuration layer for TYPO3. You define your configuration as a plain PHP class with typed constructor parameters and a couple of attributes — the library handles reading, converting, and validating everything automagically: #[ExtensionConfig(extensionKey: 'my_extension')] final readonly class MyExtensionConfig { public function __construct( #[ExtConfProperty] public int $maxItems = 10, #[ExtConfProperty] public bool $enableFeature = false, #[ExtConfProperty(path: 'api.endpoint')] public string $apiEndpoint = '/api/v1', ) {} }</code></pre> Then just type-hint the configuration class in your constructor — TYPO3's DI container takes care of the rest: final class Foo { public function __construct( private readonly MyExtensionConfig $config, ) {} public function doSomething(): void { $max = $this->config->maxItems; // int $enabled = $this->config->enableFeature; // bool $url = $this->config->apiEndpoint; // string } }</code></pre> No casting, no manual parsing, no surprises — just clean, typed PHP. Features</a> </h2> Attribute-Based Schema: Define your configuration contract with #[ExtensionConfig]</code> and #[ExtConfProperty]</code>. Declarative, readable, and IDE-friendly.</li> Path Mapping: Map nested configuration keys with ease, e.g. api.endpoint</code>.</li> Configuration Generation: Run ./vendor/bin/typo3 typed-extconf:generate</code> to scaffold a configuration class from your existing ext_conf_template.txt</code>.</li> Dependency Injection: Configuration classes are auto-registered as services.</li> </ul> Under the hood, the library is powered by the amazing CuyZ/Valinor</a> for type-safe object mapping and validation — ensuring invalid or unexpected values are caught early, not deep inside your business logic. The extension supports TYPO3 v12, v13, and v14 LTS. Full documentation, advanced examples, and a developer guide are available on GitHub</a>. TYPO3 Developer Days 2025 2025-08-10T00:00:00+00:00 I've just returned from Karlsruhe to resume my summer vacation after having attended this year's TYPO3 Developer Days</a>, and what an incredible experience it was yet again! From exploring TYPO3's development future to understanding how emerging technologies will reshape content management, the sessions provided a vision of where we're heading. It wasn't just about current best practices, but about preparing for the next generation of web development challenges and opportunities. What struck me most was how the community has evolved - I might be wrong but the conference felt noticeably younger and more diverse, with significantly more women participating than in previous years. This shift is fantastic to see and brings fresh perspectives and energy to our ecosystem. The true spirit of open source was alive and thriving. People genuinely inspired each other to share knowledge, contribute code, and push the boundaries of what's possible with TYPO3 and PHP. The contribution night and several water-cooler discussions embodied the very best of community-driven development, with core developers being incredibly approachable and eager to share their insights as well as listen to new ideas. While many attendees represented agencies and commercial interests, what shone through was the incredible amount of passion and volunteer spirit driving this community. People dedicate countless hours not for profit, but for the love of building something meaningful together. The motivation for this volunteer work can be challenging to sustain. Often, you feel like you're working in isolation, questioning whether your contributions truly matter. But events like T3DD25</a> or the many barcamps throughout the year remind you exactly why you do this work - you're not alone. You're part of a global community of people who believe in the power of open source to create something greater than the sum of its parts. A heartfelt thank you to the organizers who made this event possible, to the sponsors who give back to the open source community that supports their businesses, and to every single participant who took time from their lives to be there. Without dedicated developers, contributors, and community members like these, events like this wouldn't exist - and neither would the open source ecosystem we all depend on. I genuinely hope to return next year for T3DD26.

@mteu · posts

Notice Before Your Client Does — Exposing health state of custom components in your TYPO3 instance

Authorization</a> </h2> Two authorizers ship by default:</p> Token authorization — an HMAC of the endpoint path, generated with TYPO3's HashService</code>, sent as a header. The Monitoring → Authorizers</em> backend module shows the ready-to-use token.</li>

Type-Safe Extension Configuration in TYPO3

TYPO3 Developer Days 2025