What the check sees
A page check is an HTTP request. It reads the HTML the server sends, not what a browser builds from it with JavaScript. For a page rendered on the server or at build time, that HTML holds the content, and a required phrase works. For a page that is only rendered in the browser, the HTML is a shell with an empty container, and the status code is 200 whether the data loaded or not. Choose the required text from the shell that is always sent, such as the footer, and put the real proof of the data in an API check on a route you control.
What goes wrong, and which check sees it
Preview and old deployments answer, and may be indexed. Vercel’s documentation says an X-Robots-Tag: noindex header is added to every Preview Deployment so that search engines do not index the preview addresses, and the same to the previous production deployment after a new one is promoted. It also says the header is not set when a custom domain is assigned to a non-production branch. Agencies often do exactly that for a client’s staging site. Run curl -I against the address and look for the header, as Vercel suggests. Beamfar alerts when a page becomes noindex or robots.txt starts to block it; it does not alert that an address is indexable, so staging stays a manual check.
A cached page stays stale. The Next.js documentation describes Incremental Static Regeneration this way: after the revalidation time passes, the next request still gets the cached page, a new one is generated in the background, and if that regeneration throws an error, the last page that was generated successfully keeps being shown. A broken data source can therefore leave a site answering 200 with old prices for days. The status code and the required text both pass. Make your application say so: add a route such as /api/health that returns {"data": "fresh"} when the content is younger than the limit you set and "stale" when it is not, and assert in an API check that the JSON value data equals fresh. The monitor compares a value, so your code decides what fresh means.
A missing path answers 200. A single-page app or a catch-all rewrite can answer every path with the shell. That is a soft 404: search engines see endless pages and visitors see an empty screen. Add an API check on a path that must not exist and expect status 404.
A deploy that built still fails at runtime. A missing environment variable, a failed database connection or a route that throws shows as a 500 on one route while the home page, built long ago, is fine. Add an API check on each route that matters, with status 200 and a response-time limit.
The domain does not point where you think. A custom domain on a hosting platform is usually a CNAME or an alias to a target the platform names. DNS changes by a registrar, a client or a new agency break it. The DNS check records the address records and a change appears on the timeline with its time. See DNS changes that break client websites.
The checks that matter most
| Check | What it catches here | How to set it up in Beamfar |
|---|---|---|
| Page with required text | A 500, an empty shell, the wrong site on the domain | The page check on the production address; text from the footer that is in the sent HTML |
| Health route | Stale data, a failed data source, a missing variable | An API check on /api/health you add: status 200 and the JSON value data equals fresh |
| Missing path | A catch-all that answers 200 | An API check on a path that must not exist, expecting 404 |
| Key routes | A runtime error on one route | An API check on each: status 200 and a response-time limit |
| Search settings | noindex or a robots.txt block shipped with a deploy | Automatic: an alert after a second sighting |
| Sitemap | A sitemap that stopped being generated | The sitemap monitor, within the limits of the plan |
| DNS, certificate, domain | Records changed, expiry | Automatic on every site |
Set it up
- Add the production host name in the portfolio.
- Set the page check’s required text to a phrase that is in the HTML the server sends, then confirm it with
curlbefore saving. - Add the health route to the application and the API check for it. Keep it cheap; it runs every minute from two regions.
- Add the missing-path check and one API check for each route a client would notice.
- Alert the person who can redeploy, and write the previous good deployment’s address in the care notes so a rollback is one step.
What an outside check cannot see
It cannot run your tests, read the build log or see an environment variable. It does not run your scripts, so a failure that happens only in the browser (a JavaScript error after load, a failed client-side fetch) is invisible to it. It does not see traffic that never reaches the site. Keep an error tracker for the browser and the server, and use the monitor for what happens when everything inside the site is silent.
How Beamfar helps
Beamfar is not a plugin for Next.js or for any host. It calls a site down only when two regions agree, runs API checks with assertions on the status, headers, JSON values and response time, records DNS, certificate, redirect and search-setting changes on one timeline and watches the sitemap. It works the same on any host. It has been tried on test pages only and has no customers yet.
Questions
Can an uptime check see a Next.js page that renders in the browser?
Only the HTML the server sends. If the content is added by JavaScript, the check sees the shell, so put the proof in an API route that your application controls.
Why does my site answer 200 with old content?
A cached page is served until it is regenerated, and if regeneration fails the last good page can stay. Expose a freshness value in a health route and assert on it.
Are Vercel preview deployments indexed by search engines?
Vercel says it adds an X-Robots-Tag: noindex header to preview deployments, but not when a custom domain is assigned to a non-production branch. Check the header with curl -I.
Does this apply to Netlify, Cloudflare Pages and other static hosts?
The checks do, because they use only HTTP(S). The preview and header details above come from Vercel’s and Next.js’s documentation; read your host’s own documentation for its behaviour.
Sources
Read on . Standards and vendor pages change; confirm the current text before you rely on it.
- Vercel knowledge base, Are Vercel Preview Deployments indexed by search engines? (read through a search summary of the page) (vercel.com)
- Next.js documentation, Incremental Static Regeneration (read through a search summary of the page) (nextjs.org)
- Google Search Central, Block Search indexing with noindex (developers.google.com)