VITEC SSR — Control & Protocol

Live state of the SSR node on the VPS. The dot pulses green while the node answers its health check. Delivery shows whether visitors get server-rendered pages; the switch is in the Site settings. The strip shows the last 24 hours in 15-minute windows: green ok, yellow slower than 400 ms, red down, grey no sample. After {failoverAfter} failed checks in a row the cron switches back to the SPA. Alert mails go to the addresses under Site settings › VITEC › SSR alert mail recipients; hover “Alert mail” to see them.

SSR online

Pages are rendered on the VPS Node is ready, but delivery is off: TYPO3 serves the SPA · last check {lastSampleAge} ago

SSR not reachable

{healthError} · after {failoverAfter} failed checks in a row the cron switches delivery back to the SPA
Delivery
ON OFF Site settings via Site settings
Release
{health.release.release}
Commit
{health.release.commit}
Purge webhook
configured not configured
Alert mail
{alertCount} recipients none
Auto failover
after {failoverAfter} failed checks
Availability, last 24 hours · one bar per 15 minutes –
Share of page requests in the last 24 hours that the node answered from its cache, either fresh or stale and refreshed in the background. All others had to be rendered first. Higher is better. It drops after a full purge until the cache is warm again. The arrow compares with the 24 hours before.
Hit rate · 24 h
–%
served from cache or refreshed in the background
The big number is the last check: how long TYPO3 needed to reach the node, measured when this page loads and every 15 seconds after. Median and p95 come from the cron samples of the last 24 hours, taken every 5 minutes. The curve shows the last 4 hours. Values above 400 ms turn the availability strip yellow.
Response time
{health.responseMs}–ms
last check · updates every 15 s
median 24 h – · p95 –
How much of the node page cache is in use: pages and megabytes against the configured limit (SSR_CACHE_LIMIT_MB). When the cache is full, the pages used least recently drop out. After “Purge everything” it falls to almost zero until “Warm cache” fills it again.
Cache fill
{cockpit.cacheMb}/ {cacheLimitMb} MBMB
{cockpit.cachedPages} pages cached
Errors that visitor browsers reported from the React frontend in the last 24 hours. A chunk reload happens when an open tab still runs an older bundle after a deploy; that is usually harmless. JS errors point to a real bug. Test reports (smoke tests, curl) are left out; reports from crawlers like Googlebot count and carry a bot label. The bars show reports per hour, details are in the Client errors card below.
Client errors · 24 h
{clientErrorCount24h}reports
{chunkCount24h} chunk reloads · {jsErrorCount24h} JS errors · {testCount24h} tests left out
Requests per hour, or per 4 hours in the 7-day view, split by how the node answered: served from cache, stale and refreshed in the background, or rendered fresh. The orange line is the response time, red triangles mark purges. Spikes of fresh renders usually follow a purge or a warm run. Source: node counters sampled every 5 minutes.

Traffic and cache

Served from cache Stale, refreshed in background Rendered fresh Response time Purge
Requests
–
Hit rate
–
Render errors
–
Purges
–
Warm cache renders every sitemap page in advance, and the ring shows the progress live. Purge paths drops single pages from the cache, for example after a change the auto-purge did not catch. Purge everything empties the whole cache, which is needed after menu or footer changes and after a deploy; run Warm cache right after. Both heavy actions ask for confirmation.

Actions

Warm cache

–
no run since the server started

Renders every sitemap page in advance, so no visitor waits for a first render. Run it after “Purge everything” or a deploy.

Purge paths

Drops those pages, all hosts and query variants, from the SSR cache. They render again on their next request.

Purge everything

For menu or footer changes while auto-purge is off, and after a frontend deploy.

Every cache purge, newest first. The colour shows the trigger: auto-purge when an editor saves, manual from this module, context menu from the page tree, cli for commands and deploys, switch-on when SSR delivery was turned on. Result and duration are on the right. Switch between 30, 100 and 500 entries.

Purge activity

30 100 500
auto-purge manual context menu cli / deploy switch-on
  1. {row.day_label}
    2.
  2. {row.trigger_label} {row.trigger_who}
    all pages (*) {p}
    + more {p}
    ok HTTP {row.http_code} {row.duration_ms} ms

No purges logged yet. Saving a page, the context menu “Purge from SSR cache” or the buttons on the right create the first entry.
Every report from visitor browsers in the last 24 hours, newest first. Open an entry for release, URL, browser, anonymized IP and stack trace. “old bundle” means the tab ran an older release than the node. Test reports (smoke tests, curl) are counted under Tests but not listed. Reports are limited to 30 per minute and IP and are kept for 30 days.

Client errors

kept 30 days
24 h
{clientErrorCount24h}
Chunk reloads
{chunkCount24h}
JS errors
{jsErrorCount24h}
Tests
{testCount24h}
chunk reload error bot {row.message}{row.path} @{row.crdate}
Reported
@{row.crdate} · entry #{row.uid}
Release
{row.release} old bundlenot transmitted
URL
{row.url}not transmitted
Browser
{row.user_agent}not transmitted
IP
{row.ip} anonymized
{row.stack}

No stack transmitted.

No client errors in the last 24 hours. The frontend reports JS errors and chunk reloads here as they happen.