Python System Administration Tools

Python has earned its reputation as the go-to language for system administrators who want to automate routine tasks, monitor infrastructure, and manage servers efficiently. Its readable syntax, extensive standard library, and powerful third-party ecosystem make it an ideal fit for everything from quick disk-usage checks to full-scale remote deployment pipelines. But Python's real advantage for sysadmins is not just convenience. It is the ability to compose small, testable, well-structured scripts into production-grade automation that replaces fragile shell pipelines with maintainable code.

Whether the job is rotating log files at midnight, provisioning user accounts across a fleet of servers, or alerting on high CPU usage before a production incident spirals out of control, Python has a tool for it. This article walks through the core libraries and patterns that sysadmins rely on every day, starting with what ships in the standard library and moving into the third-party packages that extend Python's reach into remote infrastructure. Along the way, it addresses the real production concerns that separate a quick hack from a reliable automation tool: structured logging, credential management, error handling, and knowing when Python is the right tool and when it is not.

Built-In Modules for Sysadmin Work

Python's standard library ships with several modules that handle fundamental system administration tasks without requiring any additional installation. These are the building blocks that every sysadmin script tends to lean on.

The os Module

The os module is the primary interface between Python and the operating system. It provides functions for navigating the filesystem, managing environment variables, handling file permissions, and working with process information. For a system administrator, it is the foundation of the standard library's system interaction capabilities.

import os

# List all files in a directory
for entry in os.listdir("/var/log"):
    full_path = os.path.join("/var/log", entry)
    if os.path.isfile(full_path):
        size = os.path.getsize(full_path)
        print(f"{entry}: {size / 1024:.1f} KB")

# Read and set environment variables
db_host = os.environ.get("DB_HOST", "localhost")
print(f"Database host: {db_host}")

# Change file permissions
os.chmod("/tmp/deploy.sh", 0o755)

For recursive directory traversal, os.walk() is indispensable. It yields the directory path, subdirectory names, and filenames at each level of the tree, making it straightforward to search for files, calculate directory sizes, or clean up old artifacts.

import os

def find_large_files(root_dir, threshold_mb=100):
    """Find files larger than the given threshold."""
    large_files = []
    for dirpath, dirnames, filenames in os.walk(root_dir):
        for filename in filenames:
            filepath = os.path.join(dirpath, filename)
            try:
                size_mb = os.path.getsize(filepath) / (1024 * 1024)
                if size_mb > threshold_mb:
                    large_files.append((filepath, size_mb))
            except OSError:
                continue
    return sorted(large_files, key=lambda x: x[1], reverse=True)

for path, size in find_large_files("/var/log", threshold_mb=50):
    print(f"{size:.1f} MB  {path}")

The shutil Module

While os handles low-level operations, shutil provides higher-level file and directory operations. It is especially useful for copying files while preserving metadata, moving directories, creating compressed archives, and checking disk usage.

import shutil

# Check disk usage on the root partition
total, used, free = shutil.disk_usage("/")
print(f"Total: {total // (1024**3)} GB")
print(f"Used:  {used // (1024**3)} GB")
print(f"Free:  {free // (1024**3)} GB")
print(f"Usage: {(used / total) * 100:.1f}%")

# Copy a file preserving metadata
shutil.copy2("/etc/nginx/nginx.conf", "/backups/nginx.conf.bak")

# Archive an entire directory
shutil.make_archive("/backups/logs_2026", "gztar", "/var/log")

The subprocess Module

The subprocess module lets Python scripts launch external processes, capture their output, and check their return codes. This is essential for sysadmin work because it bridges the gap between Python logic and the shell commands that administrators already know.

import subprocess

# Run a command and capture its output
result = subprocess.run(
    ["df", "-h", "/"],
    capture_output=True,
    text=True,
    check=True
)
print(result.stdout)

