Laravel Maintenance Checklist: What a Good Plan Includes

A good Laravel maintenance plan covers six things on a fixed rhythm: security updates, dependency updates, backups that are actually restored and tested, monitoring of errors, queues and the scheduler, performance and database housekeeping, and a yearly plan for Laravel and PHP upgrades. If you can't say who does each of these and how often, your app is not really being maintained, it's just running.

We wrote about why Laravel maintenance and support matter a while ago. This post is the practical part: a checklist by frequency that you can hand to your in-house developer or use to compare maintenance providers.

What should a Laravel maintenance plan include?

Here is the whole plan on one page. The sections below explain each line.

Small apps can merge weekly and monthly checks. Apps that take payments or hold personal data should not skip any of them.

Which Laravel and PHP versions still get security fixes?

Everything in a maintenance plan depends on staying on supported versions, so start here.

According to the Laravel support policy, every Laravel release gets bug fixes for 18 months and security fixes for 2 years:

So as of November 2026, Laravel 11 and older no longer get security fixes, and Laravel 12 only gets security fixes until February 2027. Laravel 13 requires PHP 8.3 or newer.

PHP has its own clock. Each branch gets two years of active support and two more years of security fixes (php.net):

If your server still runs PHP 8.2, it stops getting security fixes at the end of this year. Moving to a newer PHP often means moving Laravel too; that is a project of its own, and our Laravel upgrade and migration page explains how we approach it.

What should happen every week?

Weekly work is mostly reading signals and acting on anything unusual.

• New exceptions. Look at errors that are new or growing, not the same old noise. Fix the ones users actually hit.
• Failed queue jobs. Emails, invoices, imports and webhooks usually run in queues. A failed job is often a customer who never got something. Laravel lists them with php artisan queue:failed, and they can be retried with php artisan queue:retry once the cause is fixed (queue docs).
• Scheduler runs. Scheduled tasks fail silently when the cron entry disappears after a server change. php artisan schedule:list shows what is scheduled and when it runs next, and tasks can ping a monitoring URL or email their output when they fail (pingOnFailure, emailOutputOnFailure, see the scheduling docs).
• Uptime and response time alerts. Check what fired and why.
• Backup reports. Confirm last night's backup ran and landed off the server.

Which monitoring tools should you use?

Laravel has three first-party options, and they do different jobs:

• Laravel Nightwatch is a hosted monitoring service built for Laravel. It tracks requests, queries, jobs, mail, notifications, scheduled tasks and exceptions, and sends alerts. It is free to get started.
• Laravel Pulse is a free package that adds a dashboard with "at-a-glance insights" into slow requests, slow jobs, slow queries, exceptions and server usage. It stores its data in your own database.
• Laravel Telescope is described by Laravel as a companion to your local development environment. If it is installed in production, make sure access is locked down; the docs warn it can be publicly available if APP_ENV isn't set to production.

Many teams also use a general error tracker and an external uptime checker. The tool matters less than the rule: someone is alerted, and someone is responsible for looking.

What should happen every month?

Security audit and dependency updates

Run Composer's audit, which checks your installed packages against known security advisories and exits with an error when it finds one (Composer docs):

composer audit
composer outdated --direct
npm audit

composer outdated --direct lists the packages your app depends on directly that have newer versions. Apply patch and minor updates monthly, run the test suite, deploy to staging first, then production. Composer also runs the audit automatically after composer update and composer require, unless it was turned off with --no-audit.

Front-end dependencies (Vite, Vue, React and so on) need the same treatment with npm audit.

Server and PHP patches

Apply operating system and PHP patch releases (for example 8.4.x to the next 8.4.x). Restart PHP-FPM and queue workers afterwards. Queue workers are long-running processes and keep running old code until they are restarted with php artisan queue:restart (queue docs).

Restore a backup

A backup you have never restored is a hope, not a backup. Once a month, restore the latest database backup to a separate environment and check that the app starts and the data is recent. If you use Spatie's laravel-backup, its backup:monitor command can warn you when the newest backup is too old or the backups use too much storage. Our older post on backing up a Laravel application covers the setup.

Performance review

Look at the slowest pages, jobs and queries from your monitoring tool. The usual fixes are a missing database index, an N+1 query, or slow work (PDFs, imports, API calls) that should move to a queue. Fix the top two or three each month instead of planning a big performance project once a year.

