Service: arise-os (project c14ca9b1-a9fe-4f64-9ee6-790085a7a413, service edadb862-fe20-4249-8520-27d4b16714c6, environment 57f0ebd0-81df-4f74-adb0-11b6b32e7ae1), Next.js app deployed via GitHub (AriseAbove/arise-os-private, branch rebuild/arise-above). Issue: The last 3 deploy attempts of the same commit (daac5ea) have failed identically at "Network > Healthcheck" — the deployment sits for the full 5-minute Healthcheck Timeout with zero response ever reaching the configured Healthcheck Path (/api/health), then fails. Deploy logs show the app booting cleanly and the process running fine internally (I can see repeated successful internal log lines for several minutes) — it's specifically the healthcheck prober that never gets a response. Failed deployment IDs: 72b79692-f1c9-450f-a39f-67c016479212 and 70f1efdf-8824-4ca4-ace9-3feb32d95f25 (both same commit, both identical failure). What I've already ruled out: - App-level bug: I built and ran the exact same commit locally (production mode, same start command) and /api/health responded correctly in under 150ms on every request, repeatedly. - - Healthcheck config: Path (/api/health) and Timeout (300s) are both correct and unchanged from previous successful deploys. - - Platform incident: status.railway.com shows fully operational, no incidents. - - Railway's own "Diagnose" AI tool on the failed deployment could not identify a cause. The currently-live deployment (a different, earlier commit, same service/config) is healthy and has been serving traffic fine for 12+ hours, so this isn't a config issue with the service overall — it's specific to redeploying this particular commit. Would appreciate help figuring out why the healthcheck prober can't reach this deployment. Happy to provide more logs/details.

Hi Railway team, I have a custom domain stuck in a failed certificate state on my service pocketpull-website (project 402de62d-d117-495d-9e79-276a0c2c6033, production environment). Domain: pocketpulltcg.com Domain ID: 3e9994c6-03a7-4bf1-bad1-0a53840d6846 Status returned: certificate.status: CERTIFICATESTATUSTYPEISSUEFAILED, error message: "An internal error occurred. Please retry or contact support.", marked retryable: true DNS: the required CNAME (pocketpulltcg.com → 4h9fy4oj.up.railway.app) is confirmed fully propagated and correct — domain ownership shows verified: true. Could you please retry certificate issuance for this domain on your end? I'd rather not delete/re-add it myself given Let's Encrypt's duplicate-certificate rate limit. This looks identical to the resolved thread 'Custom domain stuck at CERTIFICATESTATUSTYPEISSUING for 14 days — DNS correct, retry refused' — same failure pattern, just a different status (ISSUEFAILED vs ISSUING). Could someone manually trigger a certificate re-issuance the same way sam-a did there? Thanks, Red

Description: A secure, lightweight and self-hostable chat platform. Category: Other URL: https://railway.com/deploy/songbird

Custom subdomain has been stuck in CERTIFICATESTATUSTYPEVALIDATINGOWNERSHIP for over a week. CNAME reports DNSRECORDSTATUSPROPAGATED. The required TXT verification record resolves correctly through both Google DNS and Cloudflare DNS and exactly matches the token Railway currently reports. certificate retry refuses because the domain has not progressed past ownership validation. Is there a Railway employee who can re-trigger the ownership-verification workflow? I can provide the domain/domain ID directly if needed.

Memory (per MB / min)Qty 822095208 $190.30$0.000000231481 each

Description: Humans and AI agents together in the tools where your team already works Category: AI/ML URL: https://railway.com/deploy/switch-console

Hi Railway Support, I’m experiencing a recurring issue with Railway trial workspaces and I’d like to understand exactly what is triggering the restriction. My main Railway account works normally and I can successfully deploy my Telegram bot project from GitHub. However, I have two separate accounts that cannot deploy the same project: 1. My friend’s newly created Railway account — the workspace becomes restricted when attempting to deploy. 2. A new Railway account I created myself — the same thing happens. The workspace is restricted and deployments are blocked. The important point is that the exact same GitHub repository successfully deploys on my main Railway account, so this does not appear to be a code/build problem. The affected accounts show messages similar to: “This deployment was blocked before it could build or run because the Railway workspace is restricted.” I have also seen the Trial message: “Limited Trial Workspace. It includes your credit balance of $5. Deployments are shut down when you run out of credits. Add a valid payment method to this workspace to deploy again.” Could you please check the affected workspace/account status and tell me what type of restriction is being applied? Specifically, I would like to know whether this is caused by: - GitHub account verification/trust signals - - Trial eligibility - - Payment-method verification - - Automated abuse/security detection - - A workspace-level policy restriction - - Something related to the repository or Docker image - - Or another account-level restriction I am not trying to bypass any Railway restrictions. I just want to understand the legitimate reason for the restriction and what I need to do to make the account eligible for deployment. The repository is a legitimate Telegram/AI bot project, and it deploys successfully from my main Railway account. If you need the affected workspace ID, account email, deployment ID, GitHub repository, or any other diagnostic information, I can provide it. Thanks. https://github.com/aminsh35322088-ctrl/opencode-telegram-bot

Description: WordPress siap pakai dengan database MySQL terhubung otomatis. Category: CMS URL: https://railway.com/deploy/cms-wordpress-powered-by-sopan

Description: Browser voice AI with OpenAI, Gemini, Grok, OpenRouter, or Ollama. Category: AI/ML URL: https://railway.com/deploy/pipecat