# Create a new system user
def create_user(username):
    try:
        subprocess.run(
            ["sudo", "useradd", "-m", username],
            check=True,
            capture_output=True,
            text=True
        )
        print(f"User '{username}' created successfully.")
    except subprocess.CalledProcessError as e:
        print(f"Failed to create user: {e.stderr}")

pathlib: The Modern Path Interface

Since Python 3.4, the pathlib module has provided an object-oriented interface for filesystem paths that is increasingly considered the preferred approach over string-based os.path operations. The official Python documentation recommends pathlib for new code, and for good reason: it combines path manipulation, file I/O, and directory operations into a single, clean API where paths are objects rather than strings.

For a sysadmin, the practical benefit is code that reads more naturally and composes more safely across operating systems. Instead of scattering os.path.join(), os.path.exists(), and os.path.getsize() calls throughout a script, every operation lives on the Path object itself.

from pathlib import Path

# Navigate the filesystem with operator overloading
log_dir = Path("/var/log")
nginx_log = log_dir / "nginx" / "access.log"

# Check existence and read properties
if nginx_log.exists() and nginx_log.is_file():
    size_mb = nginx_log.stat().st_size / (1024 * 1024)
    print(f"{nginx_log.name}: {size_mb:.1f} MB")

# Recursive glob replaces os.walk for pattern matching
for conf_file in Path("/etc").rglob("*.conf"):
    print(f"Found config: {conf_file}")

Python 3.12 added Path.walk(), a native pathlib equivalent of os.walk(). This means the same recursive directory traversal pattern is now fully available without importing os at all. For sysadmin scripts that need to traverse large directory trees, Path.walk() provides the familiar three-tuple of directory path, subdirectory names, and filenames. The key difference from os.walk() is that dirpath is a Path object rather than a string, which means constructing full paths is as clean as writing dirpath / filename instead of calling os.path.join().

from pathlib import Path
from datetime import datetime, timedelta

def find_stale_files(root, days=30):
    """Find files not modified in the given number of days."""
    cutoff = datetime.now().timestamp() - (days * 86400)
    stale = []
    for dirpath, dirnames, filenames in Path(root).walk():
        # Skip hidden directories
        dirnames[:] = [d for d in dirnames if not d.startswith(".")]
        for filename in filenames:
            filepath = dirpath / filename
            try:
                if filepath.stat().st_mtime < cutoff:
                    stale.append(filepath)
            except OSError:
                continue
    return stale

for old_file in find_stale_files("/tmp", days=7):
    print(f"Stale: {old_file}")

psutil: System Monitoring and Process Management

The psutil library (short for "process and system utilities") is a cross-platform library for retrieving detailed information about running processes and overall system utilization. It covers CPU, memory, disk, network, and sensor data, essentially replacing a whole collection of traditional Unix command-line tools like ps, top, free, netstat, and ifconfig with a single, consistent Python API.

As of early 2026, psutil is at version 6.1.1 for Python 2.7 environments and version 7.2.2 for Python 3.6+ (released January 28, 2026). It supports CPython and PyPy across Linux, macOS, Windows, FreeBSD, OpenBSD, NetBSD, and Sun Solaris. The library is maintained by Giampaolo Rodola and has accumulated nearly 11,000 stars on GitHub, reflecting its central role in the Python system monitoring ecosystem.

psutil is intended for system monitoring, profiling, resource limiting, and process management.

-- Giampaolo Rodola, psutil creator (github.com/giampaolo/psutil)

import psutil

# CPU information
print(f"CPU cores (logical): {psutil.cpu_count()}")
print(f"CPU usage: {psutil.cpu_percent(interval=1)}%")
print(f"CPU frequency: {psutil.cpu_freq().current:.0f} MHz")

# Memory information
mem = psutil.virtual_memory()
print(f"\nTotal RAM: {mem.total / (1024**3):.1f} GB")
print(f"Available: {mem.available / (1024**3):.1f} GB")
print(f"Usage: {mem.percent}%")

