Python Runtime Checklist

Python, pip, venv, package paths and service checks. Last updated August 28, 2026.

Python issues often look like application bugs when the real cause is runtime drift: the terminal uses one interpreter, the service uses another, the virtual environment is not active, a package is installed globally instead of inside .venv, or the web worker starts from the wrong directory. The official Python documentation maintains platform setup notes at docs.python.org/3/using, and the Python Packaging User Guide explains pip and virtual environments. Use this checklist to collect operational evidence before changing code.

Identify the active interpreter

Run these checks in the same shell, container or remote session where the problem happens. Python command names can differ between Windows, Linux, WSL, Git Bash and hosting panels.

python --version
python3 --version
python -c "import sys; print(sys.executable); print(sys.version)"
python -c "import site; print(site.getsitepackages())" 2>/dev/null
which python
which python3

# Windows PowerShell
py --version
py -0p
python -c "import sys; print(sys.executable); print(sys.version)"
where python
where py

Verify pip and virtual environments

Always call pip through the interpreter you plan to run. This avoids installing a package into one Python while executing another Python.

python -m pip --version
python -m pip list
python -m pip check
python -m venv .venv
# Linux or macOS
source .venv/bin/activate
# Windows PowerShell
.\.venv\Scripts\Activate.ps1

Framework and service checks

Django, Flask and FastAPI apps usually fail because the service environment is not the same as the interactive shell. Compare module imports, environment variables, working directory and service command.

python -m pip freeze
python -c "import os, sys; print(os.getcwd()); print(sys.path[:5])"
python -c "import django; print(django.get_version())" 2>/dev/null
python -c "import flask; print(flask.__version__)" 2>/dev/null
python -c "import fastapi; print(fastapi.__version__)" 2>/dev/null

Linux systemd evidence

When Python runs behind Gunicorn, Uvicorn, Celery, RQ or a custom worker, inspect the exact command before changing settings.

systemctl status my-python-app --no-pager
systemctl cat my-python-app
journalctl -u my-python-app -n 120 --no-pager
ps aux | grep -E '[p]ython|[g]unicorn|[u]vicorn|[c]elery'
ss -tulpn | grep -E 'python|gunicorn|uvicorn' 2>/dev/null

Windows service and scheduled task checks

On Windows hosts, verify whether the app is launched by a user shell, Task Scheduler, NSSM, IIS, a service wrapper or a CI runner.

Get-Command python
py -0p
Get-Service | Where-Object {$_.Name -match "python|app|worker"}
Get-ScheduledTask | Where-Object {$_.TaskName -match "python|app|worker"}
Get-EventLog -LogName Application -Newest 80 | Select-Object TimeGenerated, Source, EntryType, Message

Common Python runtime failures

Symptom	Check first	Likely direction
`ModuleNotFoundError`	`python -m pip --version`, `sys.executable`, active `.venv`	The package is installed into a different interpreter.
Works in terminal, fails as service	systemd unit, Windows service command, working directory, environment variables	The service does not activate the same environment.
Import uses old code	`sys.path`, deployment path, editable installs, cache files	The host is running a stale directory or package.
Slow API response	worker count, CPU, database latency, logs, blocking calls	The runtime may be waiting on IO rather than Python itself.
TLS or HTTP failures	certificate store, proxy variables, package versions	The runtime environment differs from local development.

Deployment evidence to save

date -Is
hostname
git rev-parse --short HEAD
python -c "import sys; print(sys.executable); print(sys.version)"
python -m pip --version
python -m pip check
env | grep -E 'PYTHON|VIRTUAL|DJANGO|FLASK|FASTAPI|DATABASE|REDIS' | sort

The fastest Python fix is often not a code edit. First prove the interpreter, pip target, virtual environment, service command and logs are all describing the same runtime.