Your Postgres service is crashed with no runtime logs available, which is characteristic of the process being terminated due to memory exhaustion (OOM kill). Your usage data shows memory is the dominant cost across your workspace at $9.14, with Postgres alone at $1.77 in memory. The 5 GB increase you applied was to the volume (disk storage), which shows only $0.05 in usage and is not the issue here. You can check current memory consumption in the Metrics tab of the service, and if needed, configure Postgres memory settings like shared_buffers and work_mem via ALTER SYSTEM as described in our Postgres docs.

no look at logs its clearly saying FATAL: could not write to file "pg_wal/xlogtemp.26": No space left on device

You're correct, your Postgres service is crash-looping due to the volume being full, causing WAL write failures. The previous reply incorrectly attributed this to memory. On the Hobby plan, the default volume size is 5 GB, so if the volume was already at that size, your resize may not have changed anything. You can try a live resize to a larger size from the volume settings, and since your volume is at 100% capacity, it will automatically perform an offline resize with a service restart and data integrity check.

it was only 500 mb i did a live resize now its at 5 Gb but still failing