 I think our number one contract with customer is site availability. And like many other services, we also promise three nines of availability. And by the way, it's not just a promise, it's backed by financial guarantee. So if we are not meeting three nines, we'll credit the customers. But internally, inside the team, we don't just think about achieving three nines of availability. We're obsessed about that missing 0.1%. In other words, our contract, internal contract is to provide 100% availability to our customers. When a site goes down, that becomes job number one for the entire team. There is nothing else that takes a higher priority. And the core rules of engagement are speed, automation, and discipline action. Every action matters. Every wrong action can delay the recovery. It's a pressure cooker environment. But our goal is to keep the team calm and focused on the recovery. And in parallel, we take our responsibility to communicate the customers very seriously. So we are constantly updating our service status, telling them about what's going on, what to expect. And if it's a serious issue, our VP, Brian Harry, you would write up a fairly detailed blog post about what happened, what the problem was, how we mitigated the problem, what we learned from it, what actions we are taking to prevent that problem from happening again. So not only we are transparent to our customers about what happened, but we are holding ourselves accountable with a public blog post. So we take these things very seriously. And then what happens is that once a week, we get together, the leadership team comes together to review the life side issues from the previous week. So this is a meeting that's attended by all the engineering managers as well as directors. This is probably the most important meeting I go to myself. The goal of the meeting is to not pass criticism or point finger at anybody. Its goal of the meeting is to drive continuous improvement. So we look at the previous week's incidents and each engineering manager is expected to come prepared with a detail right up on what happened and what we learned from that. And we expect this to come from a fairly senior leader as opposed to an engineer. And the reason is that these discussions are fairly open and self-critical in nature. And oftentimes the action items that come out of that are not just tactical response, but fairly broad nature improvements in the product. And it's best to have this kind of conversation with senior leaders in the team. And we would share these learnings broadly with the team after the meeting.