Forums

My web app boniu.pythonanywhere.com has been returning 504-loadbalancer since ~16:19 UTC Jul 30 (it's a small order-management site for a shop, so we're quite stuck).

What I checked:

• error.log: no tracebacks at all today, only repeated "OSError: write error" entries.
• server.log: a worker got stuck on a hung POST /login and HARAKIRI could not kill it - signal 9 failed 5 times in a row ("HARAKIRI ON WORKER 1 (pid: 19, try: 2..5, graceful: no)"), then "DAMN ! worker 1 (pid: 19) died, killed by signal 9 :( trying respawn".
• After I clicked Reload on the Web tab: "SIGINT/SIGTERM received...killing workers...", "uwsgi_master_manage_emperor()/read(): Bad file descriptor", "lost connection with my emperor !!!", "VACUUM: unix socket removed" - and after that NO new uWSGI instance ever spawns. Tried Reload twice more, same result (one attempt showed "Your webapp took a long time to reload").
• Static file URLs also return 504 (so it's not my Flask code).
• Starting a Bash console took ~90 seconds at "Preparing execution environment".
• No code was deployed recently; the app had been running fine for months.

Looks like the web-server / storage node my account is on is unhealthy. Could you please respawn my web app from your side? Thanks a lot!

Update: the app briefly came back around 02:32 UTC Jul 31 — /login rendered normally for at least one request — but within a few minutes it was stuck again. New requests now hang for 70+ seconds with no response before eventually returning 504-loadbalancer.

So a worker does eventually respawn and serves a few requests, then hangs again — same pattern as the original stuck worker (hung in uninterruptible I/O, HARAKIRI signal 9 can't kill it). Still no code changes on my side, and static file URLs are affected too.

This flapping suggests the underlying web/storage node is still unhealthy. Could you take a look from your side? Thanks!

Same here on colinchia2 — consoles hanging on basic commands since ~17:00 UTC with CPU at 0%, and after pressing Reload at ~03:05 UTC my web app has been fully down since (external monitor shows 20+ minutes of timeouts on a no-auth endpoint).

Thanks for reporting this. Your PythonAnywhere account files are stored on a storage server that is experiencing some issues. It's a new failure mode and we're investigating it now to find a proper fix. Your files and data shouldn't be affected, but there may be degraded performance for your PythonAnywhere-hosted apps and scripts while we're working on a solution.

Apologies for any inconvenience!