# Disk information
for partition in psutil.disk_partitions():
    try:
        usage = psutil.disk_usage(partition.mountpoint)
        print(f"\n{partition.device} mounted at {partition.mountpoint}")
        print(f"  Total: {usage.total / (1024**3):.1f} GB")
        print(f"  Used:  {usage.percent}%")
    except PermissionError:
        continue

Process management is another area where psutil excels. Rather than parsing the output of ps aux with regular expressions, administrators can iterate over running processes using structured Python objects. This eliminates the fragility of text-parsing approaches, which can break when output formatting varies across systems.

import psutil

# Find the top 5 processes by memory usage
processes = []
for proc in psutil.process_iter(["pid", "name", "memory_percent"]):
    try:
        processes.append(proc.info)
    except (psutil.NoSuchProcess, psutil.AccessDenied):
        continue

top_five = sorted(processes, key=lambda p: p["memory_percent"] or 0, reverse=True)[:5]

print("Top 5 processes by memory usage:")
for p in top_five:
    print(f"  PID {p['pid']:>6}  {p['memory_percent']:>5.1f}%  {p['name']}")

Network monitoring is equally straightforward. psutil can report per-interface traffic counters, active connections, and interface addresses, giving administrators a programmatic alternative to netstat and ifconfig.

import psutil

# Network I/O counters
net = psutil.net_io_counters()
print(f"Bytes sent:     {net.bytes_sent / (1024**2):.1f} MB")
print(f"Bytes received: {net.bytes_recv / (1024**2):.1f} MB")

# Active network connections
connections = psutil.net_connections(kind="inet")
listening = [c for c in connections if c.status == "LISTEN"]
print(f"\nListening ports: {len(listening)}")
for conn in listening[:5]:
    print(f"  {conn.laddr.ip}:{conn.laddr.port}")

One notable improvement in psutil 7.x is that Process.wait() now uses pidfd_open() with poll() on Linux (kernel 5.3+, Python 3.9+) and kqueue() on macOS/BSD, eliminating the old busy-loop polling pattern. This means scripts that wait for child processes to exit are now more efficient and more responsive.

Fabric: Remote Server Automation Over SSH

When administration tasks extend beyond the local machine to one or more remote servers, Fabric is the library that fills the gap. Fabric is a high-level Python library designed for executing shell commands remotely over SSH. It builds on top of two lower-level libraries: Invoke for subprocess execution and command-line features, and Paramiko for the SSH protocol implementation.

The current stable release is Fabric 3.2.2, which requires Python 2.7 or 3.4+ according to the official documentation. Unlike configuration management tools such as Ansible, Puppet, or Chef, Fabric does not require any agent software to be installed on the remote machines. The only requirement on the target servers is a standard OpenSSH server, which makes it a natural choice for administrators who need quick, scriptable access to remote machines without the overhead of a full orchestration platform.

from fabric import Connection

# Connect to a remote server and run a command
result = Connection("webserver01.example.com").run("uname -s", hide=True)
print(f"Remote OS: {result.stdout.strip()}")

# Check disk space on a remote host
def check_remote_disk(host):
    conn = Connection(host)
    result = conn.run("df -h /", hide=True)
    print(f"--- {host} ---")
    print(result.stdout)

For tasks that need to run across multiple servers, Fabric provides the SerialGroup and ThreadingGroup classes. These let administrators define a group of hosts and execute the same command on all of them in a single call. SerialGroup runs commands one host at a time, while ThreadingGroup runs them in parallel, which can dramatically reduce execution time across large fleets.

from fabric import SerialGroup, ThreadingGroup

# Run a command across multiple servers (sequentially)
hosts = SerialGroup("web1.example.com", "web2.example.com", "web3.example.com")
results = hosts.run("uptime", hide=True)

for connection, result in results.items():
    print(f"{connection.host}: {result.stdout.strip()}")

