I haven't resorted to the "restart in a cronjob", but on Python/Django apps, we pretty much always use the gunicorn/uwsgi setting that automatically restarts wo

I haven't resorted to the "restart in a cronjob", but on Python/Django apps, we pretty much always use the gunicorn/uwsgi setting that automatically restarts worker processes after serving some number of requests (typically 10-50k for us). There are just so many ways that a Python app can leak small amounts of memory and so many 3rd party libraries involved that it's so much easier to default to the automatic restart approach rather than play whack-a-mole tracking down and fixing leaks. FWIW, my experience with Go apps is similar to yours. I have apps that handle hundreds of requests per second and run for months at a time without leaking memory. When there is a leak, it's easy to profile and find it. Those apps just tend to be more constrained in what they do than eg, a major user facing Django app, that is more subject to feature creep and ends up with a huge surface area of infrequently used endpoints.