How Cascade publishing reaches your live website

An editor fixes a typo on the admissions page, clicks Publish, and refreshes the live site. Sometimes the fix is there in seconds. Sometimes it takes a few minutes, and occasionally it never shows up at all. The difference is almost never Cascade itself. It is what happens in the five steps between the Publish button and the visitor's browser. Knowing those steps turns "the publish didn't work" into a question you can answer in a couple of minutes.

The five steps of a publish

1. Render. Cascade takes the page, applies its template, formats, and blocks, and produces the final HTML. Files such as images and PDFs are passed through as they are.
2. Queue. The rendered items wait in Cascade's publish queue. A single page moves through quickly. A folder or a full site can sit behind other jobs.
3. Transport. Each item travels to the destination over the site's transport, typically SFTP, FTPS, or Amazon S3. The destination and transport settings in Cascade decide where the file goes and how.
4. Origin. The file lands on the production web server or storage bucket. This is the copy that actually exists on your live website.
5. Edge. A content delivery network (CDN) keeps cached copies close to visitors. Until the cached copy is refreshed, some visitors may still see the previous version.

Who owns each step

Hannon Hill runs Cascade as a SaaS product, so rendering and the publish queue are on their side. Everything from the transport onward is hosting. If your site uses eWay's Cascade Website Hosting, that half is eWay's responsibility. The line is clean: Hannon Hill ends at the publish destination, and eWay begins there.

Finding where a publish stopped

Work from the Publish button outward. Each check rules out one step.

1. Check the publish report in Cascade. If it shows render errors, the problem is in the content or template, not the hosting. Fix the reported asset and publish again.
2. Check the queue. If the job is still listed, it has not finished. A large publish ahead of yours is the usual reason.
3. Check for transport errors. Connection refused, authentication failed, or timeout messages in the report point to the transport. These need the hosting team.
4. Check the origin and the edge together. Response headers show whether the server has the new file and whether the CDN is serving a cached copy:

   curl -sI https://www.example.edu/admissions/ | grep -iE "last-modified|age|x-cache"

   A Last-Modified time earlier than your publish means the file never reached the server. A recent Last-Modified with a cache hit and a large Age means the server is current and the CDN is not.
5. Rule out your own browser. Open the page in a private window or on your phone over cellular data. If it is correct there, the stale copy was in your browser cache.

Why static output matters

Cascade publishes finished files, not a running application. That is a real advantage. There is no database to query on every page view and no plugin code running for each visitor, so the published site is fast and has a small attack surface. It also means your content is safe in Cascade even if the web server has a bad day. Republishing regenerates the site.

The exceptions are the dynamic features a static site still needs: site search, forms, program finders, calendars, and anything that calls a campus system. Those run as separate services alongside the published files, and they are usually where performance and reliability work is needed.

How eWay operates the hosting side

eWay builds the publish destination around how Cascade deploys. Publishes arrive over dedicated network paths so they do not compete with visitor traffic, and the file system is sized for large publish jobs, not only for page views. When a publish completes, CDN invalidation (CloudFront on AWS, Azure Front Door on Azure) runs automatically. Monitoring watches the transport, the origin, and the edge, alerts the on-call engineer when a publish fails or finishes partially, and triages incidents within 15 minutes, 24 hours a day.

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 the destination you published to
• The time of the publish and what the publish report says
• One or two URLs showing the wrong content, and the header output from the check above if you ran it

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: why a Publish All can slow down or fail and CDN caching and cache invalidation for Cascade sites. For the full hosting picture, see Cascade Website Hosting.