 I want to first of all talk about incident management and then how transport makes it easier for, of course, DevOps teams to kind of not get overwhelmed with all the alerts and notifications. I love this question. The one thing I'll say about me is pretty passionate about certain parts of this, so great question and I appreciate you asking it, but one of the things that I really love is the concept of automation in a way that prevents that fatigue. A, if I take the first step to get contextual information and potentially take a resolution step before I get started with something, I don't need to be paged. It's the beauty of that system. I can imagine a world where X goes wrong and Y is the first step that any on-call engineer is ever going to take and step Y could be done by anybody in the company with an automation platform that handles that authentication, that on-call presence is only required when that fails. I really like the idea of that. In my life, in my previous life, it's what I strived for. How many times do I page someone just for them to be able to do something that I could have done automatically or with automation? I like the idea of thinking alert, signal, service, what is the outcome of that, or what is the thing that I can impact before I'm required to join that ongoing incident or that alert resolution. It's technically why we're bringing on-call into our solution. We want to page you when automation fails. If it's not automation failing, it's bringing that context. Bring context to the thing I'm being paged for. If I'm going to do steps one through five, do step one through five for me. I like that.