Have you ever dealt with an error in production, and no matter what you try, you can't replicate the issue on your development or staging environments? Often the next step is to gather more data by tossing a debug log at production. If you don't have a good way to correlate logs with a request it can be frustrating, especially during an incident. We added a feature to help, and it's called Breadcrumbs.
It's 2019, so we decided it was time to take a more modern approach to the Honeybadger front end. We implemented Turbolinks! This is only the first step on an ambitious roadmap. In 2025 we plan to migrate to Angular 1, and we'll finish out the decade on React unless we run into any roadblocks! But let's get real. Honeybadger isn't a single page app, and it probably won't ever be. SPAs just don't make sense for our technical requirements.
The other day a long-time customer wrote in with a problem. They use Honeybadger to monitor their Ruby apps for exceptions but were having trouble catching timeouts. If their app took too long to respond, their application server, Puma, would abort the request. The only insight their team had into this problem was through Puma's logs. Most people consider timeouts to be a kind of error, so it'd be nice to have them reported by Honeybadger like any other errors.
We had one of our awesome customers reach out to us regarding our PagerDuty integration and how it could be made more awesome for them. Our co-founder Josh's eyes grew wide with excitement, so he immediately went to work on improving the integration. He even broke the golden rule of coding and...deployed. On. A. Friday! (gasp)
Have you wanted to throw away your expensive internet bill and use your neighbor's insecure wifi? Was the only thing holding you back the Honeybadger single-factor auth flow? Well, have I got news for you.
We recently released a new search key autocomplete feature here at Honeybadger. It was such a fun project that I just had to write it up for you all. Not only does it showcase an exciting use of DynamoDB, but it also shows the challenges of using Dynamo cost-effectively with large amounts of frequently-updated data.
The other day the HB team was chatting and Ben, our dev-ops master, mentioned that he wished he'd used ULIDs instead of UUIDs for a particular system. Like any seasoned engineer, my reaction was to mumble something non-committal then sneak over to Google to try to figure out what the hell a ULID is. Two hours later I emerged with a thousand-yard stare and the realization that the world of unique identifiers is larger and more wondrous than I ever could have imagined.
When Honeybadger originally partnered with Slack, it was the dawn of a new era. Dev teams everywhere were thrilled that they could receive exception, uptime, and check-in alerts instantly from within their teams' Slack channels. That was, and still is, a lethal weapon. However, Honeybadger and Slack have partnered up again and have been hard at work pushing error monitoring to the limit. Why? Because bugs and exceptions don't rest, and neither do Honeybadger and Slack.
Because Ruby is an object-oriented language, we tend to model the world as a set of objects. We say that two integers (x and y) are a Point, and a Line has two of them. While this approach is often useful, it has one big problem. It privileges one interpretation of the data over all others. It assumes that x, and y will always be a Point and that you'll never need them to act as a Cell or Vector. What happens when you do need a Cell? Well, Point owns the data. So you add a your cell methods to Point.
Last week was amazing. It was our first ever Honeybadger Hack Week. We got to take a momentary break from thinking about exceptions and uptime to focus all our energies on something completely new. We decided as a team to build a small app in Elixir and Phoenix.