# Run in parallel for faster execution across many hosts
parallel_hosts = ThreadingGroup("web1.example.com", "web2.example.com", "web3.example.com")
parallel_results = parallel_hosts.run("free -m | head -2", hide=True)

Fabric also supports file transfers and sudo operations, covering the common sysadmin workflows of deploying configuration files and restarting services.

from fabric import Connection

def deploy_config(host, local_path, remote_path):
    """Upload a config file and restart the service."""
    conn = Connection(host)

    # Upload to a temp location first
    tmp_path = f"/tmp/{local_path.split('/')[-1]}"
    conn.put(local_path, tmp_path)

    # Move to final location with sudo
    conn.sudo(f"mv {tmp_path} {remote_path}")
    conn.sudo("systemctl restart nginx")
    print(f"Deployed {local_path} to {host}:{remote_path}")

deploy_config(
    "web1.example.com",
    "./nginx.conf",
    "/etc/nginx/nginx.conf"
)

Building a Production Monitoring Script

The real power of these tools emerges when they are combined into practical scripts. The following example brings together psutil, shutil, subprocess, and proper logging into a system health check that an administrator could run on a cron schedule or integrate into a larger monitoring pipeline. Unlike a quick-and-dirty script, this version includes structured logging, threshold-based alerting, and exception handling that will not silently swallow failures.

import psutil
import shutil
import subprocess
import socket
import logging
from datetime import datetime
from pathlib import Path

# Configure structured logging
logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s [%(levelname)s] %(name)s: %(message)s",
    handlers=[
        logging.FileHandler("/var/log/health_check.log"),
        logging.StreamHandler()
    ]
)
logger = logging.getLogger("health_check")

# Configurable thresholds
THRESHOLDS = {
    "cpu_warning": 80,
    "cpu_critical": 95,
    "memory_warning": 80,
    "memory_critical": 90,
    "disk_warning": 80,
    "disk_critical": 90,
}

def system_health_report():
    """Generate a comprehensive system health report."""
    report = []
    alerts = []
    now = datetime.now().strftime("%Y-%m-%d %H:%M:%S")
    hostname = socket.gethostname()
    report.append(f"System Health Report - {hostname}")
    report.append(f"Generated: {now}")
    report.append("=" * 50)

    # CPU check
    cpu_percent = psutil.cpu_percent(interval=2)
    load_avg = psutil.getloadavg()
    report.append(f"\nCPU Usage: {cpu_percent}%")
    report.append(f"Load Average (1/5/15 min): {load_avg[0]:.2f} / {load_avg[1]:.2f} / {load_avg[2]:.2f}")
    if cpu_percent > THRESHOLDS["cpu_critical"]:
        alerts.append(f"CRITICAL: CPU at {cpu_percent}%")
        logger.critical("CPU usage at %s%% on %s", cpu_percent, hostname)
    elif cpu_percent > THRESHOLDS["cpu_warning"]:
        alerts.append(f"WARNING: CPU at {cpu_percent}%")
        logger.warning("CPU usage at %s%% on %s", cpu_percent, hostname)

    # Memory check
    mem = psutil.virtual_memory()
    report.append(f"\nMemory: {mem.percent}% used")
    report.append(f"  Total: {mem.total / (1024**3):.1f} GB")
    report.append(f"  Available: {mem.available / (1024**3):.1f} GB")
    if mem.percent > THRESHOLDS["memory_critical"]:
        alerts.append(f"CRITICAL: Memory at {mem.percent}%")
        logger.critical("Memory usage at %s%% on %s", mem.percent, hostname)
    elif mem.percent > THRESHOLDS["memory_warning"]:
        alerts.append(f"WARNING: Memory at {mem.percent}%")
        logger.warning("Memory usage at %s%% on %s", mem.percent, hostname)

    # Disk check
    total, used, free = shutil.disk_usage("/")
    disk_pct = (used / total) * 100
    report.append(f"\nDisk (/): {disk_pct:.1f}% used")
    report.append(f"  Free: {free / (1024**3):.1f} GB")
    if disk_pct > THRESHOLDS["disk_critical"]:
        alerts.append(f"CRITICAL: Disk at {disk_pct:.1f}%")
        logger.critical("Disk usage at %.1f%% on %s", disk_pct, hostname)
    elif disk_pct > THRESHOLDS["disk_warning"]:
        alerts.append(f"WARNING: Disk at {disk_pct:.1f}%")
        logger.warning("Disk usage at %.1f%% on %s", disk_pct, hostname)

    # Top processes
    procs = []
    for proc in psutil.process_iter(["pid", "name", "cpu_percent"]):
        try:
            procs.append(proc.info)
        except (psutil.NoSuchProcess, psutil.AccessDenied):
            continue
    top_procs = sorted(procs, key=lambda p: p["cpu_percent"] or 0, reverse=True)[:5]
    report.append("\nTop 5 Processes by CPU:")
    for p in top_procs:
        report.append(f"  PID {p['pid']:>6}  {p['cpu_percent']:>5.1f}%  {p['name']}")

    # Summary
    if alerts:
        report.append(f"\n{'=' * 50}")
        report.append(f"ALERTS ({len(alerts)}):")
        for alert in alerts:
            report.append(f"  {alert}")

    logger.info("Health check completed: %d alerts", len(alerts))
    return "\n".join(report), alerts

