Skip to main content

Cascade Website Hosting

Monitoring and uptime for Cascade-published websites

Last updated Fri, Jul 10, 2026

A homepage that loads is not the same as a website that works. A Cascade site can return a perfectly healthy homepage while a failed publish has left the admissions section half-updated, the certificate has nine days left, and the program finder is timing out. Good monitoring watches for all of those, and it does so from outside your network, the way visitors see the site. This article explains what gets watched, why, and what to do when you think the site is down.

What "up" means for a static publish target

Cascade publishes finished files to a web server or storage bucket, and a CDN delivers them. That design is resilient: there is no database behind each page. It also means failures tend to be partial rather than total. The useful question is not only "does the homepage respond?" but "is the right content being served, quickly, securely, to everyone?"

The signals that matter

SignalWhat it catches
Availability checks from several locationsOutages, and regional problems that only affect some visitors
Content checks on key pagesA page that returns 200 but shows an error message or the wrong content
Error rates (4xx and 5xx) at the CDN and originBroken links after a restructure, origin failures hidden behind the cache
Response time against a baselineSlowdowns before they become outages
Publish completionFailed or partial publishes that leave stale or missing pages
Certificate expiry and DNS resolutionThe slow-building failures that otherwise surface as browser warnings
Dynamic services (search, forms, feeds)The parts of a static site that can fail independently
Server resources (disk, inodes, CPU, memory)Capacity problems, especially around large publishes

Why one failed check is not an alert

The internet is noisy. A single check can fail because of a brief network hiccup between the monitoring location and your site. Paging an engineer for every blip trains everyone to ignore alerts. Well-tuned monitoring checks at a short interval from several locations and alerts when failures repeat, or when several locations agree. That is fast enough to catch real outages within minutes and quiet enough that every alert gets attention.

Checking a suspected outage yourself

  1. Try another network. Load the site on your phone with Wi-Fi turned off. If it works there, the problem may be your campus network, DNS, or firewall rather than the website.
  2. Check more than the homepage. Try two or three deep links in different sections.
  3. Look at the status code:
    curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" https://www.example.edu/
    A 200 with a normal time means the site is serving. A 5xx means a server-side problem. A timeout or connection error points to network, DNS, or a wider outage.
  4. Check DNS: dig +short www.example.edu. No answer, or an unexpected address, means the problem is DNS.
  5. Note the time. Exact times make it much faster to match your experience to monitoring data and logs.

Reading uptime numbers honestly

Uptime percentages sound similar and are not. At 99.9 percent, a month allows roughly 44 minutes of downtime. At 99 percent, it allows about seven hours. How uptime is measured matters as much as the target: what is checked, from where, how often, and whether scheduled maintenance counts. Your service agreement defines the target and the measurement for your site. Ask for both, not just the percentage.

Common questions

  • Can we see the monitoring? Ask for it. Regular reports showing availability, incidents, and response times should be part of any managed service, and you should be able to see the history behind them.
  • Does scheduled maintenance count as downtime? Usually not, if it happens in an agreed window with notice. That is why maintenance windows should be agreed in writing and kept away from your busy dates.

How eWay monitors Cascade sites

eWay runs 24/7 monitoring across availability, performance, security, and Cascade-specific signals, including publish failures, partial publishes, and CDN anomalies. Alerts go to an on-call engineer, not a shared inbox, and incidents are triaged within 15 minutes around the clock. Monitoring covers the dynamic services around your site as well as the published pages, and scheduled maintenance happens in agreed low-traffic windows, never during registration or the start of term. Trends from monitoring feed regular reviews, so recurring issues get fixed at the cause rather than acknowledged each time.

What to include in a support ticket

  • The severity you would assign, P1 to P4 (see severity levels and response times)
  • The URLs affected and whether the homepage also fails
  • The time you noticed and whether it works on another network
  • The status code or error message, and the curl and dig output if you ran them

A site that is fully down is a P1: submit the ticket, then call 877-487-3929 (8am to 5pm ET, Monday to Friday) so an engineer engages immediately. 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 backup, restore, and disaster recovery for Cascade sites. More at 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

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article

Platform Notes

Get practical WebOps and cloud insights in your inbox

We publish articles on managed operations, cloud infrastructure, CMS platforms, government technology, and security, written by engineers who operate these environments every day. No marketing fluff. Unsubscribe any time.

We respect your privacy. No spam, no third-party sharing. Unsubscribe any time.