Here at Honeybadger, we are big fans of GitHub Actions' workflow automation and CI/CD features. We like it so much that we decided to add two of our own contributions to the community! Now you can trace stacks at light speed by uploading your source maps to Honeybadger directly from GitHub using your original, un-minified Javascript code.
Introducing the pg_partition_manager gem: It helps you easily maintain PostgreSQL partitioned tables that need to be created and dropped over time as you add and expire time-based data in your application.
Configuring your Rails app via environment variables works well, but sometimes you want to be able to update your configuration on the fly. Here's a way to update your app's environment using SSM Parameter Store.
Here at Honeybadger, we want to do our part to help student developers keep their apps free from errors. That’s why we are excited to offer our error monitoring, uptime and check-in monitoring tool free of charge to students that take advantage of the GitHub Student Developer Pack.
Palantir orbs, the Globe of Peace, Thief Raid, Trine, Prophecy Records, Ood Translators — the list of important orbs throughout history is quite long. However, the Honeybadger orb for CircleCI gives you deployment super powers. Do those other “important” orbs offer this feature? I didn’t think so!
At Honeybadger, we use Redis a lot. It's our Swiss Army Knife; it's a cache, a single source of truth, it stores background jobs, and more. Basically, Redis is one of those services that should never fail. I was pondering the DevOps apocalypse recently, as one does (could Redis be one of the four horsemen?), which led me to jump into our #ops channel to ask Ben a simple question: what are the risks if someone executed flushall on our redis instances?
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)