if __name__ == "__main__":
    report_text, alert_list = system_health_report()
    print(report_text)

This script produces clean, readable output that can be piped to a log file, emailed to an administrator, or parsed by another tool. The separation between the report text and the alert list makes it straightforward to add integrations later, such as sending alerts to Slack, PagerDuty, or an email gateway, without rewriting the monitoring logic.

Logging, Security, and Error Handling Patterns

A sysadmin script that works on a developer's laptop and fails silently in production is worse than no script at all. Three patterns separate professional automation from throwaway scripts: structured logging, secure credential handling, and deliberate error management.

Structured Logging with the logging Module

The Python logging module is far more powerful than print() statements. It supports log levels (DEBUG, INFO, WARNING, ERROR, CRITICAL), multiple output targets simultaneously, and structured formatting that downstream tools like Elasticsearch or Splunk can parse. For sysadmin scripts, the key discipline is logging at the right level: operational milestones at INFO, recoverable problems at WARNING, and unrecoverable failures at ERROR or CRITICAL.

import logging
from logging.handlers import RotatingFileHandler

def setup_logging(name, log_file, max_bytes=5_000_000, backup_count=3):
    """Configure production-ready logging with rotation."""
    logger = logging.getLogger(name)
    logger.setLevel(logging.DEBUG)

    # Rotating file handler prevents logs from filling the disk
    file_handler = RotatingFileHandler(
        log_file,
        maxBytes=max_bytes,
        backupCount=backup_count
    )
    file_handler.setLevel(logging.INFO)
    file_handler.setFormatter(logging.Formatter(
        "%(asctime)s [%(levelname)s] %(name)s: %(message)s"
    ))

    # Console handler for immediate feedback
    console_handler = logging.StreamHandler()
    console_handler.setLevel(logging.WARNING)

    logger.addHandler(file_handler)
    logger.addHandler(console_handler)
    return logger

Using RotatingFileHandler instead of a basic FileHandler is not a luxury. It is a necessity. A sysadmin script that writes unbounded log files will eventually fill the disk it was designed to monitor, creating exactly the problem it was supposed to prevent.

Credential Management

Hardcoded passwords and API keys in sysadmin scripts are a persistent security liability. The minimum viable approach is to read credentials from environment variables, which at least separates them from the source code. For production systems, dedicated secret managers provide stronger guarantees.

import os
import subprocess

def get_secret(key):
    """Retrieve a secret, preferring environment variables.

    In production, replace this with calls to HashiCorp Vault,
    AWS Secrets Manager, or your organization's secret store.
    """
    value = os.environ.get(key)
    if value is None:
        raise EnvironmentError(
            f"Required secret '{key}' not found in environment. "
            f"Set it with: export {key}='your_value'"
        )
    return value

