Deploy to Render

Monitoring, Costs and Troubleshooting

30 min

Logs and metrics

  • The Logs tab streams stdout/stderr; search it during incidents. Log streams can forward logs to external tools.
  • Metrics show CPU, memory and request data per service. Memory steadily climbing until restarts usually means too many workers for the instance or a leak.
  • Add Sentry for application errors and an external uptime monitor on /api/health.

Common problems and fixes

Symptom Likely cause
Deploy fails at build missing package, wrong Python version, failing migration
"No open ports detected" / health check failing app not binding to 0.0.0.0:$PORT, or the health route errors
502 errors after deploy app crashing on start: read the logs from the new instance
Out of memory restarts too many Gunicorn workers for the instance size
Slow first request free instance spinning up after idling
too many connections pool sizes too large for the database plan
Uploaded files vanish written to the ephemeral filesystem; use a disk or object storage
Rate limits not shared in-memory limiter with several workers; use Redis

Costs

  • Each service, database and disk is billed separately; review them monthly and delete unused previews and test services.
  • Right-size: if CPU and memory are low, a smaller instance may do.
  • Bandwidth for large downloads can add up; serve big files from object storage or a CDN.

A launch checklist for Render

  • [ ] Paid instance for customer-facing services
  • [ ] Health check path configured
  • [ ] DATABASE_URL uses the internal URL; backups and restore tested
  • [ ] Secrets in environment variables or groups; none in the repository
  • [ ] Migrations in the build or pre-deploy step, backward compatible
  • [ ] Uploads in object storage or on a persistent disk
  • [ ] Redis for rate limits and queues if more than one worker
  • [ ] Custom domain with HTTPS and a canonical redirect
  • [ ] Sentry and an uptime monitor
  • [ ] Rollback procedure written down

Final project

Deploy a full Flask application on Render from a render.yaml Blueprint: web service, PostgreSQL, Key Value, a worker and a cron job, a build script with migrations, a custom domain, preview environments for pull requests and monitoring. Then simulate an incident (a bad deploy), roll back and write a short post-mortem.

Check yourself

  • What does steadily rising memory usually indicate?
  • Why do files disappear between deploys?
  • What belongs on a Render launch checklist?

I tuoi progressi sono salvati solo in questo browser.

Invia per la revisione (10 punti)