Common ways published Replit apps break
From Replit's own troubleshooting docs. Under each one, “Heedza sees this” means the problem stops a page from opening or removes its form, so you get an alert. Heedza only sees what a visitor sees before logging in, so it can’t see problems that happen after a form is sent.
- Secrets didn't come along. "Secrets you set in the Project Editor do not automatically carry over to your published app." Missing secrets can cause "login errors, or payment failures" (Replit: Troubleshoot publishing). Heedza sees this only if a page stops opening. It can’t see a log-in that fails after the button is pressed, because it never logs in.
- Static deployments have no secrets. "Secrets are available for all deployment types except Static Deployments" (Replit: Secrets). Heedza sees this only if a page stops opening.
- The server listens on the wrong address. Your app is set to answer only on your own computer, not on the internet. Replit says it "must listen on 0.0.0.0. Listening only on localhost or 127.0.0.1 does not work for published apps." With ports set in
.replit, you needexternalPortset to 80 (Replit: Troubleshoot publishing). Heedza sees this. - A slow homepage fails the health check. "If your homepage takes more than five seconds to respond, the health check can time out and publishing can fail at the final step" (Replit: Troubleshoot publishing). Heedza can’t see the cause. You only notice that your change isn’t on the live site.
- Hard-coded localhost URLs and unrun migrations. Replit lists these, plus missing production secrets, as the main reasons a deployed app fails (Replit: Networking and app errors). Heedza sees this.
- A crash shows as an error page (code 502). "A 502 usually means your app process crashed" (Replit: Networking and app errors). Heedza sees this.
- The publish succeeded but the app returns 500. Replit says the issue is then in your app code; you can redeploy the last working version from Publishing → History (Replit: Deployment and publishing). Heedza sees this.
What Heedza checks
Heedza works from the outside, on your public web address. There's nothing to install.
- Your key pages. We open your home page the way a visitor does, follow its links to your sign-up, log-in and payment pages, and check on a schedule that each one opens and shows its form or Pay button.
- Security checks. The free scan looks for secret keys in your page code and
.envor.gitfiles anyone can open. - Alerts. When a check fails, you get an alert (by email, or on paid plans also Slack, Telegram or a webhook (we send the alert to a web address you choose; for developers)) with a picture of the page and a fix written for Replit, ready to paste into the Replit chat.
It never fills in forms, never logs in, never types a card number and never clicks Pay. So it can't tell you whether a log-in, email or payment works after the button is pressed.
It works the same for any vibe-coded app, whichever AI tool made it. Build Replit apps for clients? See Heedza for agencies: up to 30 client sites, with white label client reports and status pages on Business.
Fix it for me (Pro and Business)
Some alerts have a Fix it for me button. Nothing starts until you press it. Heedza then writes the fix and suggests it on GitHub (a pull request). Nothing changes in your app until you approve it, and you can undo it.
It works for a page Heedza checks that stopped working (such as sign-up, log-in or payment), a file that should not be public, and a security setting your site stopped sending. It needs your app’s code in a GitHub project (repository), with the Heedza GitHub app added to it. Other alerts come with a fix to paste into your AI tool. How Fix it for me works