Project: protective-commitment, service: control-panel-alpaca, volume: control-panel-alpaca-volume (id 94a941c8-20d9-4451-b77a-0dfe89f2b1b0).

The Volume Usage dashboard graph and the project cost breakdown show usage climbing continuously and independently disagree with what your own railway volume list --json API reports for the same volume at the same time:

railway volume list --json → "currentSizeMB": 0.688128 (real, current size)

Dashboard "Volume Usage" graph → climbing smoothly toward ~950MB / 94% of a 1GB volume over the same hour

Project cost breakdown → "Volume" and "Backup" line items both continuously increasing ("Volume: 316.39 minutely GB", "Backup: 26.02 minutely GB" and rising), driving the estimated bill for this period to $6.54 against the $5 included Hobby plan usage

We independently confirmed the real usage is small every way available to us from inside the container: df -h and du -sh via railway ssh and our own app-level file-size check have all consistently shown a few MB, matching your own volume list API's 0.69MB — never the number shown in the dashboard or billed in the cost breakdown.

This pattern has recurred repeatedly across today's session (usage previously shown climbing to 89-97% capacity multiple times while direct on-container checks always showed real usage under 1% of the volume's capacity), including once after fully wiping the volume, where the dashboard still climbed back toward 90%+ within an hour with zero manual writes beyond normal lightweight application activity.

Could you look into why the billing/metrics pipeline is reporting usage that doesn't match the volume's actual real size, and review/credit the charges accrued from this discrepancy for this billing period?