# Usage
db_password = get_secret("DB_PASSWORD")
api_token = get_secret("MONITORING_API_TOKEN")

Deliberate Error Handling

Bare except clauses and silent failures are the enemy of reliable automation. Every sysadmin script should catch specific exceptions, log them with enough context to diagnose the problem later, and either recover gracefully or fail loudly. The pattern below demonstrates a retry wrapper that is practical for network-dependent operations like remote monitoring or API calls.

import time
import logging

logger = logging.getLogger("sysadmin")

def retry(func, max_attempts=3, delay=5, exceptions=(Exception,)):
    """Retry a function with exponential backoff."""
    for attempt in range(1, max_attempts + 1):
        try:
            return func()
        except exceptions as e:
            logger.warning(
                "Attempt %d/%d failed: %s", attempt, max_attempts, e
            )
            if attempt == max_attempts:
                logger.error("All %d attempts exhausted for %s", max_attempts, func.__name__)
                raise
            time.sleep(delay * attempt)  # Linear backoff

Scheduling and Orchestration

A monitoring script is only useful if it runs at the right time. Python offers several approaches for scheduling tasks, depending on the complexity of the workflow.

The simplest option on Linux systems is the system cron. Adding a line to the crontab is all it takes to run a Python script at regular intervals, and it requires no additional Python dependencies.

# Run the health check every 15 minutes
# Add this line to crontab with: crontab -e
*/15 * * * * /usr/bin/python3 /opt/scripts/health_check.py >> /var/log/health.log 2>&1

A more robust alternative on systems running systemd is to use a systemd timer instead of cron. Systemd timers provide better logging integration with journalctl, dependency management between services, and more precise control over execution conditions. The trade-off is additional configuration files, but for production scripts, the reliability gains are significant.

# /etc/systemd/system/health-check.service
[Unit]
Description=System Health Check
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/bin/python3 /opt/scripts/health_check.py
User=monitoring
Group=monitoring

# /etc/systemd/system/health-check.timer
[Unit]
Description=Run health check every 15 minutes

[Timer]
OnBootSec=2min
OnUnitActiveSec=15min
AccuracySec=1min

[Install]
WantedBy=timers.target

For workflows that need to remain within Python, the schedule library (version 1.2.0 as of 2026) provides a human-readable syntax for defining recurring tasks. It runs inside a long-lived Python process and is well suited for lightweight daemons. As the library's own documentation states, it is designed for simple scheduling problems, not as a replacement for full job orchestration.

import schedule
import time

def run_health_check():
    report, alerts = system_health_report()
    with open("/var/log/health.log", "a") as f:
        f.write(report + "\n\n")
    if alerts:
        # Integration point: send alerts to Slack, PagerDuty, etc.
        notify_on_call(alerts)

# Schedule the check every 15 minutes
schedule.every(15).minutes.do(run_health_check)

# Also run a daily disk cleanup at 3 AM
schedule.every().day.at("03:00").do(cleanup_old_logs)

# Run the scheduler loop
while True:
    schedule.run_pending()
    time.sleep(60)

For more complex orchestration involving multiple tasks, dependencies between jobs, and retry logic, tools like Celery or APScheduler offer the additional structure that production systems demand. APScheduler in particular supports cron-style triggers, interval triggers, and date-based triggers with persistent job stores backed by databases, making it a strong choice for applications that need scheduling to survive process restarts.

Where Python Fits in the Automation Landscape

Python scripts and full configuration management platforms like Ansible, SaltStack, Puppet, and Chef occupy different points in the automation spectrum. Understanding where each fits prevents two common mistakes: over-engineering a simple task with a heavy framework, and under-engineering a complex deployment with a fragile script.

