Software rots even when nobody touches it. Dependencies get vulnerabilities, certificates expire, APIs deprecate, hosts change defaults. Maintenance is a small ongoing cost, and skipping it entirely is how a working project quietly becomes broken.

The monthly half hour

Genuinely enough for a small project.

Update dependencies. Run the audit, apply the security fixes, update the rest in a batch you can revert. Small regular updates are painless; a two-year gap is a project.

Check the error log. Not for outages — for the errors happening quietly that nobody reported.

Check the bill. Usage-based services drift, and a bug can double your costs without anything appearing broken.

Verify a backup restores. Not every month necessarily, but more often than never.

Automate the alarms

You should not be the monitoring system. Set up: an uptime check, error reporting that emails you, a certificate expiry warning, and a billing alert. All have free tiers.

The failure mode you're preventing is the site being down for three days before someone mentions it.

Write down what future-you forgets

Every project has details that live only in your head: which command deploys it, which environment variable is named oddly, why that workaround exists. Six months away and they're gone.

A short MAINTENANCE.md — how to deploy, how to roll back, where the logs are, what the scheduled jobs do — takes twenty minutes and saves an evening.

maintenance-notes.txt
Here's my project: <paste structure and config>

Write me a maintenance document covering:
- How to deploy, and how to roll back.
- Where logs and errors are, and how to reach them.
- Every scheduled job and what it does.
- Every external service, what it's for, and what breaks without it.
- Anything that expires — certificates, tokens, domains — and when.
- The three things most likely to break unattended.

Assume I've forgotten everything about this project.

Decide when to stop

Not every project deserves indefinite maintenance. If nobody uses it and you don't either, shutting it down deliberately — with notice, and with data export for anyone who does — is a legitimate and tidy ending.

An abandoned but still-running project with old dependencies and real user data is the worst of both.

Put the recurring checks in your calendar. Maintenance that depends on remembering is maintenance that doesn't happen.