Additional finding: railway volume list --json shows a second,

orphaned volume still present on this project:

• Name: donutkick-volume-HZP8
• Volume ID: 6321c0df-4f07-40e6-a769-bfae997109cc
• currentSizeMB: 3787.8
• isPendingDeletion: true
• serviceName: null (detached)
• deletedAt: 2026-07-20T01:00:49.763+00:00

This volume was deleted weeks ago as part of a migration to the

current volume (43cbd771-...), but it appears to never have been

fully purged — it's stuck in "pending deletion" and may still be

billed. Could you force-purge this volume as well?

The gap between your filesystem usage (132 MB) and the reported metric (1.65 GB) is a ZFS block-allocation discrepancy, not a data issue. The usage metric tracks allocated storage blocks rather than logical file size, and freed blocks are only returned when they are discarded back to the underlying storage layer. Running fstrim from inside the container is expected to fail (containers lack the required capability), so that is not a viable path.

Billing does track this metric, so the inflated number does affect your charges. The most reliable self-serve fix is to create a new volume, copy your ~132 MB of data to it, attach it to the service, and delete the current volume. A fresh volume starts with a clean block allocation that matches your actual data.

Regarding the second volume you found in pending deletion - when a volume with data is deleted, it enters a 48-hour safety retention window before it is permanently removed. This is a safeguard against accidental data loss and cannot be expedited. It clears on its own once the window passes, and you will not be billed for it after it is fully removed.

Following up on my earlier thread (volume-usage-metric-still-inflated-after-0f7b9674). I migrated to a completely fresh volume on 2026-07-22 (00:39 KST). Real usage matched the metric immediately after migration. I'm not trying to guess at a root cause this time — just reporting the exact observed shape, since it doesn't match either of my two working theories.

Timeline:

2026-07-22 00:39 KST: migration completed, currentSizeMB ≈ real usage (~150-215MB).

2026-07-22 through 2026-07-23 17:00 KST (~40 hours): currentSizeMB climbed steadily up to ~3.7GB.

Zero deployments during this entire window.

Since 2026-07-23 17:00 KST through now: completely flat at ~3.7GB.

Real usage stayed flat at 215-243MB throughout — before, during, and after.

What doesn't add up: an hourly background job writes to SQLite every hour, all day, every day — if that drove the growth, it should still be climbing now, but it's been flat for over a day. A separate once-daily batch job should produce one big step per day, not a 40-hour continuous climb. Neither matches "climbs steadily then flatlines."

Questions:

What exactly does currentSizeMB measure, and how is it sampled?

Could a snapshot/point-in-time-recovery mechanism on your side pin and later release blocks independent of the container's own writes?

Is periodic volume migration really the only self-serve fix?

Does currentSizeMB directly drive billing, or is billing based on provisioned sizeMB (5GB) regardless?

Volume ID: ee8fb0c6-95d8-4946-826c-eac976b4bd10 / Project: donutkick

currentSizeMB reports the storage actually allocated to the volume, which can sit above the file sizes visible inside the container until freed space is reclaimed. Billing averages this figure over the billing period, so charges follow it rather than the provisioned 5 GB.

There are no snapshots on your volume, so no point-in-time mechanism on our side is pinning and releasing space independently of your writes.

Migration to a fresh volume and redeploys remain the self-serve options.