Content plane operational
Last checked SGTAvailability of the static, media, streaming and download endpoints. This page covers the content plane only. Sign-in, the console and the portal APIs are the control plane and are reported separately on the service status page — the two are deliberately independent, so a traffic surge on one is never a symptom on the other.
Endpoints
Separate hostnames, separate cache policies and limits| Endpoint | Serves | Cache policy | Hit ratio | p95 TTFB | State |
|---|---|---|---|---|---|
| static.nbcdn.example | Hashed CSS, JS, fonts, icon sprites | max-age=31536000, immutable |
99.8% | 21 ms | Operational |
| media.nbcdn.example | Image renditions, thumbnails, posters | max-age=604800, stale-while-revalidate |
97.1% | 34 ms | Operational |
| stream.nbcdn.example | HLS manifests and media segments | segments immutable · manifest 60 s |
94.2% | 42 ms | Elevated misses |
| dl.nbcdn.example | Packages and archives, range requests | max-age=31536000, immutable |
92.6% | 58 ms | Operational |
| origin-media.nb.internal | Object store behind the shield | not publicly reachable |
— | 96 ms | Operational |
| portal.northbay.example | Control plane — pages, session, APIs | no-store |
— | 61 ms | See service status |
Edge locations
7 PoPs · anycast| PoP | Region | Hit ratio | p95 TTFB | Egress | State |
|---|---|---|---|---|---|
| pop-sin-2 | Singapore | 98.1% | 18 ms | 1.6 Gbps | Healthy |
| pop-hkg-1 | Hong Kong | 97.4% | 24 ms | 0.6 Gbps | Healthy |
| pop-syd-1 | Sydney | 96.8% | 31 ms | 0.3 Gbps | Healthy |
| pop-fra-1 | Frankfurt | 89.2% | 46 ms | 0.5 Gbps | Refilling |
| pop-lhr-1 | London | 90.6% | 44 ms | 0.2 Gbps | Refilling |
| pop-iad-1 | Virginia | 97.9% | 29 ms | 0.4 Gbps | Healthy |
| pop-sjc-1 | San Jose | 97.2% | 33 ms | 0.2 Gbps | Healthy |
Origin & shield
- Shield PoP
- pop-sin-2
- Shield hit ratio
- 78.4%
- Origin requests
- 1.3% of total
- Origin 5xx
- 0.02%
- Storage
- Object store · 1.9 TB
- Replication
- AP-East → EU-West
Only the shield may reach the origin. A cold PoP therefore costs one shield request, not one origin request per location.
Purge queue
Idle- Queued
- 0
- Last purge
- 2026-08-03 21:14
- Scope
- 1 manifest path
- Propagation
- 8 s to all PoPs
- Purges this month
- 3
A low purge count is the goal, not a coincidence: versioned paths mean new content gets a new URL, so invalidation is reserved for mistakes and takedowns.
Why this page is separate
Bulk content and the control plane fail differently, scale differently and are read by different people. Keeping them apart means:
- Separate hostnames. Cookieless domains for content, so no session data rides along with a 6 GB image, and a compromised cache cannot see portal cookies.
- Separate capacity. Streaming and downloads never share connection pools, worker threads or bandwidth budget with sign-in and the console.
- Separate limits. Rate limiting on the control plane counts requests; on the content plane it shapes bytes per client.
- Separate blast radius. A saturated edge degrades playback start times. It does not slow the login page, and this page says so explicitly instead of leaving people guessing.
The full architecture, including the cacheability matrix, is documented in Documentation → Content delivery.
Delivery incident history
Last 60 daysAccept-Ranges header, breaking resumable transfers for 26 minutes. Rolled back; a synthetic range check now runs every minute.