Feature Request: Add php artisan logs:clear to prevent log accumulation in long-lived systems

[noejunior792]

Context

I maintain and oversee more than 20 Laravel-based systems running in production environments, active continuously since 2021. Each system handles over 1,000 users daily. Over time, without proper log rotation in place, the default storage/logs/laravel.log files have accumulated over 5TB of raw log data across projects.

Even though I have access to a 100TB server infrastructure, this behavior leads to real problems:

• Sluggish file I/O, affecting performance on read/write operations
• Difficulties with backups, file corruption, or timeout issues
• Systems crashing due to "disk full" errors on auto-deployment or logging spikes
• Massive logs make debugging slower, or even impossible to load in some editors
• Lack of a simple cleanup mechanism during maintenance workflows

The Problem

Laravel's current default uses the single channel unless configured otherwise. While the daily driver exists and is a better practice, many production systems are shipped without log rotation awareness — especially in long-lived deployments across multiple teams, such as in government, education, or telecom infrastructures.

Today, if you want to delete old logs, you must manually write custom commands or scripts to clean the storage/logs/ directory.

Proposed Solution

Add a built-in Artisan command:

php artisan logs:clear

Behavior:
Delete all .log and .log.* files under storage/logs

Optional flags:

--dry-run → list what would be deleted

--keep-days=30 → retain logs from the last 30 days only

--path=custom/path → support logs in different locations

This would match other convenience commands in Laravel like cache:clear, queue:flush, etc., and could be easily extended by developers.

Why This Matters
Laravel is used in long-term infrastructures where developers may rotate, and deployment scripts may stay unchanged for years.

logs:clear improves DX (Developer Experience) and server hygiene with zero risk.

Prevents catastrophic server outages caused by forgotten laravel.log growth (especially in debug mode).

Reduces reliance on external solutions when Laravel could handle this natively.

Final Notes
I’m happy to contribute a PR if the team is open to including this in core. Otherwise, I'd suggest at least documenting best practices for log rotation more explicitly in the logging documentation.

Let me know your thoughts!

[macropay-solutions]

If you are in a position to depend on file logging like you describe and you don't have a devops team to solve this for you using file beat for example or not using files at all but stdout etc., then the fastest solution would be for you to add that command in your projects.

Also you should not delete the files in production but move them in archive and then delete them from the archive after some months or years and by doing this, it would make the laravel built-in delete command overhead for production usage and just usable for local development.

[noejunior792]

Thanks for your reply — you’re absolutely right that in ideal DevOps environments, logs should go to stdout and be piped via Filebeat or other logging infrastructures.

However, Laravel powers a vast number of systems globally that don't run inside containers, don't have centralized logging, and don't have DevOps teams. This includes thousands of education systems, health records, telecom backends, and public administration services — especially in developing markets.

In those environments, logs grow in storage/logs over years, silently filling up disks, crashing systems, or making backups impossible.

I'm not advocating for unsafe deletion in regulated environments — I'm advocating for a safe and optional command that empowers smaller teams to maintain healthy deployments.

Just like we have php artisan cache:clear (which would be dangerous in production if misused), logs:clear could come with safeguards or confirmation prompts, and still be a life-saver for many setups.

Let’s not assume every Laravel user has a Kubernetes cluster and centralized logging. Many don’t — and Laravel’s elegance comes from also serving those use cases with dignity.

[macropay-solutions]

We would create a cron job that would clean up older than X time logs and we would set the logging channel as daily in this situation. So that command that removes the logs would be better suited for this case to avoid accidental deletions in prod.

--keep-days=30 → retain logs from the last 30 days only

So this optional would be mandatory.

[noejunior792]

Thank you for the thoughtful response — I completely agree with your point. In fact, my intention was never to encourage unsafe deletions in production environments.

I work in environments where many Laravel systems have been running continuously since 2021, including government platforms, schools, and enterprise back offices in Africa, without DevOps teams or centralized logging stacks like Filebeat or ELK. Over time, some of these systems accumulated over 5TB of logs in storage/logs, causing real production issues — failed backups, full disk errors, and crashes on auto-deploys.

That said, I fully support the idea of making --keep-days mandatory or defaulted to a safe value like 30 days, especially when in production.

I'm happy to adjust the proposal as follows:
logs:clear will require --keep-days in production or fallback to a default of 30 days

It will prompt confirmation or block full deletions unless --force is explicitly passed

It will also support --dry-run for safe previewing and optionally --path for flexible locations

This keeps things safe, while still giving smaller teams a much-needed tool for log hygiene — without needing DevOps, Filebeat, or Kubernetes.

Let me know if you'd be open to a PR with these safety checks built-in, or if you'd prefer this to be an external package instead. I'm happy to proceed either way!

[macropay-solutions]

@noejunior792 see spatie/laravel-log-cleanup https://spatie.be/docs/laravel-activitylog/v4/basic-usage/cleaning-up-the-log

[noejunior792]

Nice, thank you!.