a day ago
Hi, my project is currently impacted by the recent service disruption.
I'm running Directus with a Postgres database in EU West.
Current situation:
- Postgres shows as "Completed" but intermittently not serving connections
- Directus crashes repeatedly with KnexTimeoutError (timeout acquiring connection)
- I adjusted DB pool variables to reduce connections
- After redeploy, the deployment is now stuck in "Queued" for over 10 minutes
Because of this, Directus is not responding at all ("Application failed to respond").
Can you confirm:
- If EU West is still experiencing degraded deployment or database connectivity?
- If deployments are currently stuck in queue due to capacity?
- If my Postgres volume (postgres-volume) is safe and unaffected?
This is a production project and I currently cannot access my CMS.
Thanks.
6 Replies
a day ago
Your project was directly impacted by the service disruption that affected EU West and has since been resolved. Your Postgres service is currently crash-looping (unable to start its main process), and your Directus deployment is stuck in an initializing state, both consistent with lingering effects of the outage. Your Postgres volume is being mounted successfully, so your data appears safe. We recommend redeploying your Postgres service now that the incident is resolved, and once Postgres is healthy, redeploy Directus as well. If either service remains stuck after a fresh redeploy, please let us know.
Status changed to Awaiting User Response Railway • 1 day ago
2 hours ago
Following up here since my new thread was closed as duplicate.
After the outage recovery, my Directus instance is partially working:
- /items endpoints work publicly
- but ALL /assets/:id return 403
Error:
"You don't have permission to access collection "directus_files" or it does not exist."
This affects all images, PDFs, and file access across the site.
Important:
- This issue started AFTER the Railway outage and recovery
- I did not change anything in infrastructure
- I only attempted a backup via API during recovery
Even after reviewing Public Policy permissions, assets remain blocked.
Could the outage or recovery process have affected Directus system collections or public access state?
This is currently breaking the entire frontend.
Would appreciate urgent guidance.
Status changed to Awaiting Railway Response Railway • about 2 hours ago
Status changed to Open Railway • about 2 hours ago
an hour ago
This is currently breaking the entire frontend (all images and PDFs are inaccessible publicly).
Would really appreciate prioritizing this, as content endpoints work but the site is visually unusable.
Railway
Your project was directly impacted by the [service disruption](https://status.railway.com/incident/I23M92U0) that affected EU West and has since been resolved. Your Postgres service is currently crash-looping (unable to start its main process), and your Directus deployment is stuck in an initializing state, both consistent with lingering effects of the outage. Your Postgres volume is being mounted successfully, so your data appears safe. We recommend redeploying your Postgres service now that the incident is resolved, and once Postgres is healthy, redeploy Directus as well. If either service remains stuck after a fresh redeploy, please let us know.
an hour ago
Following up here with additional diagnostics:
- directus_files Read is set to "All Access"
- No filters are applied
- Field permissions are fully enabled
- /items endpoints work correctly in incognito
- ONLY /assets endpoints return 403
Error:
"You don't have permission to access collection 'directus_files' or it does not exist."
This suggests the issue is not basic permission configuration.
Given this started immediately after the outage and recovery, could this indicate an inconsistent Directus state affecting system collections like directus_files or public access resolution?
Would a full redeploy of Directus (after confirming Postgres stability) be the recommended next step?
This is currently breaking a live production site, so I would appreciate guidance on the safest fix.
androikzone
Following up here with additional diagnostics: - directus_files Read is set to "All Access" - No filters are applied - Field permissions are fully enabled - /items endpoints work correctly in incognito - ONLY /assets endpoints return 403 Error: "You don't have permission to access collection 'directus_files' or it does not exist." This suggests the issue is not basic permission configuration. Given this started immediately after the outage and recovery, could this indicate an inconsistent Directus state affecting system collections like directus_files or public access resolution? Would a full redeploy of Directus (after confirming Postgres stability) be the recommended next step? This is currently breaking a live production site, so I would appreciate guidance on the safest fix.
an hour ago
Update after testing:
I performed a clean redeploy of the Directus service while Postgres was online and stable.
Directus deployed successfully, but /assets/:id still returns:
{"errors":[{"message":"You don't have permission to access this.","extensions":{"code":"FORBIDDEN"}}]}
So the issue persists after redeploy.
Content endpoints still work publicly; only assets remain blocked.
androikzone
Update after testing: I performed a clean redeploy of the Directus service while Postgres was online and stable. Directus deployed successfully, but /assets/:id still returns: {"errors":[{"message":"You don't have permission to access this.","extensions":{"code":"FORBIDDEN"}}]} So the issue persists after redeploy. Content endpoints still work publicly; only assets remain blocked.
an hour ago
Additional confirmation:
- directus_files collection exists and is readable in admin
- issue only affects public /assets endpoint
- reproducible consistently in incognito
Happy to provide logs if needed.