Year‑End Server Checklist: 10 Essential Settings

10 Server Settings You Should Verify Before the Holidays

(To keep the servers running smoothly during the break)

“Is there anything special to check just because it’s the end of the year?”

The short answer is yes.

The servers themselves don’t change, but the people who run them do.

Fewer staff available due to vacations and holidays
Traffic patterns become erratic
The overall tension level drops

That makes the holiday season the most risky time for incidents. This post isn’t a preachy “you must do this” list; it’s a realistic set of checks to keep everything running during the break.

1. Disk Usage and Log Growth

Logs don’t magically stop at the end of the year.

Key items to confirm:

/var/log space usage
Application log rotation settings
Docker container log size (do JSON logs grow indefinitely?)

A full disk can bring a server to a halt without warning. What might have been tolerable during the year can become a critical failure over the holidays.

2. Backup: Does It Restore?

Having a backup file is only half the battle. The real question is:

Can I actually recover from it?

Before the new year, run through these steps at least once:

Verify the most recent backup exists
Quick integrity check of the archive
Restore into a test environment

Don’t let the first task of the new year be “oh, the backup was corrupted.”

3. SSL/TLS Certificate Expiry

The end of the year is a prime time for certificate failures.

Is Let’s Encrypt auto‑renewal actually running?
Are the cron or systemd timers enabled?
Any errors in the recent renewal logs?

Assuming auto‑renewal works is a common trigger for outages.

4. Firewall Rules and Temporary Open Ports

Over a year of operation, temporary changes accumulate:

Ports left open for testing
IPs temporarily whitelisted
Obsolete service ports

These forgotten settings become easy-to-miss security holes. The holidays are a good time to clean them up.

5. SSH Access and Key Management

Attacks during the break often go unnoticed for longer.

Is password login disabled?
Are unused SSH keys removed?
Have keys for former employees or contractors been revoked?
Do admin accounts have the least privilege necessary?

Optimism that “no one cares about our server” is almost always wrong.

6. Silent Failures in Cron/Schedulers

Cron, systemd timers, and other schedulers quietly fail.

Any errors in recent run logs?
Are there long‑standing failing jobs?
Are obsolete jobs still running?

A broken scheduler in December will persist into the new year.

7. Peak, Not Average, Resource Usage

Holiday traffic is more volatile.

Sudden spikes during specific periods
Bot or crawler anomalies
Holiday patterns in particular countries

Monitoring should focus on peaks, not averages:

CPU and memory peaks
DB connection counts, queue lengths
Concurrent users, session counts

Saying “normally fine” isn’t reassuring during the holidays.

8. Dependent Service Health

Even if your server is healthy, a down dependency can stop the whole service.

Examples:

Redis / Memcached
Message brokers (Kafka, RabbitMQ, SQS, etc.)
External APIs (payment, auth, notifications)
File/ image storage

These services also undergo checks, deployments, and maintenance during the year. Verify their status pages and alert channels.

9. Test That Error Alerts Actually Arrive

Having an alert system is one thing; receiving the alert is another.

Trigger a test error
Verify email/Slack/Webhook notifications
Ensure severity filters aren’t silencing them

Often the biggest holiday incident is that no one noticed it.

10. One‑Page “Where to Start When Something Breaks” Document

Documentation is the final, non‑configuration item.

List of critical services
Server/container access methods
Log locations (nginx, app, DB, queue, etc.)
Restart/rollback procedures
Emergency response order

Having this page can shift incident response from hard mode to normal mode.