Python sysadmin scripts (using the tools covered in this article) are the right choice when the task is specific and self-contained: a monitoring check, a log rotation routine, a one-off data migration, or a quick audit of running services. The script lives in a single file or a small package, runs directly via cron or systemd, and can be understood by a sysadmin who reads it top-to-bottom.

Configuration management tools become necessary when the problem shifts from "run this task" to "ensure this state." Ansible, for example, uses YAML playbooks to declare the desired state of a system and applies only the changes needed to reach that state (idempotency). SaltStack offers event-driven automation with a fast ZeroMQ message bus, making it well-suited for environments that need real-time reactions to infrastructure changes. Puppet and Chef enforce continuous state convergence using a client-server model.

The relationship between Python scripts and these platforms is not adversarial. It is complementary. Ansible itself is written in Python, and its modules are Python scripts. Fabric scripts frequently serve as the precursor to Ansible playbooks: an administrator writes a Fabric script to solve an immediate problem, and as the problem grows in scope, the logic migrates into Ansible roles. The psutil-based monitoring scripts in this article could feed data into a SaltStack reactor that automatically responds to resource spikes.

Start with a script. Graduate to a framework when the script needs to run on dozens of machines, handle rollbacks, or enforce state continuously.

-- A practical rule for choosing between Python scripts and orchestration platforms

When Python Is Not the Right Tool

There are tasks where Python sysadmin scripts are not the best fit, and recognizing these boundaries is part of being an effective administrator. Kernel-level monitoring and eBPF programs require C or Rust. High-frequency metrics collection (sub-millisecond intervals) is better served by purpose-built agents like Telegraf, node_exporter, or collectd that are optimized for minimal overhead. Large-scale configuration management across hundreds of heterogeneous servers almost always warrants a dedicated platform rather than a growing collection of Fabric scripts.

The practical test is this: if a Python script is acquiring complexity faster than it is acquiring reliability, meaning it needs its own configuration management, dependency tracking, and deployment pipeline, it is time to evaluate whether the problem has outgrown the script.

Key Takeaways

1. Start with the standard library: The os, shutil, subprocess, and pathlib modules handle filesystem operations, file management, shell command execution, and modern path manipulation without any additional installation. They form the foundation of every sysadmin script.
2. Use pathlib for new code: Since Python 3.4 (and especially since Path.walk() arrived in 3.12), pathlib provides a cleaner, object-oriented approach to path operations that the Python documentation explicitly recommends over os.path for new projects.
3. Use psutil for monitoring: Rather than parsing the text output of Unix commands, psutil 7.2.2 provides structured Python objects for CPU, memory, disk, network, and process data across all major platforms. Version 7.x added efficient process-waiting via pidfd_open() on Linux and kqueue() on macOS/BSD.
4. Reach for Fabric when going remote: Fabric 3.2.2 wraps SSH operations in a clean Python API, making it straightforward to execute commands, transfer files, and manage services on remote servers without installing agents. Use ThreadingGroup for parallel execution across large fleets.
5. Build for production from the start: Use the logging module (with RotatingFileHandler), never hardcode credentials, catch specific exceptions with retry logic, and define configurable thresholds rather than magic numbers.
6. Schedule thoughtfully: Use systemd timers or cron for simple schedules, the schedule library for Python-native daemons, or APScheduler for complex workflows that need persistent job stores and database-backed state.
7. Know when to graduate: Python scripts are ideal for focused operational tasks. When requirements grow to include state enforcement, rollbacks, and fleet-scale orchestration, evaluate whether the problem has grown into Ansible, SaltStack, or Puppet territory. These tools are complementary, not competing.

Python's ecosystem for system administration continues to grow stronger. With the standard library handling the basics, pathlib modernizing path operations, psutil covering system telemetry, and Fabric managing remote execution, administrators have a complete toolkit for building reliable, maintainable automation. The key is to start with a real operational pain point, write a focused script that solves it well, including proper logging, security, and error handling, and expand from there as the problem warrants it.