Your Honeybadger account comes with customizable status pages. Give your users insights into the working state of your system by connecting uptime checks or providing updates during problems via incidents.

Here’s a live example of our Hook Relay status page.

Adding a custom domain

To add a custom domain, enter the domain (without the http(s)://) when editing your status page. To verify your domain, add a CNAME DNS record with a value of status.hbuptime.com. For example, if your domain is status.example.com, then you should add the following CNAME through your DNS provider (Google Domains, Amazon Route 53, GoDaddy, etc.):

Once the record has been created, click the “Verify” button under your status page back in Honeybadger:

Now you can visit your domain in a browser. We automatically generate SSL certificates; it should be ready to go on the first visit, but in some cases you may need to refresh a few times. If you have trouble, don’t hesitate to get in touch.

Uptime checks

Connect any currently running uptime checks to your status page if you’d like to share your uptime status with the world. Status pages may include uptime checks across all of the projects in your account.

Connecting checks

While editing your status page, toggle which uptime checks you would like included with your status page.

Give each uptime check an optional display name if you want to customize the name displayed publicly.

That’s it! We will show each uptime check’s current status and history on your public status page.

Incidents

An incident is an effective way to communicate system issues to your users. It can also inform your users of upcoming planned maintenance or downtime.

Conceptually, an incident is a container for timestamped updates that describe the context surrounding a problem affecting your system. An incident can be as simple as a single update that explains some minor downtime, or it can span multiple days with many updates, each representing the changing severity and status of the incident.

Creating Incidents

We provide three scenarios when creating incidents: Current, Scheduled Maintenance, and Retroactive:

Current

Current incidents start with one update and are typically open after creation (meaning you would not select “Resolved” as the starting status.)

Scheduled Maintenance

Scheduled Maintenance incidents are notable because you can queue updates for later posting.

You can create up to three future updates, which we will post at the supplied Start Time. Typically you will send out a Maintenance scheduled update that describes the type of maintenance you will perform and when. After that, we have both In Maintenance and Maintenence complete statuses that you can queue up as individual updates. It’s up to you how much lead time to give your users, based on how you stagger the timing of each update.

If you complete your maintenance sooner than expected, you can always edit the queued update and use the “send now?” button to post the update immediately.

Retroactive

Retroactive incidents give you a tool to create multiple incident updates in one operation. You can create a closed incident from months ago or an open incident that started minutes ago. If you don’t end with a closing update, the incident will be considered open.

A retroactive incident also allows you to craft a single announcement message to accompany your incident updates. This way, you have the option to summarize the incident yet keep each event as separate updates.

Posting an update

When you are ready to inform your users with an update to your incident, click the button in the incident header and fill in your update inline.

Severity and status

When you create an incident or post a new update, you choose a status and severity. status describes where you are in the process of resolving your incident and severity describes how your system is currently affected by the incident.

Scheduled maintenance incidents have a special set of statuses. You can, however, post an update during scheduled maintenance with an incident status, say if things go awry.

Open and closed incidents

An incident, when created, is considered “open.” It will be prominently displayed on your internal status page and made visible as an “active incident” on your public status page. When you provide an update containing a status that closes the incident, it will be “closed” and moved to the historical list of closed incidents.

Even if you have closed an incident with an update, you can always re-open it by posting an update with a new status. While this is possible and useful if something comes up right after closing an incident, we recommend you open a new incident if a significant amount of time has passed.

Announcing updates

We provide the option to connect your status page to a Twitter account (while editing the status page). Linking your Twitter enables us to announce your incident updates to the world. Once connected, a new “Announce” option will be available while crafting any incident updates.