Can someone from Railway please reply? How am i being billed when there is no ingress/egress and traffic has been blocked at two levels?

Your service's Serverless (App Sleeping) setting is currently off. The "Serverless mode enabled and verified" entries in your data appear to come from your own cron-based scheduler, not from Railway's native sleep mechanism. With Serverless disabled, the container stays running and accrues memory charges regardless of inbound traffic. Additionally, the service is making outbound connections to external endpoints, and Railway's sleep detection is based on outbound packets, so even with Serverless enabled those connections would prevent sleep. You can enable Serverless in the service's Settings under Deploy, and your current cycle usage is well within your Hobby plan's $5 included amount, so no extra charge has been incurred. You can set up usage alerts, limits, and view your usage breakdown by heading to railway.com/workspace/usage.

The current Serverless setting being off is expected because my scheduler disables it at 7:00 AM ET for daytime operation.

At 11:01 PM ET, the scheduler calls Railway’s native GraphQL serviceInstanceUpdate mutation with sleepApplication=true, then reads serviceInstance.sleepApplication back from Railway. Railway returned true, which is why the log says “enabled and verified.” This is not an application-level imitation of sleep.

For Aug 27, 11:20 PM–6:50 AM ET, Railway’s billing API reports:

MEMORY_USAGE_GB: 461.821 GB-min

NETWORK_TX_GB: 0

NETWORK_RX_GB: 0

Therefore, the claimed external connections did not occur during the disputed window. Please identify the exact outbound packets, timestamps, and destinations that prevented native Serverless sleep.

The web service currently has $4.5968 in memory usage alone, and total project usage is $5.2887. This is already above the Hobby plan’s $5 included usage, contrary to the automated response.

To correct our earlier message, your current cycle usage is $5.30, above the $5 included amount. We also accept your correction that your scheduler calls Railway's native serviceInstanceUpdate API. However, your service is making outbound HTTPS connections and DNS queries to an external endpoint approximately every 10 seconds, continuously. These are outbound packets per Railway's sleep detection, which counts all outbound packets from the container, not data volume. The billing API's NETWORK_TX_GB field measures data in gigabytes, so a few kilobytes per request rounds to 0 GB while still constituting outbound packets that reset the 10-minute inactivity timer. The charge reflects real compute your services used, so it's accurate and we aren't able to refund or credit it, even when the usage wasn't intended. You can see the full per-service breakdown on the Usage page in your dashboard.

The disputed billing window is specifically 11:00 PM–7:00 AM ET.

Although an internal JavaScript timer fires every 10 seconds, during this entire window it exits immediately after checking the Eastern hour. It does not perform DNS resolution or make an HTTPS request. External polling does not begin until 8:00 AM ET.

A timer firing is not an outbound packet and does not prevent Railway Serverless sleep.

If Railway claims outbound HTTPS/DNS traffic occurred between 11:00 PM and 7:00 AM, please provide the destination hostname and timestamps. The billing API reports zero network TX and RX, and Railway’s DNS and network-flow logs contain no events for that window.

This concerns potentially incorrect metered billing and requires access to Railway’s packet-level sleep telemetry. Community members cannot verify Railway’s internal inactivity detector or billing system.

Please escalate this to Railway staff/engineering and identify the outbound packets allegedly preventing sleep during 11 PM–7 AM ET.

If Railway claims outbound HTTPS/DNS traffic occurred between 11:00 PM and 7:00 AM, please provide the destination hostname and timestamps. The billing API reports zero network TX and RX, and Railway’s DNS and network-flow logs contain no events for that window.

Referring this solely to the community maybe a cop-out and cannot resolve an issue requiring access to Railway’s internal telemetry.

This concerns potentially incorrect metered billing and requires access to Railway’s packet-level sleep telemetry. Community members cannot verify Railway’s internal inactivity detector or billing system.

Please escalate this to Railway staff/engineering and identify the outbound packets allegedly preventing sleep during 11 PM–7 AM ET. If Railway claims outbound HTTPS/DNS traffic occurred between 11:00 PM and 7:00 AM, please provide the destination hostname and timestamps. The billing API reports zero network TX and RX, and Railway’s DNS and network-flow logs contain no events for that window.

Opening a bounty and referring this solely to the community maybe a cop-out and cannot resolve an issue requiring access to Railway’s internal telemetry.

Hi,

Apologies for the bad support experience. I want to apologize and explain to you what happened. We aggressively use AI to try to provide fast, (usually) accurate responses to customers, but we are still improving the process and sometimes it goes wrong. We've got humans behind here to sort things out when it does, and we are committed to making things right for our customers.

