We have some exciting news: thanks to our friends at Honeybadger, we now have a public dashboard that collects runtime bugs on DEV!
If you'd like to help us out squash those bugs, check out the GitHub issues with the honeybadger label. Don't forget to "claim" your issue by leaving a comment, so that other won't be working on the same one!
The DEV team recently started using Honeybadger for monitoring bugs on our platform. We like this service for a few different reasons! It gives us the ability to neatly separate frontend errors from backend ones, and it includes great features for supporting deploy tracking. We also like its filtering tools, which are super useful when it comes to sorting and searching through errors, and we appreciate its very smart defaults, like the ability to ignore errors in our test and development environments!
Although we have been using Honeybadger internally to help us track errors for a couple of months, we've decided to make this information public to the community so that our contributors can help jump in and help us keep DEV more stable! To see it in action, head over to our public dashboard.
If you find new errors in our dashboard that aren't recorded anywhere, you can open a GitHub issue following this template as an example. We also recommend reading up on DEV's contributing guide and developer documentation before making your contribution!
The Honeybadger team also plans to release public dashboards as a standard feature for all open source projects in the near future based on community feedback, so if you are a maintainer we recommend checking them out! :-)
Top comments (9)
Let's kill the bugs !
I've always been a Rollbar person, but I have some friends sware by Honeybagder.
Maybe I'll fix a few bugs so I get to experience the other side of error reporting service.
I noticed in my blogs, I used the
source code'
' for a lot ofthings, and this breaks the rendering veryeasily`.Awesome
Are you worried about any sensitive information being leaked in error logs and exceptions? I know we all do our best to keep PII and secrets out of logs, but this feels like it could be a bit risky! 😱
Hi Tim, we do collect a lot of data that could potentially have PII (such as request parameters and session data). For this reason, public dashboards are limited to just a few pieces of information about each exception: the class name, error message, and backtrace. It is still technically possible to leak information in the error message or other fields (it's obviously really bad practice to include PII in an error message, but it does happen). However, each error on the public dashboard was specifically shared by a DEV team member with full account access, which implies that the error data was reviewed first. (It's similar to copy/pasting the error information into a GitHub issue which is what they were doing before).
Does that help? I'm happy to answer any other questions or discuss concerns you may still have.
Thanks for the detailed response! Sounds good!
This is great! Time to check some bugs out.