GitLab: With the Press of a Button

GitLab endured what probably was their most significant crisis to date. With the press of a button, an employee accidentally deleted some of their clients’ data from their database servers. Then, the company’s backups didn’t work and GitLab lost access to an enormous amount of data. GitLab shut down their site for 18 hours in order to fix the issue. Below was their initial response.


GitLab’s response was good because they responded immediately and were somewhat transparent, however, it could still use some improvement. They were vague in their transparency because GitLab didn’t want their customers to know that they lost their data and couldn’t access it with no other information to say, which is understandable. Customers could get ugly when hearing something like this. GitLab still could have been a little more transparent by saying that they’ve identified an issue, although that’s what the “performing maintenance” lingo means, but is not clear for someone who doesn’t know that.

GitLab didn’t post again until the next day, but it was completely transparent then. However, there was nearly 14 hours between posts with no update posts in between. This could prove detrimental for a company, given the situation, but GitLab made it through with the combined post below.


My team’s immediate initial response would have gone something like this:

“We have identified an issue with our database servers. Our site may go offline, if need be. We will post updates as we progress through this issue.”

Here, I believe the company would be as transparent as it could get without risking immediate customer backlash in the form of share slander. Meaning, if were 100% transparent right-off-the-bat with no other information in the form answers, our company could easily be subject to negative and destructive press. We have identified an issue and we are letting our customers know that, whereas GitLab just said they were running maintenance. Then, we said the servers may go offline in order to ease our customers into going offline. This is based off my personal experience in that when people hear that something may happen, they then handle it better when it actually happens. Lastly, we would let our customers know that we will be updating them periodically with further information, which GitLab did not do. They just waited until the next day. Frequently updating customers on progress and then answering their questions would further add to the transparency between company and customer. The customer would feel more comfortable, thus mitigating potential damage to GitLab.

Link to article: