Robert Ross
Robert “Bobby” Ross is the CEO and co-founder of FireHydrant. Formerly of Namely, DigitalOcean, and Thunderbolt Labs. Based in New York City, enjoys a great cocktail, bleeding-edge tech, and making software that helps teams build better systems.
The not-so-obvious positive outcomes of great incident management
The industry and markets are volatile right now. More than ever, you should be focused on shipping great products, retaining engineers, and building trust with customers. The right incident management strategy can help you make strides in all three.
Avoid frostbite: Stop doing code freezes
A code freeze is intentionally halting changes to your codebase and environments in an effort to reduce the risk of an outage.On the surface, pausing on deployments feels like a logical solution to preventing incidents. Unfortunately, this isn't the case.
We’ve raised a $23M Series B to help us get to a world where all software is reliable
We envision a world where all software is reliable, and we’re on a mission to help every company that builds or operates software get closer to 100% reliability. Today, we’re thrilled to announce that we’ve raised $23 million to help us further our goal.
Four things to consider when evaluating incident management platforms
Four things to consider when evaluating incident management platforms--from whether you have the culture and process to support a potential tool, to understanding your pain points, to knowing which key stakeholders to involve.
It's Time We Throw Out the Usage of 'Postmortem'
Why are we using the term 'postmortem' when no one died? In any other job, conducting a postmortem means someone perished, so we need to switch to another phrase to lessen the gruesomeness of software incidents. I wanted to provide some ideas that your organization could possibly run with as a replacement to “Postmortem.”
Creating a Data Source - Episode 6 of Throughput Thursdays
In Episode 6, we update our Terraform resource for FireHydrant functionalities and create a data source for FireHydrant services. This allows us to pull services from a list and link them to functionalities. Linking resources like this lets us do a lot of cool things with Terraform.
Adding Two Terraform Resources - Episode 4 of Throughput Thursdays
In episode 4, we were able to achieve creating two full-blown Terraform resources for FireHydrant environments and functionalities. While simple resources, they unlock a lot of power that did not exist previously for teams that want to document their infrastructure using Terraform.
Fixing Some Code Sins - Episode 3 of Throughput Thursdays
In episode 3, we built a flexible API client for our Terraform provider that implements a really simple interface. We also wrote some simple but effective tests and replaced the original cruft in the provider code with our new API client.
Live from Cape Cod - Episode 2 of Throughput Thursdays
In Episode 2, Bobby is live in Cape Cod, sitting on a dock about 4 inches from the edge of a lake. Last week we built a skeleton of a Terraform provider. Now we’ll get the provider to create and delete resources, like services in FireHydrant.
We’re Building a Terraform Provider! - Episode 1 of Throughput Thursdays
In Episode 1, we started out the Terraform provider with a simple data resource against the FireHydrant API. We were able to successfully retrieve information about a single service and display its name in our terminal!
July Product Updates: Status Pages, Incident Redesign, and more
Fire hydrants usually have a firehose hooked up, and do we have a firehose of updates this July. We’ve been focused on making FireHydrant simpler to use and more deeply integrated with existing workflows to make managing your complex systems easier.
NFS with Docker on macOS Catalina
You like living on the edge, life is fun on the edge until the edge is a macOS major update. Then you use vibrantly colorful words, some that your dead ancestors heard, all because your development environment now doesn’t work in spectacular fashion.
3 Defensive Programming Techniques for Rails
Incidents happen all the time because of bad code deploys. Defensive programming is great for codifying how a bug could be introduced, and raising an error right before it would happen, or choosing an alternative path. Here are some simple ideas to defend yourself against simple mistakes.
A Gophers Guide to San Diego
The FireHydrant team is dominantly from San Diego, 3 of our 4 person team actually. We’re here to enjoy the awesome community that Go has been creating and to meet new faces. But we also wanted to give back a little with a small guide on food and drinks in Downtown San Diego.
So You Want To Give A Tech Talk?
So you’ve signed up to give a tech talk, awesome! You’re a subject matter expert in something and want to share your knowledge, that’s what helps make a community awesome. You’re going to be speaking in front of a room of people that you don’t know in a place you’ve likely never been, talking about something you confidently know. Sounds easy, right?
Severity Matrix Updates
We’re on a mission to make responding to incidents a bit less chaotic. One of the best features we offer (we’re definitely not biased, no way) is a simple way to define how a severity gets determined when you open an incident. We call it the severity matrix, and today it has a new look.
Instrumenting Ruby on Rails with Prometheus
If you’re running a production application, you need metrics. In the Rails community, this is commonly achieved with NewRelic and Skylight; but we achieve visibility using Prometheus and Grafana. Check out this guide on how to use Rails with Prometheus.
Flexible Ruby on Rails Reader Objects
Rails and ActiveRecord provide a simple interface for retrieving information from a database. With a few characters, I can retrieve all of my users with User.all. This simplicity is great, but it breaks down when you start doing more advanced queries.
New Feature: Incident Status Pages
Today we're happy to release our incident status page feature! If you operate within an organization that has stakeholders that need the gist of what's going on, how to respond to customers, and give a general feeling of "we're on it," this feature was built for you.