1

Rebooting a production server may seem like a routine task, especially when troubleshooting performance issues, applying updates, or recovering from a service failure. However, a reboot can erase valuable information about what happened immediately before the system went down. Once the server restarts, volatile data may disappear, processes may terminate, and temporary diagnostic information can become difficult or impossible to recover.

For that reason, systems engineers should collect the right logs and diagnostic information before rebooting a production server. Good pre-reboot data can turn a mysterious outage into an identifiable root cause.

Here are the most important logs and system details to capture.

1. System Logs

Start with the operating system’s primary system logs. These often contain information about kernel errors, service failures, hardware problems, authentication events, and other system-level activity.

On Linux systems, depending on the distribution and logging configuration, useful sources may include:

• /var/log/syslog
• /var/log/messages
• /var/log/kern.log
• journalctl output

For systems using systemd, engineers should pay particular attention to the current boot’s journal entries and recent errors. Commands such as journalctl -p err can help identify high-priority events.

On Windows Server, collect relevant Windows Event Logs, especially:

• System
• Application
• Security
• Setup

Look for warnings and errors immediately preceding the incident rather than collecting only the latest entries.

2. Application Logs

Operating-system logs rarely tell the complete story. If the server hosts an application, inspect the application’s own logs before rebooting.

Application logs may reveal:

• Crashes and exceptions
• Database connection failures
• Authentication problems
• Request timeouts
• Configuration errors
• Memory-related failures
• Unusual traffic or request patterns

Record the relevant time period around the incident. If possible, preserve both normal and abnormal entries so engineers can compare what changed.

For distributed applications, also collect logs from related services. A problem appearing on one server may actually originate from another component.

3. Web Server and Reverse Proxy Logs

For servers running applications behind Nginx, Apache, IIS, or another web server, collect access and error logs.

Access logs can show whether traffic suddenly increased, while error logs may reveal upstream failures, connection problems, or configuration issues.

Useful information includes:

• HTTP status codes
• Request volume
• Response times
• Client connection errors
• Upstream connection failures
• Repeated requests from particular sources

If the server experienced a sudden spike in traffic, these logs can provide important evidence after the reboot.

4. Database and Storage Logs

If the server runs a database, database logs should be collected before restarting it.

Look for:

• Connection failures
• Long-running queries
• Deadlocks
• Replication errors
• Transaction failures
• Recovery messages
• Storage-related warnings

Storage information is equally important. Check for filesystem errors, disk failures, I/O errors, and capacity problems.

A server that appears to have a software problem may actually be experiencing disk latency or filesystem corruption.

5. Authentication and Security Logs

Authentication logs can help determine whether unexpected login activity, repeated authentication failures, or privilege-related events occurred before the problem.

On Linux, authentication information may be found in sources such as auth.log or secure, depending on the distribution.

On Windows, review relevant Security Event Logs.

If there is any indication of suspicious activity, preserve the logs carefully before rebooting. Avoid modifying or deleting evidence unnecessarily.

6. Resource Utilization Data

Logs aren’t the only information worth collecting. Capture the server’s current resource state while the problem is still occurring.

At minimum, record:

• CPU utilization
• Memory usage
• Swap usage
• Disk utilization
• Disk I/O
• Network traffic
• Process list
• Load average
• Open connections

This information can be particularly valuable when troubleshooting intermittent performance problems.

For example, a process consuming 100% CPU may disappear during a reboot. Without a snapshot of the running processes, engineers may lose an important clue.

7. Process and Service Information

Before restarting, record which processes and services are running and whether any are failing.

On Linux, useful information may include process lists, service status, and recently failed units. On Windows, capture the status of important services and running processes.

Pay attention to services that have repeatedly restarted or entered a failed state.

If a service is responsible for the incident, its state immediately before rebooting may help engineers understand why the problem occurred.

8. Kernel, Hardware, and Crash Information

Hardware and kernel-level problems require special attention.

Check for:

• Kernel errors
• Out-of-memory events
• CPU errors
• Disk or controller errors
• Network interface errors
• Hardware warnings
• Kernel panics
• Previous crash information

On Linux, kernel messages can often be examined with tools such as dmesg or through the system journal.

If the server experienced an out-of-memory condition, capture the relevant kernel messages before rebooting whenever possible.

9. Configuration and Recent Changes

Logs explain what happened, but configuration history can help explain why.

Before rebooting, document recent changes such as:

• Software deployments
• Configuration modifications
• Package updates
• Firewall changes
• Certificate replacements
• Database changes
• Infrastructure changes
• Scheduled jobs

Compare the incident timeline with the change timeline. A failure that begins immediately after a configuration or software change deserves particular investigation.

10. Preserve the Evidence

Collecting logs is only useful if the information remains available after the reboot.

Save important logs to a safe location, preferably outside the affected server. Include timestamps, host information, and the time window covered by the collection.

Avoid simply copying enormous log directories without context. A focused collection containing relevant errors, application logs, system information, and resource snapshots is often more useful.

For critical incidents, consider creating a forensic or diagnostic snapshot according to your organization’s incident-response procedures.

A Practical Pre-Reboot Checklist

Before restarting a production server, verify that you have captured:

• System and kernel logs
• Application logs
• Web server logs
• Database logs
• Authentication and security events
• CPU, memory, disk, and network statistics
• Running processes and services
• Hardware and filesystem errors
• Recent configuration and deployment changes
• Relevant monitoring and alert information

Also record when the problem started, what symptoms were observed, what troubleshooting steps were already attempted, and why the reboot is necessary.

Conclusion

A production reboot should not be treated as simply pressing a restart button. It is also a potential loss of diagnostic evidence.

Collecting system, application, database, security, hardware, and performance information before the reboot gives engineers a much better chance of identifying the underlying problem. Even a few minutes spent gathering evidence can save hours of troubleshooting later.