We’re happy to announce today that we’re launching double opt-in for StatusPage subscribers. This should make the StatusPage experience even better for page owners, team members, and subscribers.
Now when people subscribe to email updates on your status page, they’ll receive a confirmation email. They will need to click a confirmation link on this email before they receive future updates from your page.
This should help with account security and cut down on potential spam accounts. It should also help our emails deliver even faster and more reliably. As a page owner, we hope it gives you peace of mind knowing that there’s a real person behind all those email addresses in your subscriber log.
You’ll also notice we’re going to be rebuilding the way we display subscribers in your account’s subscriber table. You’ll be able to easily see who has signed up, who has confirmed and who hasn’t.
The change only takes effect for new subscribers. People who previously subscribed before now won’t need to opt in.
We've heard a lot of great customer stories at StatusPage over the years. From the support team who cut customer wait times in half, to the security company managing incident communication across 46 customer deployment groups, we know our customers see the value in their StatusPage account.
We're always hungry to know more about what our customers think of the product, this year we launched our first ever customer survey. Our goals were to better understand the value our customers see from StatusPage and learn how different areas of their organizations benefit in different ways.
More than 300 different StatusPage page owners responded, giving us a great set of data on how modern teams use StatusPage to make incidents less painful.
We are thrilled with the feedback and results. Here are the top five findings:
Integrating StatusPage with chatops tools like HipChat and Slack is a great way to keep your team informed about incidents. It ensures everyone gets the message, it prevents costly context switching, and it gives the team a platform for discussing the incident.
Taming the firehose with ChatOps Filters
But, in reality, sometimes your status page information isn’t relevant to the whole team. While your engineers need to be up to speed on every detail of every incident, your sales team might only need high level updates on specific components.
That’s why we’ve added ChatOps Filters for HipChat and Slack, allowing you to customize the types of messages piping into your chat rooms. If you've ever wanted to do things like only send scheduled maintenance notifications to a scheduled maintenance room or only send component updates on your API to an API room, you'll want to take a look at the feature.
ChatOps Filters let's you open up StatusPage updates within chat to teams who otherwise may have been lost in the noise.
If you're using HipChat, you'll want to head to your admin panel, scroll down to integrations, and add the StatusPage integration. From there, you can configure your StatusPage ChatOps Filters per room. For the full walk through, take a read through our knowledge base article.
As a Slack user, you can configure your ChatOps Filters per channel directly within the StatusPage ChatOps panel. Feel free to read through the integration guide and let us know if you have any questions!
Answering the same question twice is annoying. How about answering the same question hundreds, or even thousands of times? Just plain crazy, right?
Unfortunately, that’s what a lot of support and IT teams put themselves through whenever there’s a service outage. “Is this thing broke” tickets start flying in, and pretty soon your team is buried just trying to keep up. A bunch of versions of the same question come in, a bunch of versions of the same answer go out.
But what if your team could answer everyone at once? What if your users found what they were looking for before even filing a support ticket? Sounds like the kind of thing that would save a lot of wasted time.
Announcing our first JIRA Service Desk integration
The combination of using JIRA Service Desk and StatusPage is the perfect fit for support and IT teams focused on hitting SLAs and managing the queue during downtime. The new free add-on for JIRA Service Desk cloud users helps teams by surfacing status information from your status page directly onto Service Desk portals.
This can be helpful during common system events, including:
- Open Incidents
- Degraded Services & Components
- Active Scheduled Maintenance
With the add-on installed, a banner appears at the top of your JSD portal whenever you open an incident on your status page.
Visitors can click on this banner to go directly to the StatusPage, where they can see more information about the incident.
And even subscribe to updates on the incident — and future incidents — via email and SMS.
Why use the integration?
Downtime is a fact of life for web companies. When it happens, your team and users are going to want to know what's going on. Diverting them to your status page within JIRA Service Desk will prevent a support nightmare before it even starts.
When your users see that there is a dedicated home for updates on the incident, they’re less likely to all file the same ticket. This also helps them get in the habit of checking your status page for incidents in the future and also receiving proactive notifications through StatusPage, which means even fewer inbound tickets down the road.
Whether you're using JIRA Service Desk for internal IT support or external customer support, enabling the StatusPage add-on is the easiest way to reduce the flood of support tickets during an incident.
How to get started
Existing JSD and StatusPage customers can visit our marketplace listing to learn more and install the add-on for free. If you're an existing JSD user, but don't have a StatusPage yet, create your free trial to get started! You can learn more about setting up the integration with our help article.
We'd also love to hear from anyone as we continue to enhance the integration. Feel free to reach out to us directly at firstname.lastname@example.org with any product feedback.
We built StatusPage to help companies that host a web service communicate publicly with their end users.
It was a big need for us and we hope it’s been a big help for our customers. But along the way we discovered another need that was out there. Often times you need to communicate with your internal team without alerting your public subscribers.
Maybe it’s sensitive, internal data. Maybe it’s internal tools your organization uses that wouldn’t be relevant to the outside world or maybe it's the status of your internal VPN. Whatever the reason, it’s helpful to have a private status page once tapping on the shoulder of your IT Admin or Ops Manager no longer cuts it.
That’s why we made it easy for our public page customers to activate an additional private page.
To create an additional page, click the page drop-down in the top navigation bar in your StatusPage account and select "Add Another Page." The new page will be in trial mode until you select a plan to activate it.
Each page you add has its own subscription under your account. This is helpful if you’re a heavy user of public pages, and need a bigger plan with a lot of subscribers, but have a smaller use case for your private page.
After you create your additional page, you can toggle between managing your pages through the drop-down at the top of the screen.
If you're already a private page customer, you can easily use the same process to add a private page. Even if you don't have much public-facing technology, it’s worth having a dedicated place to talk to the public in the event of a major incident. By default, your public page trial will be in a free sandbox mode until you want to launch to your users. To launch, simply choose the subscription that works the best. Once activated, your page will be publicly available for your customers to view status and subscribe to notifications.
With the public page, you might also want a place to show off uptime and system performance. Using Public Metrics, you can display this high-level data on your public status page, while keeping the individual outage reports within your team.
If you have any questions with adding a private or public page to your account, just give us a shout at email@example.com!
Learning new ways to use StatusPage can be a little tricky. Unlike a lot of other tools you probably use, testing new functionality and training new team members on StatusPage has an extra layer of caution. You don’t want to accidentally alert all your customers or team about an incident, when you’re really just testing something out. Or showing a colleague how the tool works.
Since we don’t want you to ever be afraid to get your hands dirty trying out new features or designs or showing your team how StatusPage works, we recommend almost everyone set up a test page. A test page gives you a sandbox for testing and training with StatusPage outside of your production environment.
Adding a test page is pretty simple. Start by clicking the page drop-down and clicking Add Another Page. This new page will be in "trial” mode and hidden from the public unless you select a payment pan to activate it. If you never activate it, you’ll always see it available as a separate page. Name the page “Test page” or whatever helps you know this page is not a production environment.
Now you’ll always have this page available to run tests on, free of worries that you’ll accidentally broadcast a misleading message on your public page.
When you're using StatusPage, sometimes you'll need to look up specific subscribers or past incidents. This is now faster and easier than ever thanks to our new search feature. You'll see the new search bar at the top of your page on the Incidents and Notifications pages.
For example, say you have a colleague who wants to know if they're subscribed to your page. Or you have a customer who requests you delete their subscription. In the past, you would have had to scroll through multiple pages of subscribers to try to find the subscriber in your list. This could have taken a really long time if you have a lot of subscribers. Now, simply start typing their email (or phone number for SMS subscribers) in the search bar and they'll come up right away.
You can also look up old incidents. On your Incidents page, search for any words from the title or body of your incident. This is especially helpful if you need to look up an old incident but don't recall the date. Or if you don't want to flip through pages of old incidents to find a specific one.
Today we’re happy to announce that we’ve added a new option to component statuses, the “Maintenance” state.
Dating back to the public launch of StatusPage, components have only ever had four possible statuses: Operational, Degraded Performance, Partial Outage, and Major Outage. These four statuses serve us well during unplanned downtime, but they don't adequately describe the state of your stack when you’re having a scheduled maintenance.
Though your website might be completely unavailable during a maintenance, giving it a “red” status of Major Outage just feels wrong. The color and the wording make it seem like you've been caught off-guard, and you're scrambling to get things fixed. Furthermore, you've probably already communicated the scheduled maintenance to affected users ahead of time, making this state of "alarm" even more unnecessary.
This is why we've added "Maintenance" to the list of possible states that a component can be in. It communicates that the component (could be a specific feature, or an entire region of data centers) is currently unavailable but for a good reason.
We started StatusPage with one goal in mind - increasing transparency between software providers and their customers. The early adopters mainly consisted of dev tool companies, which makes sense. Any developers building in mission-critical functionality to their applications with API as a service products, like Mailgun or Twilio, needed to know immediately if API response times are spiking or if calls are failing. Furthermore, those developers also needed to know why and when a resolution could be expected. That’s where we came in.
Since then, we’ve grown from 20 customers to 2,000 customers within 2.5 years and have seen pretty much every type of company imaginable come on board. Dev tools, SaaS companies, internet infrastructure, higher education, government, consumer apps, game shops, and many others. Turns out, being transparent isn’t just a good thing for developers, it’s a good thing for everyone. With this uptick in transparency, one of our main use cases has become one that I can’t say we expected - internal IT communication across entire organizations. Employees depend on internal IT services just as developers depend on Twilio and Mailgun.
The first chat integration we ever built at StatusPage let customers pipe incident and component status updates directly into their HipChat rooms. Here’s the announcement from back in the day. Since then, the integration has become one of our most popular to date, with a third of our customers now sending status updates into HipChat for internal consumption.
As we publish this post, Atlassian is announcing HipChat Connect beta, an all-new API that allows external apps, like StatusPage, to extend our functionality seamlessly within HipChat. The new platform lets teams work and solve problems faster without having to context switch. We’re super excited to be one of the early integration partners and wanted to give everyone a quick look into the new updates.