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.
Good communication is at the core of any incident management process, empowering stakeholders with...
What’s just as important as resolving an impacted service? Providing detailed yet digestible...
Here at StatusCast we understand the importance of a resourceful and communicative status page. A...
