It is the week before orientation. Your team has refreshed the site header, so someone starts a Publish All on a 40,000-asset site at 10 a.m. Two hours later the job is still running, the publish report is a wall of transfer errors, and half the site shows the new header while the other half does not. This article explains why large publishes fail, how to tell which failure you are looking at, and how to plan a full-site publish that finishes cleanly.
What a Publish All actually asks of your hosting
A Publish All has two halves. Cascade renders every page, file, and asset in the site. Then each rendered item travels through the site's transport (usually SFTP or Amazon S3) to the publish destination, where it is written to disk and served to visitors. Rendering happens inside Hannon Hill's Cascade SaaS. Everything from the transport onward is your hosting.
That second half is where most trouble starts. A 40,000-asset site means 40,000 separate transfers and 40,000 file writes in a short window. Most web hosting is sized for the opposite pattern: many reads from visitors and very few writes. A Publish All flips that pattern for an hour or more, and a server that handles enrollment-day traffic comfortably can still buckle under it.
The four ways it goes wrong
| What you see | Likely cause | Where the evidence is |
|---|---|---|
| Publish runs for hours, then times out partway through | Connection or queue limits on the transport endpoint | Publish report: repeated connection or timeout errors on consecutive assets |
| "No space left on device" errors while the disk still has free space | Inode exhaustion | Server metrics; only your hosting provider can see inode usage |
| Transfers start fast, slow to a crawl, then get refused | The destination's anti-abuse rules flag the burst of writes as an attack | Publish report: errors cluster after a specific point in time |
| Cascade reports success, but some pages still show old content | Files silently not delivered, or a stale CDN cache | Response headers on the affected pages (see below) |
Inode exhaustion catches people off guard. Every file on a Linux file system consumes one inode, and the number of inodes is fixed when the volume is created. Sites with large image libraries, generated thumbnails, PDFs, and XML feeds can run out of inodes long before they run out of gigabytes. When that happens, writes fail no matter how much space the dashboard says is free.
How to check a page after a large publish
Two different problems look identical in a browser: the file never arrived, or it arrived and the CDN is still serving an older copy. The response headers tell them apart:
curl -sI https://www.example.edu/admissions/index.html | grep -iE "last-modified|age|x-cache"
- Last-Modified is older than your publish: the file on the server is old. The publish did not deliver it. Republish that folder.
- Last-Modified is recent, but X-Cache shows a hit and Age is large: the new file is on the server and the CDN is serving a cached copy. The cache needs invalidating.
Spot-check five to ten pages from different sections, not only the homepage. The homepage is usually the first page refreshed, so it is the least useful test.
Planning a Publish All that finishes cleanly
- Confirm you need one. A change to a shared header, footer, or template touches every page and does need a full publish. A stylesheet or script change usually only needs that file, and a section redesign only needs that folder.
- Pick the window. Early morning or evening, away from application deadlines and registration opens. Check the Cascade publish queue first so you are not stacking behind another large job.
- Pause other publishes. Ask editors to hold while the job runs. Simultaneous publishes compete for the same transport connection and slow each other down.
- Tell your hosting team ahead of time. Share the approximate asset count and the planned window so capacity can be confirmed and someone is watching.
- Read the full publish report. Scan past the summary for individual errors, and republish any failed folders.
- Spot-check with the header test above.
How eWay's Cascade Website Hosting handles it
eWay builds the publish destination for this workload rather than adapting general-purpose hosting to it. Cascade publishes over dedicated network paths, so a large job does not compete with visitor traffic. File system capacity is pre-warmed and sized for full-site publishes, which keeps inode limits and write throughput out of the picture. The publish connection is not subject to the anti-abuse throttling generic hosts apply.
When a publish completes, CDN invalidation (CloudFront on AWS, Azure Front Door on Azure) runs automatically, so visitors get the new version without anyone filing a cache-clear request.
What to include in a support ticket
- The severity you would assign, P1 to P4 (see severity levels and response times)
- The Cascade site name and publish destination
- When the publish started, and whether it is still running
- The errors from the publish report (a screenshot is fine)
- Two or three URLs still showing old content
With those four details, an engineer can usually identify the failure mode on the first pass. eWay customers can open a ticket in the support portal or email support@ewaycorp.com at any time. See how to request support for all the options. Related reading: CDN caching and cache invalidation for Cascade sites and handling enrollment traffic spikes on Cascade sites. For how eWay engineers the publish target, see Cascade Website Hosting.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article