After a hosting provider allowlisted several REST API paths, Site Health stopped reporting the timeout — read at first as “the problem is fixed.” Around the same time, a direct, unauthenticated request to a REST endpoint returned “Forbidden context” instead of data, which at first glance looked like another failure. Testing directly: the site root REST endpoint returned valid JSON, the posts endpoint returned an empty array, and the edit-context endpoint returned “Forbidden context” rather than timing out.
How to Read a Test Result Correctly — Success vs. Error vs. Timeout
Field Note #286
⚡ Quick Fix (TL;DR)
The Culprit: "Forbidden" is fundamentally different from a timeout — it means the server received the request and applied its own authorization rules, proving the server is alive and processing correctly. A timeout with zero bytes received means the request never got a response at all. Separately, the later recurrence of the same timeout showed that one successful test only proves the endpoint was reachable at that moment, not that an intermittent problem is gone for good.
The Fix: Recognizing "Forbidden" as a working, authenticating server rather than a new failure, and treating the earlier clean test as a snapshot rather than a permanent fix — continuing to monitor rather than closing the issue out.
Rather not untangle this yourself? Our Done-For-You team handles exactly this kind of thing, start to finish.
See DFY options → Was this helpful? Thanks for the feedback!
Tagged in :