Orphaned service from a restore billed $99.77 in VM Memory after downgrade from Pro
dhconn
HOBBYOP

19 days ago

(My apologies for not posting this in the BIlling thread, but I tried and it does not currently including a "Post this message" button.)

Project: Daily_Baltimore_News_Quiz (790670f9-9194-4135-ab8a-8a6ecc5eb2ac)

Workspace: dhconn's Projects

Environment: production

Currently on Hobby

After a data-loss incident in my Postgres service in late August, I upgraded to Pro specifically to restore from a backup, then downgraded back to Hobby on Sept 11. The restore provisioned a separate service named postgres-2026-08-23 00:47 UTC. That service was never removed when I downgraded. I only discovered it on Sept 16, at which point I deleted it. It contained 265 MB of data and served no traffic for its entire life.

My latest invoice has a line "VM Memory — $99.77", quantity 86,203,528 at $0.000001157407 each.

That unit price is $0.10 ÷ 86,400, so the unit is a GB-second, and the quantity decodes to 997.7 GB-days. My billing period ran Aug 16 – Sept 15 (confirmed by the Sept 11 proration lines on the invoice). Over 31 days that works out to 32.2 GB of memory billed continuously for the entire cycle — 32 GB × 31 days is 992 GB-days, within 0.6% of what I was charged.

32 GB is the Pro per-service memory ceiling, so this appears to be allocated memory, not consumed. The service held 265 MB of data; a Postgres instance that size uses on the order of 100 MB of RAM.

For comparison, my two real services average 0.074 GB and 0.100 GB of memory, on 0.27 GB of disk, serving ~25,000 requests a week.

That orphaned service was created by a restore around Sept 1, and I downgraded to Hobby on Sept 11. Yet the billed quantity corresponds to a full 31-day cycle at the Pro memory ceiling. A service created Sept 1 can only have existed for about half that period, so a large share of this charge appears to have no running service behind it.

I would be grateful if you would:

  1. Please confirm the exact creation and deletion timestamps you have for postgres-2026-08-23 00:47 UTC, and whether the meter ran outside that service's actual lifetime or continued after my Sept 11 downgrade.
  2. Please confirm whether this line bills allocated or consumed memory. If allocated, an idle 265 MB restore was billing at a Pro ceiling with no indication of it anywhere in my usage view.
  3. Please credit the $99.77, plus any accrual for this service still pending on the current cycle — it was live until Sept 16, which falls after the Sept 15 period close.
  4. Please confirm the date my workspace moved to Pro. I received an email confirming the Sept 11 downgrade, but I have no email and can find no invoice line recording the upgrade.
  5. Please confirm whether a restore-created service is intended to survive a downgrade from Pro to Hobby, and whether anything is supposed to warn the user that it is still billing. Mine persisted silently for two weeks after the restore completed.

Related — and the reason I was on Pro in the first place:

The restore was necessary because of a data loss I would still like explained. My Postgres service (2ca55bdd-d89b-4f00-890b-65eb13f3f479) took an automatic vulnerability patch at 2026-08-23T00:47:06Z — a Sunday, inside the service's configured auto-update window — and a "Pre-Security-Patch Backup" was created at that moment.

On Aug 27–28 I found that every write between Aug 23 and Aug 27 was gone: the database had reverted to exactly that pre-patch state. There were no deploys of my application on Aug 26–28 apart from a single image upload, and no deployment of the Postgres service between Aug 23 and Sept 1. I had to reconstruct five days of user data by hand.

Could you check what happened to that service's volume around the Aug 23 patch and in the days following?

Thanks so much for your attention to this.

Under Review

0 Threads mention this feature

0 Replies

Welcome!

Sign in to your Railway account to join the conversation.

Loading...