CoreWatch: A Laravel-Native Dashboard for Server Health and Operations

Most Laravel applications eventually need a way to answer a few operational questions: Is the server under pressure? Is the scheduler still running? What is filling the logs? Did a queue or cache operation fail?

There are excellent tools for answering those questions, but they often mean setting up another service, dashboard, or agent. For smaller deployments, I wanted a more direct option: a Laravel package that puts a useful operational view inside the application that already runs the project.

That idea became CoreWatch.

What CoreWatch does

CoreWatch adds a dashboard at /corewatch and a set of Laravel-native tools for:

• CPU, memory, disk, uptime, and host information
• Application checks for the database, cache, queue, and environment
• Recent log entries, read backwards in chunks
• Configured service actions, such as restarting Laravel queue workers
• Health checks and optional Slack or Telegram alerts
• Health and Prometheus endpoints for external monitoring

The package supports PHP 8.2 and Laravel 11, 12, and 13. Its exact operating-system metrics depend on the host: on Linux it reads /proc where available and uses command-based fallbacks for some values. It is not intended to replace a full observability stack for a high-scale system.

Keep it inside the Laravel app

Install the package with Composer and publish its configuration:

composer require hamzi/corewatch
php artisan corewatch:install

The dashboard is available at /corewatch. CoreWatch also exposes its functionality through a facade, so application code can use metrics without making an HTTP request to its own server:

use Hamzi\CoreWatch\Facades\CoreWatch;

$cpu = CoreWatch::cpu();
$ram = CoreWatch::ram();
$disk = CoreWatch::disk();
$health = CoreWatch::health();

That makes the package useful beyond its built-in page. For example, an application can place a small health summary inside an existing admin panel or use the health result in a custom command.

Avoid loading an entire log file

One implementation detail I cared about was log inspection. A naive log viewer reads a file into memory and then slices out the latest lines. That approach becomes unreliable as the file grows.

CoreWatch seeks to the end of the configured file and reads backwards in 64 KB chunks until it has enough matching lines for the requested page. Memory use therefore does not grow with the total size of the log file. It still depends on the requested page and the size of individual log entries, so this is bounded reading rather than a claim of constant memory in every possible case.

Log sources are selected by configured keys. A request does not get to provide an arbitrary filesystem path. That lets an application choose which logs the dashboard can expose.

Operational controls need boundaries

A dashboard that can run server commands is a security feature only if its limits are clear. CoreWatch accepts a service key, looks it up in package configuration, and runs only the corresponding configured command. The request cannot submit a shell command directly. Potentially disruptive shell actions are disabled by default.

The dashboard and API use Laravel's auth middleware by default. For production, authentication is only the first step: an application should also restrict access to administrators using a gate or its own authorization middleware. For example, an app with an isAdmin() method could configure a gate in its service provider:

config([
    'corewatch.gate' => fn ($request) => $request->user()?->isAdmin() === true,
]);

Health and Prometheus endpoints are private by default as well. They can be exposed deliberately for an external monitor, but that choice should be paired with suitable network or proxy restrictions. Operational endpoints can reveal useful details about an application and its host.

A layered package structure

The code separates Laravel's HTTP and console entry points from the work they trigger:

src/
├── Contracts/       Interfaces for metrics, logs, and notifications
├── Domain/          Health rules and diagnostic logic
├── Application/     Actions that coordinate use cases
├── Infrastructure/  Host metrics, repositories, shell, notifications
├── Http/            Controllers, middleware, and requests
└── Console/         Artisan commands

This is not architecture for architecture's sake. It gives the package places to isolate system access, health decisions, and Laravel integration. It also means that tests can exercise actions and domain rules without relying on a live server for every scenario.

The package includes commands for scheduled health checks and scheduler heartbeats:

use Illuminate\Support\Facades\Schedule;

Schedule::command('corewatch:heartbeat')->everyMinute();
Schedule::command('corewatch:check-health')->everyFiveMinutes();

It also includes corewatch:doctor to inspect common environment and integration issues, plus corewatch:test-alert to check alert delivery.

Where the project is going

CoreWatch is a practical tool for Laravel teams that want basic operational visibility close to the application. It favors an installable package, Laravel's existing scheduler and authorization mechanisms, and a small number of explicit integration points.

It does not collect historical time series or replace dedicated monitoring systems. For that, use a proper metrics store and alerting stack. CoreWatch is most useful for the everyday checks that otherwise require opening several tools or logging into a server.

The project is open source, and feedback is welcome: hamdyelbatal122/CoreWatch on GitHub.

If you try it in a Laravel application, I would especially like to hear which operational checks save you the most time and what should be configurable before anything else.