System Scripting Best Practices
Scripts you can trust unattended follow the same operability rules as production services: predictable failure modes, safe defaults, and logs operators can search at 3am.
Search across all documentation pages
Scripts you can trust unattended follow the same operability rules as production services: predictable failure modes, safe defaults, and logs operators can search at 3am.
--dry-run for mutating tools.if __name__ == "__main__" and a main() -> int function. Keeps modules importable and testable.--help and README.--dry-run for destructive actions. Print intended changes without side effects.encoding="utf-8" on text files. Prevent platform default surprises.cd to project root.known_hosts or certificates.pyproject.toml entry points when scope grows.First prod run without preview causes irreversible deletes - dry-run is the cheapest insurance.
For quick local tools yes; scheduled prod scripts should use logging with levels.
argparse for zero-deps cron scripts; typer when building multi-command operator tools.
YAML/TOML in git for non-secrets; env vars for secrets; CLI overrides win on conflict.
Runbook with example commands, exit codes, expected runtime, and rollback steps.
Yes with reused boto3 session, retries, and least-privilege role - see Cloud SDK section.
pytest main() with tmp_path; integration test in staging with dry-run then live on sample data.
When dependencies, SLAs, and observability exceed one file and cron matrix becomes unmaintainable.
Store UTC in logs and filenames; document local-time cron only when business requires it.
Silent success on partial failure - always aggregate errors and exit non-zero when anything failed.
Stack versions: This page was written for Python 3.14.0 (stable 3.14, maintenance 3.13), FastAPI 0.115+, Django 5.2, Flask 3.1, Pydantic 2, PyTorch 2.6+, pandas 2.2+, Polars 1.x, ruff 0.9+, and uv 0.6+.
Reviewed by Chris St. John·Last updated Jul 16, 2026