A free model endpoint is not healthy just because it returns a response. It has three separate health signals: the connection opens, the stream begins producing chunks, and an abort actually stops the bytes. If the second or third signal starts to drift, your real UI will discover it in the worst possible moment—mid-demo, after a deploy, or in front of a keyboard user who cannot see that the spinner has frozen. A small static watchdog page can check all three signals from the same browser environment your users actually have, and report the results in a table that a screen reader can follow.
Disclosure: This article was prepared as part of MonkeyCode's product outreach. I used MonkeyCode's advertised free model endpoint and free static server to host the watchdog file. The 30,000,000-token allowance is their stated offer at the time of writing; I did not verify it independently, and it may change.
The reason to build this as a static page instead of a server-side cron job is not convenience. Server monitoring tools can tell you whether the endpoint is reachable from a datacenter in Virginia, but they cannot tell you whether the stream remains readable after a cancel, whether the first chunk arrives before your loading state gives up, or whether the browser drops the connection after exactly one minute. Those three failures live in the gap between the network tab and the user's perception. A watchdog that runs in fetch inside a real tab can measure all of them with ordinary performance.now() calls, and it can announce the result to a screen reader without firing a single console log.
The page starts with a single button and a live region, deliberately without a disabled attribute. When a watchdog fails, you do not want the browser to drop focus to the document body because someone clicked the only control. Instead the button changes label while a check is running, and it becomes a no-op with an announcement. That preserves the keyboard path and gives assistive technology a predictable place to return to when the result appears. Below the button sits a semantic table, one row per signal, with column headers for the check name, the measured value, and the pass or fail state.
The first check is connection time. The page calls the endpoint with a minimal prompt and records the time from the start of the fetch to the first ReadableStream chunk. If that value exceeds a threshold you choose—say four hundred milliseconds on a typical connection—the table marks it as slow, not failed, because a slow stream is still a stream and should not be treated like a network error. The second check is streaming continuity. After the first chunk arrives, the page keeps a timer between chunks. If no chunk has arrived for twice the previous average interval, the row flips to stream_stalled, and the watchdog cancels the request. The third check is abort behavior. A separate request is started and immediately aborted through AbortController; if the fetch does not settle into an abort state within a short window, the wire is still leaking bytes and your users are paying attention time for nothing.
The JavaScript behind the table is compact but it must separate the three outcomes clearly. The code below uses one async function for a normal stream and one for the abort probe, both writing into rows that already exist in the DOM. The screen-reader announcement lives outside the table so that a new result does not steal focus while the user is still examining the previous row.
<table>
<caption>Free endpoint watchdog results</caption>
<thead>
<tr>
<th scope="col">Signal</th>
<th scope="col">Measured</th>
<th scope="col">State</th>
</tr>
</thead>
<tbody>
<tr id="connection-row">
<th scope="row">Connection to first chunk</th>
<td id="connection-value">not run</td>
<td id="connection-state">waiting</td>
</tr>
<tr id="stream-row">
<th scope="row">Interchunk gap</th>
<td id="stream-value">not run</td>
<td id="stream-state">waiting</td>
</tr>
<tr id="abort-row">
<th scope="row">Abort settlement</th>
<td id="abort-value">not run</td>
<td id="abort-state">waiting</td>
</tr>
</tbody>
</table>
<p id="announcer" aria-live="polite" role="status"></p>
The aria-live region uses polite because a watchdog result is rarely urgent. If you are running the page while debugging, you want the announcement to wait until your current action finishes; if the endpoint is down, a polite message will still arrive before you have time to tab away. The table itself uses th scope="row" on each first cell so that a screen reader can identify which measured value belongs to which signal, rather than reading a wall of numbers left to right.
Building a check around MonkeyCode's free model access made sense because the watchdog consumes only a tiny prompt per run, far below any stated allowance. The free static server gave the file a stable URL, which matters when you want to re-run the check from a phone, a different browser profile, or a colleague's machine without handing them a local file path. I also used the endpoint's actual error shape instead of assuming a status code, because free tiers often return a third-party proxy message with a 200 when the upstream refuses the request. The page checks for a quota string in the response body and maps it to a separate row state, but that string is implementation detail you should confirm against current documentation before copying into your own watchdog.
The limits here are easy to state. A static watchdog page does not run on an interval, does not page you at 3 a.m., and does not replace real uptime monitoring. It is a browser tool for verifying that the endpoint's streaming and cancel behavior still works from a real user environment, which is exactly the kind of failure a server monitor cannot catch. The watchdog also makes one request at a time; if your real UI fires several concurrent streams, this page will not reveal queueing problems because it never builds a queue. Teams that need alerting, historical trends, or multi-client concurrency should use a proper synthetic monitoring setup. A single static HTML file is for catching changes between the day you built the UI and the day the endpoint silently changed its response type.
If you have a free model endpoint and you have not checked whether an abort actually stops the stream, this watchdog gives you the three rows that matter. The value is not in the specific provider; it is in keeping a runnable, keyboard-operable probe close at hand, ready to run the next time a free tier changes underneath your shipped interface. MonkeyCode's free endpoint and static server are one way to try the pattern without setting up a host, but the same table and announcement logic moves to any endpoint and any static file server you already use.
A free server option is enough to reproduce the setup.
Top comments (0)