System status
Last reviewed: 7 August 2026
Read this first: this page cannot tell you if the site is up.
Novus Examples is a fully static site. This page is prerendered HTML, exactly like every other page — it does not poll anything, it has no backend to ask, and it cannot change between deploys. Publishing a live uptime percentage or an incident feed here would mean inventing numbers, so we do not. What this page can honestly give you is the architecture, what each part depends on, what actually breaks when something fails, where to check the hosting platform yourself, and how to reach us.
The practical version: if you are reading this, the site served it to you.
What each part depends on
| Subsystem | Depends on | What happens if it fails |
|---|---|---|
| Pages and catalog | Static HTML on the CDN | Prerendered at build time. If the CDN serves, every page serves — there is no origin application to fall over separately. |
| File downloads | Static assets on the CDN | Immutable, long-cached files under /files/. Same availability as the pages themselves. |
| Search | Your browser | Runs client-side against an index built at deploy time. There is no search server to time out. |
| Editors and Studios | Your browser | All six creation workspaces run locally. Nothing is uploaded, so nothing server-side can break them mid-edit or mid-generation. |
| Form demo endpoint | One serverless function | POST /api/demo-submit is the only request path that executes code on demand. If it fails, the live form demos stop confirming — nothing else is affected, and it stores nothing either way. |
| Fonts | Nothing at runtime | Typefaces are downloaded at build time and self-hosted, so there is no third-party font request to hang. |
| Analytics and advertising | Google, after consent | Loaded only once the relevant consent category is enabled. Blocked, failing, or disabled, they change nothing about the content. |
| Offline shell | Your browser's service worker | A cached app shell keeps previously visited pages and the offline page rendering with no network at all. |
Why the failure surface is this small
There is no database, no user accounts, and no runtime environment variables or server-side secrets. The catalog is compiled from JSON manifests into static pages at build time, downloads are files on a CDN, and search runs in your browser. That removes most of what normally appears on a status page: there is no connection pool to exhaust, no cache to go stale, no queue to back up, no migration to fail, and no login to lock you out of.
It also means the realistic failure modes are narrow: a hosting or CDN incident, a bad deploy, or your own network. The first is upstream and visible on the platform's own status page. The second we roll forward with another deploy. The third is what the offline page and cached app shell exist for.
Checking upstream yourself
The site is hosted on Vercel, which publishes its own live status. If pages are not loading at all, that is the first place to look:
Advertising and analytics are Google services and are, by design, unable to affect whether the content loads — they are gated behind consent and load after the page. If ads are missing, the content is not broken; see cookie preferences.
Planned maintenance
There is none to announce, and there is unlikely to ever be. Deploys are atomic: a new static build replaces the old one at the edge with no downtime window, no read-only period, and no migration step. Content updates ship the same way.
What this build contains
These figures are counted from the catalog at build time, so they describe the deployment you are looking at rather than a number someone typed in:
- 5,075 downloadable example files.
- 840 published visual templates.
- Content last materially updated: 2026-08-23. This is the date the library content changed, not the date of the last code deploy — the same value the sitemap reports to crawlers for static pages.
Report a problem
If something is broken — a download that 404s, a page that will not render, a preview that never loads — email examples@novusstreamsolutions.com with the URL, what you did, and your browser. We have no error-reporting backend collecting this automatically, so a report from you is genuinely how we find out.
Security issues follow a separate process — see the security policy. Accessibility barriers have their own reporting route on the accessibility statement. Everything else belongs on the contact page.