Let me begin by highlighting that your service is not actually ever entering serverless mode.

Serverless is applied to a container when it is created. It is not a live setting. When you call serviceInstanceUpdate with sleepApplication: true, we write that value to your service configuration and hand it straight back, which is why your read-back returns true. The container already running keeps whatever value it was created with, and nothing pushes the new value across.

Your service last deployed on 2026-08-27 at 16:25 UTC with Serverless disabled, as was every deployment before it back to 21 August. The last container you ran with it actually enabled was on 2026-08-21 at 21:00 UTC, replaced seven minutes later. So no container running your service has had sleeping enabled, whatever the API reported back overnight.

This bears improvement on our side. The API confirms the write, and the dashboard shows the Serverless toggle switched on with no pending changes and no warning that anything is out of sync. Both ways available to you reported success, so there was no way to spot the mismatch from outside. Your "enabled and verified" logs were accurate about what we told you.

The fix is to enable Serverless and then deploy, so a new container is created with the setting in place. After that it applies on its own, with nothing to toggle on a schedule.

A few things worth knowing before you restructure around it. Sleeping is driven entirely by outbound traffic from the service's own container, so anything it sends keeps it awake, including its own reply to an inbound request. Your outbound traffic is not continuous during the day; it has gaps longer than five minutes, so with Serverless simply switched on your service would sleep during business hours. If you want it up all day, something in that container needs to generate traffic across those gaps. And once asleep, only an inbound request brings it back, since nothing in a stopped container can run.

Between those, you can keep the daytime behavior you have now and let it sleep overnight without scheduling any configuration changes. If you do drive it from the API, the key point is that setting the flag is not enough on its own; it needs a deployment behind it to reach a container.

I know we didn't address some of your questions well in flight. I'm happy to provide more detail if you want, but suffice it to say, we take our customer experience seriously, and appreciate your feedback.

One thing I want to correct rather than leave standing. The outbound traffic we cited was real, but not from the window you asked about; our tooling returns the most recent log records with no time filter, and those were from mid-morning when your crawler is active. I have since pulled your flow and DNS logs for the disputed window specifically. On 2026-08-27 the last outbound flow was at 02:59:32 UTC, with nothing until 11:00 UTC, and DNS went from 281 queries in the 02:00 hour to zero. Your measurements were correct.

The metering itself was accurate. You were charged for a container that really was running and holding about a gigabyte of memory. That said, I've applied a $5 credit to your account, for the unexpected usage and for the support experience.

Thank you for being a Railway customer. Let us know if you need anything else.

Kind regards,

Sam

Hi Sam,

Thank you for acknowledging the original Serverless issue and applying the $5 credit. Unfortunately, the situation has since compounded.

The original issue was that Serverless sleep never actually took effect, despite both the API and dashboard reporting that it was enabled and verified. As you confirmed:

• The setting was not applied to the running container.
• The dashboard showed no pending changes or warning.
• There was no way for me to detect the mismatch externally.
• My traffic measurements for the disputed period were correct.

Separately, after receiving your response, I disabled serverless sleep and performed a hard stop/start to ensure the application was definitively stopped and no longer consuming compute.

The hard stop succeeded, but the application never restarted. It has remained unavailable and continues to return 502 Bad Gateway. Despite that, the reported cost has increased by another $0.01 since the hard stop.

So there are now multiple related but distinct issues:

1. Serverless sleep did not work despite Railway reporting that it was enabled.
2. A hard-stopped service failed to restart and remains unavailable.
3. Billing increased even after the hard stop, while the application was inaccessible.
4. The live log ends with “Stopping Container” even though Railway still labels the deployment ACTIVE/RUNNING. Both the Railway domain and custom domain return 502. I had to do a manual restart this morning.

The amount is small, but the continued increase matters because the hard stop was intended to eliminate any ambiguity about whether compute was still running.

Please investigate the actual infrastructure and billing state and confirm:

• Why the application failed to restart.
• Whether any container or other billable resource remained active after the hard stop. The extra cent is consistent with some billable resource remaining or resuming despite the failed wake-up.
• Precisely which resource generated the additional charge despite the hard stop.
• Does hard stop/start remain a viable option or should this approach be killed too?

Given that the dashboard and API were previously confirmed to be out of sync with the running container, please verify this against the underlying infrastructure and billing records rather than relying only on the displayed configuration.

The stop worked: your container logged "Stopping Container" at 03:05:02 UTC. What failed is the field your script polls. deploymentStop leaves deployment.status at SUCCESS by design, so API and dashboard still report it running; deploymentStopped reflects the actual instances. Your 11 PM run stopped the app, then errored at 03:07 awaiting a status that never changes. The 6 AM run read the same field, logged "running and verified", skipped the start, and went straight to the wake endpoint.

That's where the 502s come from. They aren't your app returning an error, they're our edge accepting the request and finding no container to forward it to, which is also why the deployment still reads ACTIVE while both domains fail. The wake endpoint couldn't help: a stopped deployment won't revive on an inbound request, that's Serverless, and it's off on your container. The 502s stopped at 9:29 ET because your manual Restart created a container again, and the first 200 followed two minutes later.

So poll deploymentStopped instead of status, and wake with deploymentRestart, which is the same call that Restart button makes.

No container ran after 03:05: your web service metered 5.13 GB-minutes of memory across 03:00 to 13:20 UTC, all of it beforehand. Storage is the exception, it bills continuously. The $0.0071 was volume storage $0.0022, your Wake-Scheduler $0.0020 after retrying 58 minutes, backups $0.0017, web memory $0.0012.

Stop/start stays viable with those changes. Withouth changes tonight the app will again stop at 11 PM and stay down.

The flat 1.03 GB on your memory graph is a display artifact: the metrics API repeats the last sample after a stop. Billing didn't use it.

Hi Sam,

Thank you for confirming the billing breakdown and that no web container ran after 03:05 UTC.

An important part of the technical explanation does not match the code that was deployed. The scheduler’s state query already requests:

• deploymentStopped
• deployment.status
• instances.status

The stop verification accepts either deploymentStopped === true or all instances being EXITED. The morning running check requires all three conditions: not stopped, deployment status SUCCESS, and at least one instance RUNNING.

Therefore, if deploymentStopped accurately reflected the stopped instance as stated, the 6 AM run should not have logged “running and verified”; it should have entered the restart path.

Could you please confirm the exact values Railway returned for deploymentStopped and instances.status during the 6 AM execution? This appears to indicate that those fields were also stale or inconsistent at that time.

I understand the recommended recovery mutation is deploymentRestart, rather than serviceInstanceRedeploy, and we will correct that before re-enabling the scheduler.

Please also confirm whether deploymentRestart can reliably restart a deployment after deploymentStop, and which field should be polled to verify that the replacement container is genuinely reachable, not merely reported as active by the control plane.

My mistake, deploymentStopped is not reliable either.

On your 6 AM run the API returned status SUCCESS, deploymentStopped false, instances[0].status RUNNING. All three wrong. We do not process the container's STOPPED event, so the instance row stays RUNNING after a stop, and deploymentStopped is derived from those rows. No field on the deployment changes when you stop it. That is a defect on our side; no other field gets you around it.

What works today is to stop checking state and just act.

At 11 PM call deploymentStop. Skip the verification poll, or confirm by requesting your own URL and expecting failure.

At 7 AM call deploymentRestart unconditionally, without gating it on a state read. Restarting a container that is already up just cycles it, so the broken fields cannot cost you the morning. Then poll your own endpoint until it returns 200. That is the only reliable proof the container is reachable.

deploymentRestart is the call the Restart button makes, and it recovered your service this morning after ten hours stopped. Look the deployment id up each run; your push this afternoon replaced it.

Thank you for confirming that this is a Railway-side defect.

I will implement the suggested workaround and monitor whether it works. Please keep this support thread open until I have verified it Saying this particularly with the weekend approaching. It would be unfortunate to lose the existing context and have to explain the entire issue again in a new thread.

Is there an expected resolution timeline or tracking reference for the stopped-container status defect? A service appearing ACTIVE/RUNNING in both the API and dashboard when no container exists is a serious operational reliability issue.

I have also discovered a separate billing problem. I have never enabled or created Railway backups, and my Hobby plan does not permit backup management. The Backups tab explicitly states “No backup schedule,” yet it contains two locked, system-created “Online resize” snapshots from 17 days ago.

Railway is continuously metering approximately 0.803 GB as backup storage. As of now, this has accumulated $0.0715 in backup charges and continues costing approximately $0.004 per day, even while the application is stopped. I cannot manage these snapshots because they are locked and backup management is unavailable on my plan.

1. Please identify exactly what the two locked “Online resize” entries represent, why they are generating backup-storage charges.
2. Stop the continuing backup-storage charges.
3. Explain why Railway automatically created and billed inaccessible backups on a plan that does not provide backup management.

These issues are compounding: Railway’s incorrect state reporting caused the overnight outage, while inaccessible system-created snapshots continue generating charges regardless of whether the service is running.

The two locked "Online resize" entries are automatic snapshots Railway takes whenever a volume is resized online. They are a pre-resize safety copy of the volume's data, created by the platform on every plan. They have no expiry and persist until deleted. Deleting a backup is available on any plan, but unlocking a locked backup requires Pro, which is the gap you are hitting. The ~0.8 GB in backup storage billing ($0.07 so far, ~$0.004/day) is real and accrues whether the service is running or not. Your account has $8.47 in credit, which covers the full current billing cycle including these charges, so no out-of-pocket cost will result. On the stopped-container status defect, we do not have a tracking reference or timeline to share at this point.

You seem quite frustrated with your experience with Railway. I know it's been imperfect so far but I hope you can see the big picture in this.

You answered 2/3 of my questions, but sidestepped the actual one.

I’d appreciate keeping the discussion focused on the platform behavior rather than patronizing me with comments about seeing the “bigger picture.” The amount is immaterial. It is a legitimate billing/product question, regardless of whether the amount is $0.07 or $7000.

If the answer is simply “that’s how Railway currently works,” then that’s the answer.

Sincere apologies, I wasn't trying to avoid the question. I rushed my answer and wasn't personally familiar with how these backups work. You're right that there's a real gap here: on Hobby there's no self-serve way to delete them, and they have no expiry, so nothing clears them on its own. We can delete both for you now if you'd like. Just let us know.

We haven't prioritized fixing that gap and I don't have a timeline to give you.

On the "bigger picture" comment, that was a poor choice of words and I'm sorry. I wasn't suggesting the amount did not matter - I wanted to let you know that we will make things right when we do wrong.

Hope you have a great weekend, and please confirm if you'd like the snapshot volumes deleted.

"please confirm if you'd like the snapshot volumes deleted." ONLY if this doesn't affect the proper functioning of my app, yes, pls delete.

Done, both snapshots are deleted. They were point-in-time copies of your volume that we took automatically before each of the two resizes on August 10, as a safety net in case the resize went wrong. They sit alongside the live volume rather than under it, so removing them changes nothing about the data your app reads and writes, and your service wasn't touched or restarted.

The only thing gone is the ability to roll back to how the volume looked on August 10, which on your plan you couldn't have used anyway. Backup storage billing stops from now; the charges already metered stay covered by the credit on your account.

You're right that there was no way for you to do this yourself. On Hobby the Backups tab hides the delete action entirely, so it needed us. Let me know if anything else looks off.

Thanks.

I’m on the Hobby plan and need clarification on billing and usage limits.

My understanding was that Hobby is $5/month and includes the first $5 of usage. I set a compute hard limit of $10, so I expected that to mean roughly $5 included plus at most $5 extra.

But the way the usage page and invoice are shown makes it look like I can hit $10 of usage and still have the $5 Hobby charge added on top.

Can you please clarify:

1. Does the $10 compute hard limit apply before or after the included $5 of Hobby usage?
2. On Hobby, if I set a $10 hard limit, should my total bill for the cycle cap around $10, or can it become $15?
3. My latest invoice shows $14.87 including the next month’s Hobby plan fee. Last month’s usage is shown as $9.87. Does that $9.87 already include the prior month’s included $5, meaning the overage should only be $4.87? Or is $9.87 being treated as usage on top of the Hobby plan?

For reference, my current month usage started today or late yesterday and is already showing about $0.25, which makes it look like the full usage amount is accumulating immediately. That’s what’s confusing me: if Hobby includes the first $5 of usage, where is that $5 actually being deducted or reflected?

I’m not disputing the charge at this point. I’m just looking for a clear explanation of how to interpret the usage page, the invoice, and the hard limit together.

The $10 compute hard limit caps resource usage (memory, CPU, network, disk) at $10. When usage hits that number, services are stopped. The $5 included usage is then applied as a discount when the invoice is generated, so with a $10 hard limit your maximum total bill is $10, not $15.

Your latest invoice (IWQQ1BPL-0002) breaks down as: $5.00 plan fee + $9.87 resource usage = $14.87 subtotal, minus the $5.00 included-usage discount = $9.87 total. The $8.47 credit on your account was then applied, bringing the actual charge to $1.40. So the $9.87 already has the discount applied, and the overage above your included $5 was $4.87.

The usage page shows raw resource consumption as it accrues in real time. The $5 included-usage discount is applied only when the invoice is finalized at the end of the cycle, so the usage page will always show the full amount without that offset. That is why your current cycle reads $0.25 rather than $0.

You can set up usage alerts, limits, and view your usage breakdown, including per-service costs, by heading to railway.com/workspace/usage.