The three primary goals of a hosted status page are:
Similarly, using a webhook integration, StatusCast pulls designated alerts from PagerDuty, allows you to rephrase them into terms more relevant to your end-users, and sends them out to impacted users via each individual user’s preferred communication channel. As with all status updates in StatusCast, you can program them to send immediately, to send automatically but with a time delay, or to require manual approval before being sent at all.
StatusCast helps you bridge the customer experience gap by sending out alerts based on affected components (meaning only impacted customers receive the communication), and sending them out through the communications channel your customers have identified themselves to be most effective for status updates.
StatusCast is built with a similar idea in mind – though downtime is unlikely, to an extent it is unavoidable. Rather than deny that unpleasant truth, better to be prepared to handle it professionally. By providing the history of uptime on your hosted status page, you are reminding customers when downtime occurs that it is a rare occurrence rather than the norm.
One of the reasons StatusCast was built as a hosted status page tool in the first place was to help IT/DevOps focus on resolving the issues impeding application performance, by taking the burden of communicating about the issue and its resolution off of that team’s shoulders. By working with another team (for instance Marketing) in advance, to ensure the customer-facing alert language is user-friendly but accurate, IT/DevOps can free themselves to focus on what they do best when the need for their timely attention is at its greatest.
Not all status updates are published because of an incident or scheduled maintenance event....
Best practice to prevent stuff happening and for when stuff actually happens! In the IT world,...
IT Stovepipes Got You Down? Smash Your Incident Response Silos with a Corporate Status Page. To...
