4 days ago
Project: angelic-optimism · Service: Maukbs · Region: europe-west4 · Custom domain: ops.maukbs.com
On 30 September 2026, two separate sites using our app both received the "Not Found — The train has not arrived at the station. Please check your network settings to confirm that your domain has provisioned" page when loading https://ops.maukbs.com/. One of them photographed it (attached).
Request ID: inHBg3zwRaOo7foUjUJq2g
Both recovered on their own within about six minutes, with no action taken at our end:
Site A: last failure 07:35:29 UTC, first success 07:41:12 UTC
Site B: last failure 07:36:56 UTC, first success 07:42:32 UTC
These are different premises on different ISPs, so a local connectivity fault at one site is ruled out. Our service was not redeployed or restarted — the deploy log shows a single "Application startup complete" at 09:22 UTC on 29 September and nothing since. The failed requests do not appear in our service's HTTP logs at all, which suggests they were rejected at the edge before reaching the service.
Could you tell us:
- What caused the domain to be treated as unprovisioned during that window?
- Whether anything in our configuration makes this more likely to recur?
- Whether this affected other requests we would not have seen?
This matters because the app is used for staff clocking in and out at retail premises — an outage during opening time means attendance records are lost for that period, which we then have to reconstruct by hand.
Attachments
1 Replies
4 days ago
Apologies for the trouble. On 30 September we had an incident where our global routing service returned not-found responses for domains hosted with us after a network configuration change was rolled out. It was reported from 07:34 UTC and resolved by 07:57 UTC. Your failures at 07:35 and 07:36 UTC fall inside that window. It also explains why those requests never showed up in your service's HTTP logs: they were answered at our edge and never reached your service.
Nothing in your setup caused it or makes it more likely to happen again. The domain's DNS record is correct, it is verified, and its certificate is valid. The incident affected new connections to every workload hosted with us in all public regions, so any client that opened a new connection to your app in that window would have had the same failure, not only the two sites you saw.
You can see the full timeline here: Domain routing disruption
Status changed to Awaiting User Response Railway • 4 days ago