Hi @danielfriis! From your screenshot it looks like you created a single-node development database. Do you remember if you enabled scale-to-zero when you did so? If so, your DB will shut down if it’s had no open connections for an hour.
Just in case you did enable scale-to-zero, here’s some extra troubleshooting info in advance:
Your database must be configured to autostart when your app connects to it. Some older flyctl version didn’t do this properly, so if you want to keep scale-to-zero enabled, then you can run the following to ensure that autostart is configured:
fly machines -a <name of your database app> update <machine id> --autostart=true
(If you don’t know the machine ID, an easy thing to do is replace <machine id> with --select in that command and then pick it from the menu you get.)
If you would prefer to disable scale-to-zero, you can do that following these instructions.
If you’re not sure whether you’ve deployed the changes you made to your local fly.toml, then you can pull down the most recently deployed configuration with fly config show or fly config save (just be careful with config save not to overwrite your local fly.toml if that’s not your intention!). And whenever you run fly deploy, the autostart and autostop settings will be updated according to your fly.toml.
If not specified, then autostart is enabled by default, whereas autostop is not.
Just to give a comprehensive answer, here’s another, low-level way to check. (Chances are you won’t need it, so feel free to ignore it!)
Since Apps v2 is built on Fly Machines, you can check the configuration of individual machines in your app. You can see that with fly machines status -d <machine ID> (the -d flag asks it to dump the machine configuration in JSON form). In the services sections, you may find autostart/autostop fields like this: