Break it on purpose

The fastest way to learn how render-debug works is to give it something real to chew on. You’ll introduce the single most common production-on-Render failure: a service that binds to 127.0.0.1 instead of 0.0.0.0.

It looks fine locally. Browsers from your laptop hit localhost:8000 and it works. On Render, the load balancer sits on a different machine and tries to connect from outside the container - the loopback interface refuses, and the deploy fails with a polite-but-frustrating message.

1. The diff

Open render.yaml and remove --host 0.0.0.0 from the web service’s start command. That’s it. One change.

- startCommand: uvicorn main:app --host 0.0.0.0 --port $PORT
 

 
+ startCommand: uvicorn main:app --port $PORT

2. Push and watch it fail

git add render.yaml
git commit -m "feat: tighten uvicorn binding (do not merge)"
git push

autoDeploy: true on the web service means Render starts a new deploy as soon as the push lands. Either watch it from the Render Dashboard or stream logs from your terminal:

render logs --resources tinylink-web --tail

Within a minute or two you’ll see the canonical failure:

==> Running 'uvicorn main:app --port $PORT'...
INFO:     Uvicorn running on http://127.0.0.1:10000 (Press CTRL+C to quit)
INFO:     Application startup complete.
==> No open ports detected, continuing to scan...
==> Detected service running on port 10000 - unreachable (only listening on 127.0.0.1)
==> Timed out
==> Exited with status 1 while building your code.

The build succeeded. The container started. The app even printed “Application startup complete.” But the load balancer can’t reach it, so the deploy is marked failed and Render keeps the previous version live.

That’s the most insidious thing about this failure: nothing in the application logs looks wrong.

3. Confirm the previous version is still serving traffic

Render does the right thing here - the failed deploy doesn’t take production down. Hit the public URL and you’ll still get the working version from before the diff:

$curl https://tinylink-web.onrender.com/healthz
{"status":"ok"}

That’s deliberate. Failed deploys don’t cut over. The new version sits as a failed deploy in your history, and the last green deploy keeps serving until you fix things.

4. Hand off to the agent

Resist the temptation to fix it yourself - you’re using this failure to drive the next step. Open the agent and prompt:

The latest deploy of tinylink-web is failing. Can you take a look?

That’s all the context the agent needs. In the next step you’ll watch it diagnose, propose a fix, and redeploy - entirely through the plugin.