Your service has CDN caching enabled, so the edge is serving a cached copy from a previous build. Purge the cache from your service's Edge settings (Purge All to clear everything, or Purge HTML for pages only), and the next request will fetch fresh content from the active deployment. To prevent this after future deploys, check that "Purge Cache on Deploy" in the same section is set to purge on each successful deploy.

Adding IDs per the support guidelines:

Project ID: cf07613f-2724-4a25-b4bf-14cabb1004a4

Service Name: pleasant-cat

Service ID: 6d2d956e-b403-4c2c-8e03-fdc53f41e99c

Environment ID: 62daa3b3-fec1-40c9-802e-b82741690134 (production)

Deployment ID: 56063169 (the "Active" deployment showing commit

"Update Open Graph description for SEO")

I checked Settings → Edge → CDN Caching, and the toggle is currently

OFF (screenshot attached). No "Purge Cache" or "Purge Cache on Deploy"

option appears since the feature itself is disabled.

So CDN caching doesn't seem to be the cause here — is there anything

else on the edge/routing layer that could be serving stale content

even with CDN caching turned off? Could this be a stale/orphaned

container still receiving traffic separately from the container the

dashboard shows as "Active"?

To correct our earlier message, CDN caching is not the cause here. Your service has CDN enabled but response caching is off, so there is no stale cache to purge.

What we see in the edge logs is that requests to your custom domain are reaching the current active deployment on the pleasant-cat service and returning 200, so the edge is routing correctly. The content you see IS what the active deployment is serving.

Your workspace has two services both named handle-generator (in different projects), and only the one in pleasant-cat has the custom domain attached. If your recent commits are deploying to the other service, those changes would not appear at your custom domain. Check which project your repo's deploy trigger is connected to.

Ruled out the duplicate-service theory — the second handle-generator

service (project grand-wholeness) had no custom domain attached, so

it wasn't serving gethandlenames.com traffic. I've since deleted that

entire project.

Given your note that "the content you see IS what the active deployment

is serving" — this points to the build itself producing stale content,

not a routing issue. My build logs show several "cached" layer-copy

steps (e.g. "copy /app cached", "copy /app/node_modules cached"). Is it

possible the build's layer caching isn't detecting that public/index.html

changed, and is reusing a stale cached copy of the /app directory into

the final image?

Is there a way to force a clean, no-cache rebuild to test this theory?

Thank you