Production monitoring for small Laravel shops is either too much or too little.
The small team running a handful of Laravel apps sits in an awkward gap. On one side are the enterprise observability suites — powerful, pricey, and calibrated for a fleet you do not yet have. On the other side are ad-hoc cron jobs and a Slack channel full of curl errors that nobody reads on Sunday. What was missing, for the two-developer agency with six sites in production, was a single dashboard that watched uptime, SSL, exceptions, and server health across all of them — and that one could install with a Composer require and a migration.
The target was a small, honest tool: one Filament panel, many apps, and a notification that arrives before the client calls.
A Filament plugin for the dashboard, a companion package for the metrics, a desktop app for the debugger.
MoonGuard was a Filament plugin — installed into a Laravel app, it gave the operator a panel for registering sites, scheduling checks, and reading incidents. Uptime and SSL probes ran on a cron; exceptions and server metrics were reported in by the monitored apps themselves. Notifications were pluggable, with email and Slack shipped out of the box. The plugin owned the schema, the UI, and the alerting; the monitored apps owned only the small act of reporting.
The reporting side lived in Larvis, a lightweight companion package installed into each monitored Laravel app. Larvis forwarded exceptions and server telemetry — CPU load, RAM usage, disk space — to the MoonGuard host over HTTP, and spoke the same protocol that Krater, a cross-platform desktop app, used for local debugging. Three pieces, one vocabulary: the Filament plugin as the panopticon, Larvis as the sensor, Krater as the developer's local lens on the same data.
The fourth piece was the one that surprised people. The package was accompanied by a free book — MoonGuard: The Software Creator's Journey — that documented the end-to-end process of conceiving, building, and publishing a Filament plugin, with code examples drawn directly from the repository. The package and the book were written in parallel; each kept the other honest.
Shipped, open-sourced, and eventually set down.
MoonGuard shipped as taecontrol/moonguard on Packagist and as an open
repository under MIT. It watched multiple Laravel apps from a single
Filament panel, probed uptime and SSL on a schedule, ingested
exceptions and server metrics over Larvis, and notified by email or
Slack when thresholds tripped. The active release arc was narrow and
dense: v1.0.9 added Slack integration in November 2023, v1.1.0
followed two weeks later with maintenance-mode indicators and
automatic exception cleanup, and v1.2.0 landed full server monitoring
— CPU load, RAM, disk — in February 2024, the same window in which
Krater grew an OpenAI-backed query assistant and split into a free
and Pro tier. The code is still where it was — the repository remains
public and installable, and the blog at blog.moonguard.dev stays
online as an archive of the build — but the marketing site, the docs
site, and the book at moonguard.dev have been taken down along with
the domain.
The more interesting outcome was the one that was never in the product spec: the book turned the repository into a teaching artifact. People who installed the plugin read the book; people who read the book installed the plugin. The code and the prose reinforced each other in a way that pure marketing copy never does — and that, in the end, is the part of the project I am proudest of.
Writing the book while writing the package was the decision that paid.
Three choices still feel right. First, committing to Filament as the host surface. The plugin did not try to be a standalone SaaS; it was a panel inside the operator's own Laravel app. Installation collapsed to a Composer require and a migration, and the UI inherited everything Filament already knew how to do. The leverage, for a small team, was substantial.
Second, splitting the system into three packages rather than one. MoonGuard owned the host and the UI, Larvis owned the reporting agent, Krater owned the local developer experience. Each had its own release cadence, its own scope, and its own README. The seams showed up as work — a shared protocol, three repos to keep synchronised — but the boundaries kept each piece small enough to reason about.
Third, writing the book in parallel with the code. Every chapter drafted against an unwritten feature surfaced a rough edge; every refactor that made the chapter easier to write made the package easier to use. It is the closest I have come to documentation-driven development actually working.
What I would do differently is the release cadence and, with it, the quiet middle period that turned into the end. Between November 2023 and February 2024 the project shipped four meaningful releases in a row; after v1.2.x the tempo collapsed, and the package sat dormant while other Taecontrol priorities took the room and the open issues and PRs accumulated in the gap. A monitoring package that asks users to trust it in production cannot afford a silent year; by the time we might have come back to it, the site was already down. The repository stays up as a record — and the book, if it finds a new home, will stay with it.