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.
You can create a new status page at Account → Status Pages.
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.):
|Record type||Label/Host field||Time To Live (TTL)||Destination/value|
|CNAME||status.example.com||default is fine (i.e. 3600)||status.hbuptime.com|
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
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.
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.
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.
We provide three scenarios when creating incidents:
Current incidents start with one update and are typically open after creation (meaning you would not select “Resolved” as the starting status.)
Scheduled Maintenance incidents are notable because you can queue updates for later posting.
This is the only place you can submit an update to post in the future.
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
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 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.
You can not announce each update individually via a retroactive incident.
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.
When you create an incident or post a new update, you choose a
status describes where you are in the process of resolving your
severity describes how your system is currently affected by the
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.
An incident update with a
complete status will close the containing incident.
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.
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.