Live blog hosting for seconds-old news at full scale.
Everything about caching assumes content stays still. A live blog changes every ninety seconds while fifty thousand people watch the same URL.
Fresh and cached at the same time.
The two requirements look mutually exclusive, and reconciling them is the only interesting problem here.
A cache measured in seconds, not hours
The page is cached hard, but only briefly, and purged the moment an entry is posted. Readers get a shared response that is never more than a few seconds behind the newsroom.
Thousands of readers refreshing one page
A live blog concentrates an entire audience on a single URL, and many of them poll for updates. That polling is the real traffic and it is served from the edge.
Publishing that jumps the queue
A journalist posting an update during peak coverage must not wait behind reader traffic. Editorial requests get their own capacity, because the whole point is being first.
Entries appended, not rebuilt
A long live blog is hundreds of entries on one post. Updates append rather than re-rendering the whole thing, so the two-hundredth entry costs what the first did.
The archive is the record
When coverage ends the page becomes the historical account and keeps attracting traffic for years. It is retained and backed up as content, not cleared as an event.
Caching against a moving target.
Cache it for an hour and the coverage is useless. Do not cache it and the origin melts under fifty thousand readers. The answer is a very short window plus an immediate purge.
- Short cache window with purge on publish
- Reader polling absorbed at the edge
- Editorial requests prioritised over reader traffic
- Entries appended rather than re-rendered
Seconds behind, at any scale.
The number that matters is the gap between a journalist pressing publish and a reader seeing it, measured while the audience is at its largest.
What we change for live blogs
Every row is a compromise between freshness and scale, which on a normal site never have to be traded off at all.
| Setting | What we do | Why |
|---|---|---|
| Cache window | Seconds during coverage, purged on every publish | An hour-long cache makes live coverage pointless and no cache melts the origin, so the only workable answer is a very short window with immediate invalidation. |
| Reader polling | Served from the edge as the primary traffic | A live blog concentrates the whole audience on one URL and many of them refresh continuously, so polling outweighs page views by a wide margin. |
| Editorial requests | Prioritised ahead of reader traffic during coverage | The value of a live blog is being first, and a journalist queuing behind fifty thousand readers to post an update defeats the format. |
| Entry rendering | Appended rather than rebuilding the full post | Coverage runs to hundreds of entries, and re-rendering all of them per update makes the site slower the longer the story goes on. |
| Post-event retention | Kept as an archive rather than cleared | Once coverage ends the page becomes the historical record and keeps earning traffic, which is exactly when people delete it as an expired event. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Can a live blog be cached?
Why is the site slow when a big story breaks?
Do updates from journalists get delayed?
What happens to the page after coverage ends?
Publish now, serve everyone.
Move the newsroom across. Migration is free, archives included.