Monitoring, Logs and Keeping It Running

Deploying is the start, not the end. You need to know when the app breaks before your users tell you.

Four things to monitor

Error tracking with Sentry

import sentry_sdk
sentry_sdk.init(dsn=os.environ.get("SENTRY_DSN"), traces_sample_rate=0.1, send_default_pii=False)

Every unhandled exception arrives with its stack trace, request and release version. Do not send personal data unless your privacy policy covers it.

Logs

• Log to stdout with timestamps and levels; the platform collects and searches them.
• Log events that matter (sign-ups, payments, permission denials, failures), never passwords, tokens or full card data.
• Add a request ID to log lines so you can follow one request through the system.

Backups

Managed databases include automatic backups; check the retention period and test a restore to a scratch database. Back up user uploads separately (object storage versioning or a scheduled copy).

Costs

• Free tiers often sleep after inactivity (slow first request) and may delete data; read the limits.
• Watch bandwidth/egress charges for downloads and images; a CDN helps.
• Set billing alerts.

The operations checklist

• [ ] Uptime monitor on the health check
• [ ] Error tracking with alerts to your phone or email
• [ ] Automatic database backups, restore tested
• [ ] Dependency updates monthly (pip list --outdated, pip-audit)
• [ ] Platform and domain accounts protected by 2FA
• [ ] A short runbook: how to deploy, roll back, restore and rotate secrets

Final project

Take an app from your laptop to production: GitHub repository, CI running tests, a PaaS deploy with managed PostgreSQL, environment variables, a custom domain with HTTPS and a canonical redirect, a health check, Sentry, an uptime monitor and a tested database restore. Write the runbook. This is exactly what clients pay for when they ask you to "put the app online".

Check yourself

• Which four things should every live app monitor?
• What must never appear in logs?
• Why test restoring a backup?