No transcripts available. Earn a free month
I am trying to wrap around my head around the hooks. The first immediate hook is errbit knowing the application's github repository. The second is the airbreak.rb file where the app (and I assume all of its deploys) actually points to errbit application and its services. So I understand airbreak config... 'send my errors to errbit'. But why then does errbit need to know about to the repo?
A corollary question: if there are multiple deploys, say 'staging1' and 'staging2' are added, they will all be handled by errbit and show the non-traditional deploy name (unless stated in ignore_environments config line) ?
a) So we could run this on hatchbox for $5/month for our three deployed apps?
b) I think you mentioned that errbit is now included in Rails or something? So we don't have to go through all of the steps you list here. Could you remind me again what it was you said?
A) Yep, I use it for all my error handling. Deployed it with Hatchbox and it's on its own server. You'll just need to read up on all the ENV Vars you need to set.
B) Hmm, it's definitely not in Rails. Must have been something else we were talking about.
A) Would $5/month cover our needs for the first year? What triggers the upgrades? Is it based on how many errors are received?
B) So if one of our users in France triggers a heroku rails error, it will show up in errbit, and we can link it so that it notifies us in Slack?
C) And then, if another user in Brazil triggers a different heroku rails error, that too will show up in errbit, so we can diagnose it?
D) Okay, so errbit with airbrake still works according to this video? Don't need to change anything?
E) When is the best time for a deployed app with multiple uses to get set up with this type of error tracking? Is it recommened from day one, to ensure no downtime?