Costs increasing faster than expected

Questions / Help
1

Hello! Just starting out with Fly on a pre-launch project. Apologies in advance if I’ve missed something obvious.

We have four apps on the hobby plan. Each app is set not to scale so should be a single, 256mb instance. Everything looks right in the UI and inspecting the instances over the command line.

My understanding is that we should only be seeing costs rack up on just one of those instances (the other three being free), en route to $1.94/mo, per the pricing page.

Watching the costs today, they’ve been going up about $0.01 an hour, which would have us tracking over $7 per my calculation. Sampling over a couple of hours this evening, I’ve watched the seconds increase by 28,800 on VM: Shared CPU (Tier 2 at $0.00000075 / month), which would equate to 8 hours over a ~2 hour period.

Suggests we’re being billed for more than one of our four apps? Possibly all four? Keen to understand the way the costs are calculated while they’re low, and to make sure I’m not missing any scaling gotchas.

Any help in understanding this would be appreciated.

2

Hi @steve, that does look like four 256M shared-cpu-1x VMs being billed, and the first three such VMs should be free. The first thing I’d suggest is that you double-check how many instances each app has running.

For all your organization’s apps, listed under fly apps list, you can:

  • view all instances for each of those apps with fly status -a <appname>, or
  • view the scale of each app with fly scale show -a <appname> (but I think there may be a bug with fly scale show, only if you have tried multiprocess apps with the [processes] section of fly.toml)

You can also check scaling history for each app using fly history -a <appname>.

If this doesn’t uncover more VMs, can you send us an email at billing@fly.io and we’ll get things sorted?

3

The other thing that occurs to me is that we’re just finishing a month. IIRC, the 3 free full-time VMs are accounted for as a certain number of CPU-hours per month.

In this case, if an org had more than 3 VMs provisioned earlier in the month, the free hours could have been exhausted on those. That still adds up to 3 VMs worth of free CPU-hours per month; the free-ness would just be front-loaded in that case.

4

IIRC, the 3 free full-time VMs are accounted for as a certain number of CPU-hours per month.

This makes total sense. I think this is exactly what has happened. Thank you so much for getting back to me so quickly!

1 Like