{"id":1546,"date":"2025-04-29T14:59:33","date_gmt":"2025-04-29T09:29:33","guid":{"rendered":"https:\/\/blog.spike.sh\/?p=1546"},"modified":"2025-04-29T17:46:42","modified_gmt":"2025-04-29T12:16:42","slug":"how-we-built-internets-largest-public-glossary-for-the-entire-incident-response-community","status":"publish","type":"post","link":"https:\/\/blog.spike.sh\/how-we-built-internets-largest-public-glossary-for-the-entire-incident-response-community\/","title":{"rendered":"How We Built Internet\u2019s Largest Incident Response Glossary for the Wider Community"},"content":{"rendered":"\n

Today, I’m excited to share the Internet’s Largest Incident Response Glossary<\/a>. It’s a collection of over 500 terms covering on-call, alerting, monitoring, and system reliability.<\/strong><\/p>\n\n\n\n

It took us over 2 weeks from ideation to completion of this project and in this post, I would like to share how we approached this beast!<\/p>\n\n\n\n

\"Spike's
Spike’s Incident Response Glossary<\/figcaption><\/figure>\n\n\n\n

The Spark<\/h2>\n\n\n\n

The idea came from a simple problem I faced daily. I’d write blog posts<\/a> about incident response with seemingly complex terms and wonder: Does my reader know what “alert correlation” means? Should I explain it? Would that disrupt their reading flow?<\/p>\n\n\n\n

I’d add explanations, remove them, reconsider them, and add them back again. This endless cycle was maddening.<\/p>\n\n\n\n

One night while editing a blog post, I thought: What if we had a dedicated space where readers could quickly look up any unfamiliar term? A resource we could link to from our blogs without breaking the reader’s flow? Like a glossary.<\/strong><\/p>\n\n\n\n

Then, I immediately searched for existing glossaries in the incident response space. The few I found were either outdated or covered only 20-30 basic terms. Nothing that covers deep and wide existed.<\/p>\n\n\n\n

That\u2019s when we said to ourselves: \u201cWhy not build our own glossary? Something that covers everything we keep explaining anyway.\u201d<\/strong><\/p>\n\n\n\n

We didn\u2019t set out to build the largest<\/em> one out there\u2014it just turned out that way. A bit of an accident, really. We just kept adding terms we thought would help.<\/p>\n\n\n\n

\n\n\n\n

Gathering the Raw Material<\/h2>\n\n\n\n

The first step was to gather the glossary terms. I used Perplexity to search for as many relevant terms as possible. I focused on three types of terms:<\/p>\n\n\n\n

    \n
  1. Core incident response concepts<\/strong> (MTTA, on-call, etc)<\/li>\n\n\n\n
  2. Terms relevant to Spike’s features<\/strong> (Alert suppression, mobile alerts, etc)<\/li>\n\n\n\n
  3. Emerging trends in the field<\/strong> (Bot-assisted triage, AIOps, etc)<\/li>\n<\/ol>\n\n\n\n

    Take a look at the terms starting with “Z” to get an idea:<\/p>\n\n\n\n

    \"Terms
    Terms for letter “Z”<\/figcaption><\/figure>\n\n\n\n

    Shockingly, the initial list ballooned to over 700 terms<\/strong>.<\/p>\n\n\n\n

    What I expected to be a quick 50\u201370 term glossary completely blew past my expectations.<\/p>\n\n\n\n

    I spent an entire day just gathering and reviewing terms\u2014one by one\u2014adding them to the list. By the end of it, I was overwhelmed. I never imagined it would grow that<\/em> big, that fast.<\/p>\n\n\n\n

    \n\n\n\n

    Choosing What Mattered<\/h2>\n\n\n\n

    Now came the hard part: Deciding what actually belonged.<\/strong><\/p>\n\n\n\n

    Kaushik<\/a> (our CEO) and I had several discussions<\/s><\/em> debates throughout the day. We debated the relevance of each term. We asked ourselves: “Would someone working in incident response need to know this?<\/strong>“. If the answer wasn’t a clear yes, we cut it\u2014no matter how good the term sounded.<\/p>\n\n\n\n

    For example, we dropped terms like \u201cAccident<\/strong>“. Sure, it overlaps with \u201cincident\u201d in casual conversation, but in our field, they\u2019re different. An accident<\/em> implies harm or loss. An incident<\/em> is any disruption\u2014it might not cause damage, but still deserves attention.<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    After many rounds of review, Kaushik and I narrowed the list down to 525 relevant terms<\/strong>. <\/p>\n\n\n\n

    The next morning, we joked about it on our sync call. \u201cIf we removed 175 terms out of 700,\u201d I said, \u201cdoes that make the AI hallucination rate 15%?\u201d \ud83e\udee0 Totally inaccurate\u2014but hey, we like to kid around sometimes.<\/p>\n\n\n\n

    Jokes aside, we were also cautious from an SEO perspective. We were worried about Google punishing us for irrelevant content. So, we were extra careful. We only picked terms that were truly<\/em> relevant to incident response and discarded the rest.<\/p>\n\n\n\n

    \n\n\n\n

    Structuring the Content: More Than Just Definitions<\/h2>\n\n\n\n

    Most glossaries just define the term. I wanted ours to be more actionable. Something people could use to improve their own practices.<\/p>\n\n\n\n

    So, I came up with an ambitious structure: What, Why, Example, How to Implement, Best Practices, Common Pitfalls, and KPIs.<\/p>\n\n\n\n

    But as I started drafting, I saw an overlap. “Best Practices” often covered “Common Pitfalls to Avoid”. And “KPIs” didn’t apply to many conceptual terms.<\/p>\n\n\n\n

    So, I simplified the structure for clarity and value<\/strong>:<\/p>\n\n\n\n