A new HubSpot page 404s for a minute, and that is normal

Three new pages, created over the API. Create returned 201. Publish returned 200. All three URLs returned 404.

They came back together roughly 30 to 60 seconds later, with nothing else done to them.

Why this is worth knowing rather than just waiting out

Because there is a genuinely broken state that looks exactly the same from outside, and the fixes are opposite. One needs a config change. The other needs you to leave it alone.

If you assume propagation and it was a real fault, you wait and then debug. Mildly annoying. If you assume a fault and it was propagation, you start changing publish state and template paths on a page that was about to work, and you can break it for real. That is the expensive direction, and it is the one people take, because doing something feels more responsible than waiting.

How to tell them apart

Fetch the page object and compare it, field by field, against a page you know works.

domain:      ""
state:       PUBLISHED_OR_SCHEDULED
currentState: PUBLISHED
publishDate: a real ISO timestamp, not 1970
language:    "en"
templatePath: the template you uploaded

If every field matches a known-good page, wait before changing anything. That comparison is what separates the two cases, and it takes one request.

The publish date is the field that most often gives away a real problem. A 1970 timestamp means the publish did not take, whatever the response code said.

What to do in a deploy script

Poll until 200 rather than sleeping a fixed guess. A fixed sleep is either too short, which puts you back into false diagnosis, or too long, which you pay on every page forever.

Budget about a minute per page before anyone looks at a URL, and never report a fresh page as broken off a single request.

The thing this contradicts, deliberately

There is a well-earned instinct that a 200 on publish is not evidence, because HubSpot has a genuine trap around publish states where the API reports success and the page really is broken.

That instinct is correct, and it is exactly wrong here. For a brand new page, the 200 is fine and the 404 is temporary.

Two failures that look identical, with opposite fixes, is a good argument for checking the object rather than trusting a rule of thumb. Rules of thumb are how you end up confidently applying the wrong one.