Logs and database housekeeping

• Make sure log files rotate (Laravel's daily log channel or the server's logrotate) so a disk never fills up.
• Prune old records you don't need: failed jobs (php artisan queue:prune-failed --hours=48), monitoring data, and expired rows in your own tables. Laravel's model pruning deletes them on a schedule; php artisan model:prune --pretend shows how many rows would be removed before you run it for real.
• Check database and disk growth so you can plan for it.

Small improvements

Keep a few hours each month for small fixes and improvements users ask for. This is where a maintenance plan pays for itself: problems are fixed while they are still small.

What should happen every quarter?

• Major package updates. Packages like Livewire, Filament, Inertia or payment SDKs release major versions with breaking changes. Plan them, read the upgrade guides, test properly.
• Access and secrets review. Remove former staff and contractors from servers, the hosting panel, Git, the database and third-party dashboards. Rotate API keys that were shared too widely. Check that APP_DEBUG is false in production.
• SSL certificates and domains. Certificates must renew automatically. This matters more now: the CA/Browser Forum has voted to shorten the maximum lifetime of public TLS certificates in steps, from 398 days to 47 days by March 2029, so manual renewal won't keep up. Check the domain renewal date and DNS too.
• Capacity check. Compare traffic, queue volume and database size with the last quarter.
• Documentation. Update the short document that explains how to deploy, where the backups are, which services the app depends on and who has access. If your developer left tomorrow, this is what the next one needs.

What should happen once a year?

• Version plan. Check the support tables above and decide when to move to the next Laravel and PHP version. Laravel releases a major version roughly every year (release notes), so a yearly upgrade keeps each step small. Skipping several versions turns a short upgrade into a project.
• Disaster recovery drill. Rebuild the app on a fresh server from the repository and the latest backup, and time it. That number is your real recovery time.
• Infrastructure review. Hosting costs, server size, database version, whether managed services would now be cheaper than self-managed ones.
• Roadmap. Agree which improvements are worth doing next year, so maintenance hours aren't spent only on firefighting.

A quick health check you can run today

Your developer can answer most of the questions in this post in a few minutes:

php artisan about
composer audit
php artisan schedule:list
php artisan queue:failed

php artisan about prints the Laravel and PHP versions, the environment, whether debug mode is on, and the cache, queue and mail drivers in use. Compare the versions with the support tables above.

What should you ask a maintenance provider?

Whether you hire an agency or a freelancer, or give the work to an in-house developer, ask these questions before you agree a scope:

1. Which of the weekly, monthly, quarterly and yearly tasks above are included, and which are billed separately?
2. How do you handle urgent security issues and production outages? What response time do you commit to in writing, and during which hours?
3. How do you report what was done each month?
4. Do you test backups by restoring them? How often?
5. Do updates go through a staging environment and automated tests before production?
6. Who has access to our servers and code, and how is access removed when someone leaves your team?
7. Do we own the code, the repository, the hosting accounts and the monitoring accounts?
8. Are major upgrades (for example Laravel 12 to 13) part of the plan, or a separate project?
9. Can you take over an app another team built? What does the first month look like?

Good providers answer these clearly. Vague answers on backups, access and ownership are a warning sign.

What are the signs your Laravel app is under-maintained?

• Nobody knows which Laravel or PHP version is running, or it is past the security-fix dates above.
• composer audit reports advisories that have been there for months.
• Customers report errors before your team sees them.
• Failed jobs pile up, or scheduled emails and reports quietly stopped.
• Backups exist, but nobody has restored one.
• Deployments are manual and only one person knows how to do them.
• Former developers still have server or Git access.
• Pages that used to be fast are now slow, and nobody knows why.

If three or more of these sound familiar, start with an audit: check versions, security advisories, backups and access first, then work through the checklist.

Should maintenance be in-house or outsourced?

An in-house developer knows the business best, but maintenance competes with feature work and usually loses. An agency brings a routine and more than one person who knows the app, but needs a clear scope. Many companies combine both: their developer builds features, and a maintenance partner owns updates, monitoring, backups and upgrades. Our guide on how to hire Laravel developers compares the options in more detail.

CodeBrisk has worked with Laravel since 2015, and some of our maintenance relationships have lasted for years, including a web-based billing platform we have worked on since 2017. If you want someone to take over the checklist above for your app, see our Laravel maintenance and support service, then tell us about your project or contact us.