Files
nexus/sreweekly/articles/109/02-structured-logging-and-your-team.html
2026-09-12 17:23:01 +08:00

2 lines
836 KiB
HTML
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
<!DOCTYPE html><html lang="en"><head><meta charSet="utf-8"/><meta name="viewport" content="width=device-width, initial-scale=1"/><link rel="preload" as="image" imageSrcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=3840&amp;q=75 3840w" imageSizes="(max-width: 1024px) 100vw, 50vw" fetchPriority="high"/><link rel="stylesheet" href="/_next/static/chunks/0-a~7ljgpwyij.css" data-precedence="next"/><link rel="stylesheet" href="/_next/static/chunks/0k9no2apwmz~n.css" data-precedence="next"/><link rel="stylesheet" href="/_next/static/chunks/0nuksys438q2t.css" data-precedence="next"/><link rel="preload" as="script" fetchPriority="low" href="/_next/static/chunks/05gogik_6g8vk.js"/><script src="/_next/static/chunks/008dsykc_h8bq.js" async=""></script><script src="/_next/static/chunks/0i~~aj0ee08p-.js" async=""></script><script src="/_next/static/chunks/0qw_yv-45a3f4.js" async=""></script><script src="/_next/static/chunks/0._rkt7m1wq9e.js" async=""></script><script src="/_next/static/chunks/turbopack-16vnx6ub8-z5v.js" async=""></script><script src="/_next/static/chunks/14_mcc2-.c1ee.js" async=""></script><script src="/_next/static/chunks/019vi3l~x0zoc.js" async=""></script><script src="/_next/static/chunks/12~zlyzq33k~1.js" async=""></script><script src="/_next/static/chunks/025lo2k4b20~m.js" async=""></script><script src="/_next/static/chunks/0ku~nn_l8-fol.js" async=""></script><script src="/_next/static/chunks/039u5_5hlemld.js" async=""></script><script src="/_next/static/chunks/189hrhe.fk4af.js" async=""></script><script src="/_next/static/chunks/0oz-qxk30w~qw.js" async=""></script><script src="/_next/static/chunks/0vx_phl8cla2s.js" async=""></script><script src="/_next/static/chunks/0xywjwd04osrr.js" async=""></script><script src="/_next/static/chunks/0t1~yeqvn891r.js" async=""></script><script src="/_next/static/chunks/0ks4m351.jbv2.js" async=""></script><script src="/_next/static/chunks/01gy5f4286e6a.js" async=""></script><script src="/_next/static/chunks/09mg9tc2w3ag6.js" async=""></script><script src="/_next/static/chunks/0~-xo~ilf3e0r.js" async=""></script><link rel="preload" href="https://cdn-cookieyes.com/client_data/497224d8995aa8565cbc3037/script.js" as="script"/><link rel="preload" href="/hny.min.js" as="script"/><link rel="preload" href="https://stats.honeycomb.io/js/pa-DJvf3AtvU5wDjKkEU-JVs.js" as="script"/><link rel="preload" href="https://www.googletagmanager.com/gtag/js?id=G-DJM5ZXPGB0" as="script"/><link rel="preload" href="https://www.googletagmanager.com/gtm.js?id=GTM-KH7NL6K" as="script"/><link rel="preload" href="https://cdn.jsdelivr.net/npm/hockeystack@latest/hockeystack.min.js" as="script"/><link rel="preconnect" href="https://cdn-cookieyes.com"/><link rel="dns-prefetch" href="https://cdn-cookieyes.com"/><meta name="next-size-adjust" content=""/><title>Honeycomb Blog</title><meta name="description" content="honeycomb.io is an observability platform designed to help engineering teams find and solve complex issues in their cloud applications"/><link rel="canonical" href="https://www.honeycomb.io/blog"/><link rel="icon" href="/favicon.ico?favicon.07o~09ebmt8eg.ico" sizes="48x48" type="image/x-icon"/><link rel="icon" href="/favicon-16x16.png" sizes="16x16" type="image/png"/><link rel="icon" href="/favicon-32x32.png" sizes="32x32" type="image/png"/><script>(self.__next_s=self.__next_s||[]).push([0,{"children":"window.ckySettings=window.ckySettings||{};window.ckySettings.nativeFunctions={fetch:window.fetch,xhr:window.XMLHttpRequest};","id":"cookieyes-preserve-native"}])</script><script>(self.__next_s=self.__next_s||[]).push(["https://cdn-cookieyes.com/client_data/497224d8995aa8565cbc3037/script.js",{"id":"cookieyes"}])</script><script referrerPolicy="no-referrer-when-downgrade" src="https://edge.wingify.net/tag/1272784.js"></script><script>(self.__next_s=self.__next_s||[]).push(["/hny.min.js",{}])</script><script>(self.__next_s=self.__next_s||[]).push([0,{"children":"\n window.Hny.initializeTracing({\n debug: false,\n apiKey: \"hcaik_01kc76rhfsq3kjf9tdmx6f7bmhhd0rzcdrpbtbgk31bpj4nezy2frmbqx8\",\n serviceName: \"www-next\",\n configDefaults: {\n ignoreNetworkEvents: true,\n propagateTraceHeaderCorsUrls: [\n /https:\\/\\/www\\.honeycomb\\.io/,\n /https:\\/\\/www-stage\\.honeycomb\\.io/,\n /https:\\/\\/honeycomb\\.vercel\\.app/,\n /https:\\/\\/honeycomb-stage\\.vercel\\.app/\n ]\n }\n });\n ","id":"hny-init"}])</script><script>(self.__next_s=self.__next_s||[]).push(["https://stats.honeycomb.io/js/pa-DJvf3AtvU5wDjKkEU-JVs.js",{"async":true,"id":"plausible-script"}])</script><script>(self.__next_s=self.__next_s||[]).push([0,{"children":"\n window.plausible = window.plausible || function() {\n (plausible.q = plausible.q || []).push(arguments)\n };\n plausible.init = plausible.init || function(i) {\n plausible.o = i || {}\n };\n plausible.init();\n ","id":"plausible-init"}])</script><script src="/_next/static/chunks/03~yq9q893hmn.js" noModule=""></script></head><body class="roboto_a526148e-module__zhi6Uq__className poppins_b750422f-module__FR8AEW__className roboto_459e8801-module__Bzopaa__className poppins_c92f7652-module__gE1l-G__className"><div hidden=""><!--$--><!--/$--></div><div class="jsx-62ee9791d3e4bddb bg-hc-cobalt font-roboto learn-more-header relative min-h-12 content-center py-2.5 text-center text-sm text-white"><span class="jsx-62ee9791d3e4bddb mr-2.5">Observability Engineering second edition out now! 27 net-new chapters written for today&#x27;s observability challenges.</span><a target="_self" _type="link" class="font-roboto focus-visible:ring-ring inline-block cursor-pointer rounded-sm text-center font-bold uppercase transition-[color,background-color] [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 text-hc-cobalt hover:text-hc-pacific border-2 border-solid border-white bg-white px-2.5 py-1 text-[10px] leading-3.5 tracking-widest" href="/observability-engineering-oreilly-book"><span class="flex items-center justify-center gap-2.5">Get your copy</span></a></div><div class="jsx-62ee9791d3e4bddb bg-hc-cobalt fixed top-0 left-0 z-150 w-full text-white transition-all duration-300 ease-in-out pointer-events-none -translate-y-full opacity-0 pt-12"><form class="jsx-62ee9791d3e4bddb container mx-auto my-4 flex w-4/5 max-w-[1180px] items-center gap-4 border-b border-white px-2.5 pb-[5px]"><button type="button" aria-label="Search" class="jsx-62ee9791d3e4bddb"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="20" viewBox="0 0 20 20" fill="none" stroke="white" class="h-4"><path d="M8.875 16.75C13.2242 16.75 16.75 13.2242 16.75 8.875C16.75 4.52576 13.2242 1 8.875 1C4.52576 1 1 4.52576 1 8.875C1 13.2242 4.52576 16.75 8.875 16.75Z" stroke="inherit" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"></path><path d="M14.4434 14.4438L18.9997 19.0002" stroke="inherit" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"></path></svg></button><input type="text" placeholder="Search..." class="jsx-62ee9791d3e4bddb font-roboto flex-1 border-none bg-transparent text-base text-white outline-none placeholder:text-white/70" value=""/><button type="button" aria-label="Close search" class="jsx-62ee9791d3e4bddb text-white/70 transition-colors hover:text-white"><svg xmlns="http://www.w3.org/2000/svg" width="22" height="22" viewBox="0 0 22 22" fill="none" stroke="white" class="h-4"><path d="M0.999512 1L20.9992 20.9996" stroke="inherit" stroke-width="2" stroke-linecap="round"></path><path d="M20.9998 1L1.00011 20.9996" stroke="inherit" stroke-width="2" stroke-linecap="round"></path></svg></button></form></div><header id="main-navbar" style="opacity:var(--header-opacity);pointer-events:var(--header-pointer-events)" class="jsx-62ee9791d3e4bddb sticky top-0 z-50 w-full transition-transform duration-200 [&amp;[scrolled]]:bg-white [&amp;[scrolled]]:shadow-md"><div class="jsx-62ee9791d3e4bddb relative mx-auto flex max-w-[90%] items-center justify-between lg:h-full lg:max-w-[1180px] lg:px-6 xl:px-0"><a class="h-[105px] w-fit place-content-center" title="Honeycomb" href="/"><svg width="164" height="48" viewBox="0 0 164 48" fill="none" xmlns="http://www.w3.org/2000/svg" class="mb-5 lg:max-w-[135px] xl:max-w-none"><g clip-path="url(#clip0)"><path d="M151.695 26.0424C151.755 26.1018 151.8 26.1743 151.827 26.2541C151.861 26.333 151.879 26.4178 151.879 26.5036V27.1389C151.879 27.3115 151.818 27.4785 151.705 27.6094C151.652 27.667 151.588 27.7132 151.517 27.7456C151.445 27.7779 151.368 27.7956 151.29 27.7977H150.918C150.839 27.7986 150.761 27.7822 150.689 27.7496C150.618 27.7171 150.554 27.6692 150.503 27.6094C150.39 27.4785 150.328 27.3115 150.329 27.1389V26.5036C150.326 26.3305 150.388 26.1628 150.503 26.033C150.556 25.9753 150.62 25.9288 150.691 25.8965C150.762 25.8641 150.839 25.8465 150.918 25.8447H151.276C151.351 25.843 151.425 25.8591 151.493 25.8918C151.569 25.9285 151.638 25.9796 151.695 26.0424Z" fill="#25303E"></path><path d="M64.6293 28.8801H61.5331C61.0567 28.8741 60.5841 28.9668 60.1453 29.1523C59.7065 29.3378 59.311 29.612 58.9836 29.9577C58.6441 30.2861 58.3734 30.6786 58.1873 31.1125C58.0012 31.5463 57.9034 32.0128 57.8997 32.4848V40.0001H59.1438V33.0777C59.1533 32.2922 59.4655 31.5405 60.0156 30.9789C60.5644 30.4332 61.3054 30.124 62.0798 30.1177H63.9271C64.3091 30.1176 64.6872 30.1937 65.0392 30.3416C65.3913 30.4895 65.7102 30.7062 65.9771 30.9789C66.2546 31.2535 66.4746 31.5805 66.6242 31.9408C66.7739 32.3012 66.8503 32.6876 66.849 33.0777V40.0001H68.1497V32.4706C68.1547 31.9974 68.0609 31.5282 67.8743 31.0931C67.6877 30.658 67.4123 30.2665 67.0658 29.9436C66.7669 29.5936 66.3923 29.3159 65.9702 29.1317C65.5481 28.9474 65.0896 28.8614 64.6293 28.8801Z" fill="#25303E"></path><path d="M52.3573 28.6635H49.9161C48.8835 28.6805 47.8948 29.0835 47.1451 29.7929C46.4296 30.5294 46.0219 31.5104 46.0046 32.5364V36.3011C46.0122 37.3296 46.4135 38.3162 47.1262 39.0587C47.4865 39.4259 47.9181 39.7156 48.3947 39.9098C48.8713 40.104 49.3826 40.1988 49.8973 40.1882H52.3384C53.3813 40.1805 54.3822 39.7767 55.1377 39.0587C55.5023 38.7011 55.7911 38.2739 55.987 37.8026C56.1829 37.3313 56.2819 36.8255 56.2782 36.3152V32.5505C56.2646 31.5196 55.8565 30.533 55.1377 29.7929C54.3857 29.0813 53.3932 28.6782 52.3573 28.6635ZM54.9115 32.4282V36.5176C54.8979 37.1594 54.646 37.7732 54.2046 38.2399C53.7513 38.6749 53.1507 38.9235 52.5222 38.9364H49.8077C49.1756 38.9343 48.5697 38.6842 48.1206 38.2399C47.6725 37.7779 47.4209 37.1607 47.4184 36.5176V32.4282C47.4296 31.7882 47.6801 31.1755 48.1206 30.7105C48.5741 30.2724 49.1769 30.0219 49.8077 30.0093H52.5222C53.1507 30.0133 53.7521 30.2654 54.1952 30.7105C54.6405 31.1736 54.896 31.7864 54.9115 32.4282Z" fill="#25303E"></path><path d="M41.0003 28.8801H37.9135C37.4465 28.8641 36.9821 28.9559 36.5563 29.1483C36.1749 29.2725 35.8235 29.4744 35.5242 29.7412V24.8424H34.2754V40.0001H35.5808V33.0212C35.5904 32.2366 35.9008 31.4856 36.4479 30.9224C36.9983 30.3793 37.7383 30.0705 38.5121 30.0612H40.3594C40.7419 30.062 41.1204 30.1386 41.4731 30.2864C41.8258 30.4342 42.1456 30.6504 42.4141 30.9224C42.6897 31.1982 42.9081 31.5255 43.0569 31.8856C43.2056 32.2458 43.2819 32.6317 43.2812 33.0212V39.9624H44.5866V32.433C44.5919 31.9592 44.4978 31.4896 44.3103 31.0544C44.1228 30.6191 43.8461 30.2279 43.498 29.9059C43.1814 29.564 42.7939 29.295 42.3625 29.1179C41.9311 28.9407 41.4663 28.8595 41.0003 28.8801Z" fill="#25303E"></path><path d="M108.071 28.7059H105.63C104.596 28.7207 103.607 29.124 102.858 29.8353C102.142 30.5713 101.734 31.5526 101.718 32.5788V36.3435C101.735 37.3695 102.143 38.3505 102.858 39.0871C103.219 39.4542 103.65 39.7439 104.127 39.9381C104.604 40.1324 105.115 40.2271 105.63 40.2165H108.071C109.103 40.1985 110.091 39.7956 110.842 39.0871C111.557 38.3505 111.965 37.3695 111.982 36.3435V32.5788C111.966 31.5526 111.558 30.5713 110.842 29.8353C110.481 29.4681 110.05 29.1785 109.573 28.9842C109.097 28.79 108.585 28.6953 108.071 28.7059ZM110.625 32.4706V36.56C110.611 37.2003 110.359 37.8126 109.918 38.2776C109.701 38.5044 109.44 38.6839 109.151 38.8046C108.861 38.9253 108.549 38.9846 108.236 38.9788H105.516C104.885 38.9763 104.28 38.7242 103.834 38.2776C103.385 37.8182 103.133 37.202 103.132 36.56V32.4706C103.144 31.8293 103.394 31.2154 103.834 30.7482C104.287 30.3128 104.888 30.0626 105.516 30.0471H108.236C108.867 30.0506 109.471 30.3025 109.918 30.7482C110.359 31.2149 110.611 31.8288 110.625 32.4706Z" fill="#25303E"></path><path d="M128.433 28.9319H125.394C124.806 28.9346 124.227 29.0834 123.711 29.3648C123.248 29.616 122.844 29.9643 122.528 30.386C122.224 29.948 121.812 29.5962 121.331 29.3648C120.833 29.0903 120.275 28.9417 119.705 28.9319H116.774C115.834 28.9565 114.939 29.3425 114.277 30.0095C113.948 30.3406 113.691 30.7359 113.522 31.1708C113.353 31.6057 113.276 32.0707 113.296 32.5366V40.066H114.517V33.1813C114.511 32.794 114.585 32.4095 114.734 32.0519C114.87 31.7026 115.074 31.383 115.332 31.1107C115.61 30.8455 115.928 30.6263 116.275 30.4613C116.615 30.3097 116.986 30.2373 117.359 30.2495H119.098C119.752 30.2489 120.385 30.477 120.888 30.8942C121.38 31.2896 121.725 31.838 121.869 32.4519V40.1225H123.226V32.3201C123.398 31.7193 123.761 31.1904 124.26 30.8128C124.758 30.4352 125.366 30.2293 125.992 30.226H127.788C128.56 30.2331 129.3 30.5422 129.847 31.0872C130.397 31.626 130.71 32.3604 130.719 33.1295V40.0707H132.076V32.5413C132.079 32.073 131.989 31.6088 131.812 31.1752C131.635 30.7415 131.374 30.347 131.044 30.0142C130.33 29.3551 129.405 28.9714 128.433 28.9319Z" fill="#25303E"></path><path d="M142.444 29.7412C142.085 29.3913 141.659 29.1158 141.193 28.9309C140.726 28.7459 140.227 28.6551 139.725 28.6636H137.284C136.339 28.6603 135.428 29.0113 134.73 29.6471V24.7906H133.368V36.2354C133.387 37.2609 133.795 38.241 134.508 38.9789C134.869 39.3447 135.301 39.6335 135.778 39.8276C136.254 40.0218 136.765 40.1173 137.279 40.1083H139.72C140.234 40.113 140.744 40.0155 141.219 39.8216C141.695 39.6277 142.128 39.3412 142.491 38.9789C142.856 38.6213 143.146 38.1943 143.342 37.723C143.539 37.2518 143.639 36.7459 143.637 36.2354V32.4706C143.631 31.9738 143.538 31.4818 143.363 31.0165C143.119 30.5501 142.81 30.1207 142.444 29.7412ZM134.678 32.3765C134.691 31.7347 134.943 31.1209 135.385 30.6542C135.837 30.2171 136.438 29.9667 137.067 29.953H139.782C140.413 29.9565 141.017 30.2085 141.464 30.6542C141.914 31.1154 142.167 31.7327 142.171 32.3765V36.4659C142.158 37.1065 141.906 37.7191 141.464 38.1836C141.013 38.6226 140.411 38.8734 139.782 38.8848H137.067C136.754 38.884 136.445 38.8217 136.156 38.7014C135.867 38.5811 135.605 38.4051 135.385 38.1836C134.934 37.7246 134.681 37.1085 134.678 36.4659V32.3765Z" fill="#25303E"></path><path d="M99.4367 38.08C99.2387 38.3036 98.9985 38.4859 98.7298 38.6165C98.4414 38.7734 98.1154 38.8483 97.7873 38.833H95.2378C94.6185 38.7967 94.036 38.5277 93.6072 38.08C93.3933 37.8586 93.2256 37.5968 93.1139 37.31C93.0023 37.0232 92.9489 36.7171 92.9569 36.4095V32.3201C92.9502 31.7018 93.1832 31.1048 93.6072 30.6542C94.0432 30.2168 94.6216 29.9497 95.2378 29.9012H97.7873C98.3346 29.9003 98.8606 30.1131 99.2529 30.4942L99.3095 30.5459H100.851L100.794 30.3859C100.476 29.8387 100.03 29.3769 99.4933 29.0401C98.9457 28.7306 98.327 28.5684 97.6978 28.5695H95.4169C94.4297 28.6234 93.4992 29.0468 92.8108 29.7553C92.1288 30.4822 91.7584 31.4466 91.7787 32.4424V36.2071C91.7567 36.7018 91.837 37.1956 92.0145 37.6579C92.1921 38.1203 92.4632 38.5411 92.8108 38.8942C93.4915 39.6135 94.4266 40.039 95.4169 40.08H97.6978C98.3518 40.0648 98.9897 39.8747 99.5451 39.5295C100.113 39.2007 100.568 38.7087 100.851 38.1177L100.902 37.9577H99.4367V38.08Z" fill="#25303E"></path><path d="M85.8074 37.647L85.699 37.5952C85.3598 37.4943 85.0408 37.335 84.7564 37.1246C84.0922 36.4456 83.6066 35.613 83.3426 34.7011L81.6602 29.1105C81.6602 29.054 81.6084 29.0023 81.6084 28.9458C81.6084 28.8893 81.5518 28.8376 81.5518 28.7858V28.7058H80.303V28.8093C80.3563 29.1008 80.4287 29.3885 80.5198 29.6705L82.0419 34.847C82.5839 36.7293 83.7809 38.2352 85.19 38.7717L82.6593 43.7646H83.96L91.7264 28.7058H90.3692L85.8074 37.647Z" fill="#25303E"></path><path d="M151.747 29.3083H150.499V40.1319H151.747V29.3083Z" fill="#25303E"></path><path d="M163.675 30.9789C163.482 30.5057 163.184 30.0825 162.803 29.7413C162.438 29.3891 162.018 29.0983 161.559 28.8801C161.094 28.6869 160.593 28.5954 160.089 28.6119H157.648C156.615 28.6276 155.626 29.0308 154.877 29.7413C154.514 30.0976 154.227 30.5225 154.031 30.9912C153.835 31.4599 153.735 31.9629 153.736 32.4707V36.2354C153.754 37.2614 154.161 38.2423 154.877 38.9789C155.237 39.3461 155.669 39.6357 156.145 39.83C156.622 40.0242 157.133 40.1189 157.648 40.1083H160.089C161.122 40.0935 162.112 39.6902 162.86 38.9789C163.576 38.2423 163.983 37.2614 164.001 36.2354V32.4707C164.001 31.9559 163.89 31.4471 163.675 30.9789ZM162.643 32.3907V36.4801C162.63 37.1206 162.378 37.7332 161.936 38.1977C161.485 38.6368 160.884 38.8876 160.254 38.8989H157.539C157.227 38.8982 156.917 38.8359 156.628 38.7156C156.34 38.5953 156.078 38.4193 155.857 38.1977C155.407 37.7388 155.153 37.1227 155.15 36.4801V32.3766C155.164 31.7348 155.416 31.1209 155.857 30.6542C156.31 30.2185 156.911 29.9697 157.539 29.9577H160.254C160.885 29.96 161.489 30.2102 161.936 30.6542C162.378 31.1209 162.63 31.7348 162.643 32.3766V32.3907Z" fill="#25303E"></path><path d="M76.4152 28.7058H73.0457C72.2864 28.683 71.5473 28.9525 70.9816 29.4588C70.405 29.95 70.0363 30.6411 69.9495 31.3929V36.2352C69.9469 36.7902 70.0593 37.3397 70.2794 37.8493C70.4865 38.3364 70.7858 38.7789 71.1607 39.1529C71.5273 39.5197 71.9742 39.7968 72.4661 39.9623C72.8202 40.0653 73.183 40.1362 73.55 40.174H75.7743C76.4868 40.1707 77.1804 39.9453 77.7584 39.5293C77.9509 39.3867 78.1321 39.2294 78.3003 39.0588C78.4445 38.8926 78.5723 38.7129 78.682 38.5223C78.7929 38.335 78.8829 38.1361 78.9507 37.9293L79.0072 37.8211L77.8243 37.647L77.7725 37.7035C77.6414 37.9878 77.4556 38.2436 77.2258 38.4564C76.851 38.7865 76.3728 38.9762 75.8733 38.9929H73.3756C73.1731 38.9895 72.9725 38.9529 72.7818 38.8846C72.3123 38.7352 71.9071 38.4317 71.6319 38.0235C71.4688 37.8209 71.3572 37.582 71.3067 37.327C71.2502 37.2188 71.2502 37.054 71.1984 36.9505V34.9599H76.4105C77.1952 34.9796 77.9558 34.6886 78.5265 34.1505C79.116 33.6067 79.4666 32.8524 79.502 32.0517V31.6752C79.4773 30.8789 79.1385 30.1245 78.5595 29.5764C78.2803 29.2931 77.9461 29.0697 77.5774 28.92C77.2087 28.7703 76.8132 28.6974 76.4152 28.7058ZM77.6075 33.4399C77.3228 33.6385 76.9784 33.7332 76.632 33.7082H71.2031V31.407C71.2475 31.0909 71.3779 30.7931 71.5801 30.5458C71.743 30.3474 71.9472 30.1868 72.1786 30.0752C72.4169 29.9676 72.6758 29.913 72.9373 29.9152H76.632C76.8754 29.913 77.1159 29.9678 77.3342 30.0752C77.5553 30.1872 77.7573 30.3333 77.9327 30.5082C78.1383 30.814 78.269 31.1638 78.3144 31.5293C78.3607 31.8921 78.3236 32.2606 78.2061 32.607C78.1024 32.946 77.8927 33.2429 77.6075 33.454V33.4399Z" fill="#25303E"></path><path d="M148.298 38.6119C148.297 38.9133 148.206 39.2076 148.038 39.4577C147.87 39.7078 147.631 39.9025 147.352 40.0172C147.073 40.1319 146.766 40.1614 146.47 40.1021C146.174 40.0427 145.903 39.8971 145.689 39.6837C145.476 39.4703 145.331 39.1986 145.273 38.903C145.214 38.6073 145.245 38.301 145.361 38.0227C145.476 37.7443 145.672 37.5065 145.923 37.3392C146.174 37.1718 146.469 37.0825 146.771 37.0825C146.972 37.0825 147.171 37.1221 147.356 37.199C147.542 37.2759 147.71 37.3887 147.852 37.5308C147.994 37.6728 148.106 37.8415 148.183 38.027C148.259 38.2125 148.298 38.4113 148.298 38.6119Z" fill="#25303E"></path><path d="M26.0654 32.7012L30.4387 40.3482L26.0654 48H17.3706L13.002 40.3482L17.3706 32.7012H26.0654Z" fill="#FFB000"></path><path d="M26.0654 14.24L30.4387 21.8871L26.0654 29.5388H17.3706L13.002 21.8871L17.3706 14.24H26.0654Z" fill="#64BA00"></path><path d="M10.6741 24.7906L14.2369 31.1154L10.6741 37.4495H3.56276L0 31.1154L3.56276 24.7906H10.6741Z" fill="#F96E10"></path><path d="M44.9918 0L50.647 10.0141L44.9918 20.0424H33.6249L27.9697 10.0141L33.6249 0H44.9918Z" fill="#0298EC"></path></g><defs><clipPath id="clip0"><rect width="164" height="48" fill="white"></rect></clipPath></defs></svg></a><nav class="jsx-62ee9791d3e4bddb flex gap-8 max-lg:hidden lg:items-center lg:gap-0"><div class="jsx-62ee9791d3e4bddb group lg:after:bg-hc-cobalt relative lg:px-1 lg:after:absolute lg:after:bottom-5 lg:after:left-0 lg:after:h-[2px] lg:after:w-0 lg:after:transition-[width] lg:after:duration-200 lg:after:ease-in-out lg:after:content-[&#x27;&#x27;] first:lg:pl-0 lg:focus-within:after:mx-1 lg:focus-within:after:w-[calc(100%_-_8px)] lg:first:focus-within:after:mx-0 lg:first:focus-within:after:w-[calc(100%_-_4px)] lg:hover:after:mx-2 lg:hover:after:w-[calc(100%_-_8px)] lg:first:hover:after:mx-0 lg:first:hover:after:w-[calc(100%_-_4px)] xl:px-3.5 xl:focus-within:after:mx-3.5 xl:focus-within:after:w-[calc(100%_-_28px)] xl:first:focus-within:after:w-[calc(100%_-_14px)] xl:hover:after:mx-3.5 xl:hover:after:w-[calc(100%_-_28px)] xl:first:hover:after:w-[calc(100%_-_14px)]"><button aria-expanded="false" aria-haspopup="true" class="jsx-62ee9791d3e4bddb font-roboto flex w-full items-center justify-between text-left max-lg:cursor-default max-lg:text-xl max-lg:font-medium lg:pointer-events-none lg:block lg:py-10">Observability Platform<svg width="11" height="12" viewBox="0 0 11 12" fill="none" xmlns="http://www.w3.org/2000/svg" class="lg:hidden"><path d="M5 1L10 6L5 11" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path></svg></button><div class="jsx-62ee9791d3e4bddb menu fixed left-0 z-50 hidden w-full bg-[linear-gradient(to_right,_#f6f6f6_50%,_white_50%)] lg:top-[var(--navBottom,104px)] lg:group-focus-within:block lg:group-hover:block"><div class="jsx-62ee9791d3e4bddb container flex gap-12 xl:max-w-[1180px]"><div class="jsx-62ee9791d3e4bddb max-w-[170px] pt-12 pb-16"><h4 class="jsx-62ee9791d3e4bddb font-roboto mb-2 text-2xl font-bold">Explore the platform</h4><p class="jsx-62ee9791d3e4bddb mb-6 text-sm tracking-wide"> <!-- -->Honeycomb was built for the AI era. Learn how to futureproof your software for what comes next.</p><a target="_self" _type="link" class="font-roboto focus-visible:ring-ring inline-block cursor-pointer text-center font-bold tracking-[1.4px] uppercase transition-[color,background-color] [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 border-hc-cobalt text-hc-cobalt border-2 border-solid bg-transparent h-8 content-center rounded-md px-3 py-2 text-xs hover:border-hc-cobalt hover:bg-hc-cobalt hover:text-white" href="/platform"><span class="flex items-center justify-center gap-2.5">See overview</span></a></div><ul class="jsx-62ee9791d3e4bddb flex grow flex-wrap gap-x-4 bg-white pt-12 pb-16 pl-12 lg:gap-y-3 xl:gap-x-12"><li class="jsx-62ee9791d3e4bddb lg:flex lg:flex-col lg:gap-3"><a target="_self" _type="link" class="font-roboto border-hc-gray-400 group/arrow-link hover:text-hc-cobalt flex items-center border-b font-bold whitespace-nowrap lg:gap-2 lg:pb-3" href="/platform">Core Observability<svg width="11" height="12" viewBox="0 0 11 12" fill="none" xmlns="http://www.w3.org/2000/svg" class="transition-transform group-hover/arrow-link:translate-x-2 max-lg:hidden"><path d="M5 1L10 6L5 11" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path></svg></a><ul class="jsx-62ee9791d3e4bddb space-y-3"><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="3a7e355c0c21" _type="link" class="font-roboto" href="/platform/distributed-tracing">Distributed Tracing</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="57c3e96709fa" _type="link" class="font-roboto" href="/platform/log-analytics">Log Analytics</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="7c7fa92d4ab4" _type="link" class="font-roboto" href="/platform/metrics">Time Series Metrics</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="62cd2b120845" _type="link" class="font-roboto" href="/platform/frontend-observability">Frontend Observability</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="1c28ef24a5cd" _type="link" class="font-roboto" href="/platform/telemetry-pipeline">Telemetry Pipeline</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="a352c53a8036" _type="link" class="font-roboto" href="/platform/private-cloud">Private Cloud</a></li></ul></li><li class="jsx-62ee9791d3e4bddb lg:flex lg:flex-col lg:gap-3"><span class="jsx-62ee9791d3e4bddb font-roboto border-hc-gray-400 border-b font-bold whitespace-nowrap lg:pb-3">AI Agent Observability</span><ul class="jsx-62ee9791d3e4bddb space-y-3"><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="6218cd7e67db" _type="link" class="font-roboto" href="/platform/agent-timeline">Agent Timeline</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="4f3399612de8" _type="link" class="font-roboto" href="/use-cases/ai-llm-observability">LLM Observability</a></li></ul></li><li class="jsx-62ee9791d3e4bddb lg:flex lg:flex-col lg:gap-3"><a target="_self" _type="link" class="font-roboto border-hc-gray-400 group/arrow-link hover:text-hc-cobalt flex items-center border-b font-bold whitespace-nowrap lg:gap-2 lg:pb-3" href="/platform/intelligence">Agentic Intelligence<svg width="11" height="12" viewBox="0 0 11 12" fill="none" xmlns="http://www.w3.org/2000/svg" class="transition-transform group-hover/arrow-link:translate-x-2 max-lg:hidden"><path d="M5 1L10 6L5 11" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path></svg></a><ul class="jsx-62ee9791d3e4bddb space-y-3"><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="bafda870cc04" _type="link" class="font-roboto" href="/platform/canvas">Canvas</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="e4c44c9abcc8" _type="link" class="font-roboto" href="/technologies/ai-agents">MCP</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="146b1517edde" _type="link" class="font-roboto" href="/blog/accelerate-opentelemetry-migrations-honeycomb-agent-skills">MCP Skills</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="89cfc92cfad2" _type="link" class="font-roboto" href="/blog/introducing-anomaly-detection-early-warning-system-service-health">Anomaly Detection</a></li></ul></li><li class="jsx-62ee9791d3e4bddb lg:flex lg:flex-col lg:gap-3"><span class="jsx-62ee9791d3e4bddb font-roboto border-hc-gray-400 border-b font-bold whitespace-nowrap lg:pb-3">Built-in Features</span><ul class="jsx-62ee9791d3e4bddb space-y-3"><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="043ac481e220" _type="link" class="font-roboto" href="/platform/slos">SLOs</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="ad585cbbd043" _type="link" class="font-roboto" href="/platform/service-map">Service Map</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="bafe0c86bbaf" _type="link" class="font-roboto" href="/platform/bubbleup">BubbleUp</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="e8757ff0a28a" _type="link" class="font-roboto" href="/platform/opentelemetry">OpenTelemetry</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="d1f9cc290db7" _type="link" class="font-roboto" href="/platform/integrations">App Integrations</a></li></ul></li></ul><div class="jsx-62ee9791d3e4bddb"></div></div></div></div><div class="jsx-62ee9791d3e4bddb group lg:after:bg-hc-cobalt relative lg:px-1 lg:after:absolute lg:after:bottom-5 lg:after:left-0 lg:after:h-[2px] lg:after:w-0 lg:after:transition-[width] lg:after:duration-200 lg:after:ease-in-out lg:after:content-[&#x27;&#x27;] first:lg:pl-0 lg:focus-within:after:mx-1 lg:focus-within:after:w-[calc(100%_-_8px)] lg:first:focus-within:after:mx-0 lg:first:focus-within:after:w-[calc(100%_-_4px)] lg:hover:after:mx-2 lg:hover:after:w-[calc(100%_-_8px)] lg:first:hover:after:mx-0 lg:first:hover:after:w-[calc(100%_-_4px)] xl:px-3.5 xl:focus-within:after:mx-3.5 xl:focus-within:after:w-[calc(100%_-_28px)] xl:first:focus-within:after:w-[calc(100%_-_14px)] xl:hover:after:mx-3.5 xl:hover:after:w-[calc(100%_-_28px)] xl:first:hover:after:w-[calc(100%_-_14px)]"><button aria-expanded="false" aria-haspopup="true" class="jsx-62ee9791d3e4bddb font-roboto flex w-full items-center justify-between text-left max-lg:cursor-default max-lg:text-xl max-lg:font-medium lg:pointer-events-none lg:block lg:py-10">Solutions<svg width="11" height="12" viewBox="0 0 11 12" fill="none" xmlns="http://www.w3.org/2000/svg" class="lg:hidden"><path d="M5 1L10 6L5 11" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path></svg></button><div class="jsx-62ee9791d3e4bddb menu fixed left-0 z-50 hidden w-full bg-[linear-gradient(to_right,_#f6f6f6_50%,_white_50%)] lg:top-[var(--navBottom,104px)] lg:group-focus-within:block lg:group-hover:block"><div class="jsx-62ee9791d3e4bddb container flex gap-12 xl:max-w-[1180px]"><div class="jsx-62ee9791d3e4bddb max-w-[170px] pt-12 pb-16"><h4 class="jsx-62ee9791d3e4bddb font-roboto mb-2 text-2xl font-bold">Why Honeycomb</h4><p class="jsx-62ee9791d3e4bddb mb-6 text-sm tracking-wide"> <!-- -->Discover why Honeycomb is the better choice for your engineers, your customers, and your bottom line.</p><a target="_self" _type="link" class="font-roboto focus-visible:ring-ring inline-block cursor-pointer text-center font-bold tracking-[1.4px] uppercase transition-[color,background-color] [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 border-hc-cobalt text-hc-cobalt border-2 border-solid bg-transparent h-8 content-center rounded-md px-3 py-2 text-xs hover:border-hc-cobalt hover:bg-hc-cobalt hover:text-white" href="/why-honeycomb"><span class="flex items-center justify-center gap-2.5">Learn More</span></a></div><ul class="jsx-62ee9791d3e4bddb flex grow flex-wrap gap-x-4 bg-white pt-12 pb-16 pl-12 lg:gap-y-3 xl:gap-x-12"><li class="jsx-62ee9791d3e4bddb lg:flex lg:flex-col lg:gap-3"><span class="jsx-62ee9791d3e4bddb font-roboto border-hc-gray-400 border-b font-bold whitespace-nowrap lg:pb-3">Technologies</span><ul class="jsx-62ee9791d3e4bddb space-y-3"><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="973236213b56" _type="link" class="font-roboto" href="/platform/opentelemetry">OpenTelemetry</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="31d4054b0539" _type="link" class="font-roboto" href="/technologies/aws">Amazon Web Services</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="e4533f4323a3" _type="link" class="font-roboto" href="/technologies/microsoft-azure">Microsoft Azure</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="37dbd8aeb8c4" _type="link" class="font-roboto" href="/technologies/kubernetes">Kubernetes</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="6413768f27dc" _type="link" class="font-roboto" href="/technologies/google-cloud">Google Cloud</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="e3ba65b3e56a" _type="link" class="font-roboto" href="/technologies/ai-agents">AI Agents</a></li></ul></li><li class="jsx-62ee9791d3e4bddb lg:flex lg:flex-col lg:gap-3"><span class="jsx-62ee9791d3e4bddb font-roboto border-hc-gray-400 border-b font-bold whitespace-nowrap lg:pb-3">Use Cases</span><ul class="jsx-62ee9791d3e4bddb space-y-3"><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="12dfc27e1b09" _type="link" class="font-roboto" href="/use-cases/ai-llm-observability">LLM Observability</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="ag3nt0bs3rv01" _type="link" class="font-roboto" href="/use-cases/agent-observability">Agent Observability</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="cdb5d85b653f" _type="link" class="font-roboto" href="/use-cases/incident-response">Incident Response</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="05d3787884f2" _type="link" class="font-roboto" href="/use-cases/predictable-costs">Predictable Costs</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="d56b2265ff47" _type="link" class="font-roboto" href="/use-cases/devops-releases">DevOps &amp; Releases</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="687be93e73cd" _type="link" class="font-roboto" href="/platform/frontend-observability">Frontend Development</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="fd9b0d71772c" _type="link" class="font-roboto" href="/use-cases/meet-customer-experience-slas">Meet Customer SLAs</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="64e59d6ab8aa" _type="link" class="font-roboto" href="/use-cases/cloud-migrations">Cloud Migrations</a></li></ul></li><li class="jsx-62ee9791d3e4bddb lg:flex lg:flex-col lg:gap-3"><span class="jsx-62ee9791d3e4bddb font-roboto border-hc-gray-400 border-b font-bold whitespace-nowrap lg:pb-3">Industries</span><ul class="jsx-62ee9791d3e4bddb space-y-3"><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="ece052132a81" _type="link" class="font-roboto" href="/industries/ai-startups">AI Startups</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="8e6dab1d6286" _type="link" class="font-roboto" href="/industries/financial-services">Financial Services</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="440f49eafb36" _type="link" class="font-roboto" href="/industries/retail">Retail &amp; Ecommerce</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="9cb0aa2dcebe" _type="link" class="font-roboto" href="/industries/software-technology">Software &amp; Technology</a></li></ul></li><li class="jsx-62ee9791d3e4bddb lg:flex lg:flex-col lg:gap-3"><a target="_self" _type="link" class="font-roboto border-hc-gray-400 group/arrow-link hover:text-hc-cobalt flex items-center border-b font-bold whitespace-nowrap lg:gap-2 lg:pb-3" href="/why-honeycomb">Why Honeycomb?<svg width="11" height="12" viewBox="0 0 11 12" fill="none" xmlns="http://www.w3.org/2000/svg" class="transition-transform group-hover/arrow-link:translate-x-2 max-lg:hidden"><path d="M5 1L10 6L5 11" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path></svg></a><ul class="jsx-62ee9791d3e4bddb space-y-3"><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="91d95a07e165" _type="link" class="font-roboto" href="/why-honeycomb/customers">Customer Stories</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="05a8b16c4187" _type="link" class="font-roboto" href="/why-honeycomb/comparisons">Comparisons</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="eda3f9bc2fd1" _type="link" class="font-roboto" href="/why-honeycomb/enterprise">For Enterprise</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="711d9271d964" _type="link" class="font-roboto" href="/why-honeycomb/services">Honeycomb Services</a></li></ul></li></ul><div class="jsx-62ee9791d3e4bddb"></div></div></div></div><div class="jsx-62ee9791d3e4bddb group lg:after:bg-hc-cobalt relative lg:px-1 lg:after:absolute lg:after:bottom-5 lg:after:left-0 lg:after:h-[2px] lg:after:w-0 lg:after:transition-[width] lg:after:duration-200 lg:after:ease-in-out lg:after:content-[&#x27;&#x27;] first:lg:pl-0 lg:focus-within:after:mx-1 lg:focus-within:after:w-[calc(100%_-_8px)] lg:first:focus-within:after:mx-0 lg:first:focus-within:after:w-[calc(100%_-_4px)] lg:hover:after:mx-2 lg:hover:after:w-[calc(100%_-_8px)] lg:first:hover:after:mx-0 lg:first:hover:after:w-[calc(100%_-_4px)] xl:px-3.5 xl:focus-within:after:mx-3.5 xl:focus-within:after:w-[calc(100%_-_28px)] xl:first:focus-within:after:w-[calc(100%_-_14px)] xl:hover:after:mx-3.5 xl:hover:after:w-[calc(100%_-_28px)] xl:first:hover:after:w-[calc(100%_-_14px)]"><button aria-expanded="false" aria-haspopup="true" class="jsx-62ee9791d3e4bddb font-roboto flex w-full items-center justify-between text-left max-lg:cursor-default max-lg:text-xl max-lg:font-medium lg:pointer-events-none lg:block lg:py-10">Learn <svg width="11" height="12" viewBox="0 0 11 12" fill="none" xmlns="http://www.w3.org/2000/svg" class="lg:hidden"><path d="M5 1L10 6L5 11" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path></svg></button><div class="jsx-62ee9791d3e4bddb menu fixed left-0 z-50 hidden w-full bg-[linear-gradient(to_right,_#f6f6f6_50%,_white_50%)] lg:top-[var(--navBottom,104px)] lg:group-focus-within:block lg:group-hover:block"><div class="jsx-62ee9791d3e4bddb container flex gap-12 xl:max-w-[1180px]"><div class="jsx-62ee9791d3e4bddb max-w-[170px] pt-12 pb-16"><h4 class="jsx-62ee9791d3e4bddb font-roboto mb-2 text-2xl font-bold">Observability Engineering</h4><p class="jsx-62ee9791d3e4bddb mb-6 text-sm tracking-wide"> <!-- -->Start your journey with the definitive guide to observability. Download our complimentary ebook.</p><a target="_self" _type="link" class="font-roboto focus-visible:ring-ring inline-block cursor-pointer text-center font-bold tracking-[1.4px] uppercase transition-[color,background-color] [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 border-hc-cobalt text-hc-cobalt border-2 border-solid bg-transparent h-8 content-center rounded-md px-3 py-2 text-xs hover:border-hc-cobalt hover:bg-hc-cobalt hover:text-white" href="/observability-engineering-oreilly-book"><span class="flex items-center justify-center gap-2.5">Get your copy</span></a></div><ul class="jsx-62ee9791d3e4bddb flex grow flex-wrap gap-x-4 bg-white pt-12 pb-16 pl-12 lg:gap-y-3 xl:gap-x-12"><li class="jsx-62ee9791d3e4bddb lg:flex lg:flex-col lg:gap-3"><span class="jsx-62ee9791d3e4bddb font-roboto border-hc-gray-400 border-b font-bold whitespace-nowrap lg:pb-3">Engineers</span><ul class="jsx-62ee9791d3e4bddb space-y-3"><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_blank" rel="noopener noreferrer" _key="0579b3261d13" _type="link" class="font-roboto" href="https://docs.honeycomb.io/">Docs</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="ed11462fee29" _type="link" class="font-roboto" href="/observability-engineering-oreilly-book">Observability Engineering</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_blank" rel="noopener noreferrer" _key="acf97f14bc60" _type="link" class="font-roboto" href="https://docs.honeycomb.io/get-started">Quickstart</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_blank" rel="noopener noreferrer" _key="a54f159c78a0" _type="link" class="font-roboto" href="https://docs.honeycomb.io/send-data/">Sending data</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_blank" rel="noopener noreferrer" _key="053ed6ac8255" _type="link" class="font-roboto" href="https://play.honeycomb.io/sandbox/tours">Sandbox</a></li></ul></li><li class="jsx-62ee9791d3e4bddb lg:flex lg:flex-col lg:gap-3"><a target="_self" _type="link" class="font-roboto border-hc-gray-400 group/arrow-link hover:text-hc-cobalt flex items-center border-b font-bold whitespace-nowrap lg:gap-2 lg:pb-3" href="/resources">Resource Center<svg width="11" height="12" viewBox="0 0 11 12" fill="none" xmlns="http://www.w3.org/2000/svg" class="transition-transform group-hover/arrow-link:translate-x-2 max-lg:hidden"><path d="M5 1L10 6L5 11" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path></svg></a><ul class="jsx-62ee9791d3e4bddb space-y-3"><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="104a20760fd8" _type="link" class="font-roboto" href="/blog">Blog</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="6d821088a12e" _type="link" class="font-roboto" href="/resources/getting-started">Getting Started</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="e4d103599e59" _type="link" class="font-roboto" href="/resources/guides">Technical Guides</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="84b6f5e31734" _type="link" class="font-roboto" href="/resources/case-studies">Case Studies</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="a7b9915d2b3b" _type="link" class="font-roboto" href="/resources/webinars">Webinars</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="a3e557190042" _type="link" class="font-roboto" href="/resources/whitepapers">Whitepapers</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="f6862a0a3b48" _type="link" class="font-roboto" href="/resources/product-videos">Product Videos</a></li></ul></li><li class="jsx-62ee9791d3e4bddb lg:flex lg:flex-col lg:gap-3"><span class="jsx-62ee9791d3e4bddb font-roboto border-hc-gray-400 border-b font-bold whitespace-nowrap lg:pb-3">Community</span><ul class="jsx-62ee9791d3e4bddb space-y-3"><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="8a2f7421464f" _type="link" class="font-roboto" href="/events">Events</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_self" _key="eb8b17f096e8" _type="link" class="font-roboto" href="/office-hours">Office Hours</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_blank" rel="noopener noreferrer" _key="bb0360e4b1ad" _type="link" class="font-roboto" href="https://join.slack.com/t/honeycombpollinators/shared_invite/zt-3zl4f8i68-1PhyiwIIqZ0mCXtJjJcSsg">Pollinators Slack</a></li></ul></li><li class="jsx-62ee9791d3e4bddb lg:flex lg:flex-col lg:gap-3"><a target="_blank" rel="noopener noreferrer" _type="link" class="font-roboto border-hc-gray-400 group/arrow-link hover:text-hc-cobalt flex items-center border-b font-bold whitespace-nowrap lg:gap-2 lg:pb-3" href="https://academy.honeycomb.io/">Honeycomb Academy<svg width="11" height="12" viewBox="0 0 11 12" fill="none" xmlns="http://www.w3.org/2000/svg" class="transition-transform group-hover/arrow-link:translate-x-2 max-lg:hidden"><path d="M5 1L10 6L5 11" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path></svg></a><ul class="jsx-62ee9791d3e4bddb space-y-3"><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_blank" rel="noopener noreferrer" _key="b410785737ee" _type="link" class="font-roboto" href="https://academy.honeycomb.io/app/catalog">Course Catalog</a></li><li class="jsx-62ee9791d3e4bddb hover:text-hc-cobalt"><a target="_blank" rel="noopener noreferrer" _key="eba7082cbcd2" _type="link" class="font-roboto" href="https://academy.honeycomb.io/app/learning_paths">Learning Paths</a></li></ul></li></ul><div class="jsx-62ee9791d3e4bddb"></div></div></div></div><div class="jsx-62ee9791d3e4bddb group lg:after:bg-hc-cobalt relative lg:px-1 lg:after:absolute lg:after:bottom-5 lg:after:left-0 lg:after:h-[2px] lg:after:w-0 lg:after:transition-[width] lg:after:duration-200 lg:after:ease-in-out lg:after:content-[&#x27;&#x27;] first:lg:pl-0 lg:focus-within:after:mx-1 lg:focus-within:after:w-[calc(100%_-_8px)] lg:first:focus-within:after:mx-0 lg:first:focus-within:after:w-[calc(100%_-_4px)] lg:hover:after:mx-2 lg:hover:after:w-[calc(100%_-_8px)] lg:first:hover:after:mx-0 lg:first:hover:after:w-[calc(100%_-_4px)] xl:px-3.5 xl:focus-within:after:mx-3.5 xl:focus-within:after:w-[calc(100%_-_28px)] xl:first:focus-within:after:w-[calc(100%_-_14px)] xl:hover:after:mx-3.5 xl:hover:after:w-[calc(100%_-_28px)] xl:first:hover:after:w-[calc(100%_-_14px)]"><button aria-expanded="false" aria-haspopup="true" class="jsx-62ee9791d3e4bddb font-roboto flex w-full items-center justify-between text-left max-lg:cursor-default max-lg:text-xl max-lg:font-medium lg:pointer-events-none lg:block lg:py-10">Company<svg width="11" height="12" viewBox="0 0 11 12" fill="none" xmlns="http://www.w3.org/2000/svg" class="lg:hidden"><path d="M5 1L10 6L5 11" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path></svg></button><div class="jsx-62ee9791d3e4bddb menu fixed left-0 z-50 hidden w-full bg-[linear-gradient(to_right,_#f6f6f6_50%,_white_50%)] lg:top-[var(--navBottom,104px)] lg:group-focus-within:block lg:group-hover:block"><div class="jsx-62ee9791d3e4bddb container flex gap-12 xl:max-w-[1180px]"><div class="jsx-62ee9791d3e4bddb max-w-[170px] pt-12 pb-16"><h4 class="jsx-62ee9791d3e4bddb font-roboto mb-2 text-2xl font-bold">Our mission</h4><p class="jsx-62ee9791d3e4bddb mb-6 text-sm tracking-wide"> <!-- -->Bring observability to every software engineer.</p><a target="_self" _type="link" class="font-roboto focus-visible:ring-ring inline-block cursor-pointer text-center font-bold tracking-[1.4px] uppercase transition-[color,background-color] [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 border-hc-cobalt text-hc-cobalt border-2 border-solid bg-transparent h-8 content-center rounded-md px-3 py-2 text-xs hover:border-hc-cobalt hover:bg-hc-cobalt hover:text-white" href="/about"><span class="flex items-center justify-center gap-2.5">About Us</span></a></div><ul class="jsx-62ee9791d3e4bddb flex grow flex-wrap gap-x-4 bg-white pt-12 pb-16 pl-12 lg:gap-y-3 xl:gap-x-12"><li class="jsx-62ee9791d3e4bddb lg:flex lg:flex-col lg:gap-3"><a target="_self" _type="link" class="font-roboto border-hc-gray-400 group/arrow-link hover:text-hc-cobalt flex items-center border-b font-bold whitespace-nowrap lg:gap-2 lg:pb-3" href="/about">About Us<svg width="11" height="12" viewBox="0 0 11 12" fill="none" xmlns="http://www.w3.org/2000/svg" class="transition-transform group-hover/arrow-link:translate-x-2 max-lg:hidden"><path d="M5 1L10 6L5 11" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path></svg></a><p class="jsx-62ee9791d3e4bddb font-roboto max-w-[138px] text-xs leading-5 tracking-wide">Learn about our company, mission and values.</p></li><li class="jsx-62ee9791d3e4bddb lg:flex lg:flex-col lg:gap-3"><a target="_self" _type="link" class="font-roboto border-hc-gray-400 group/arrow-link hover:text-hc-cobalt flex items-center border-b font-bold whitespace-nowrap lg:gap-2 lg:pb-3" href="/careers">Careers<svg width="11" height="12" viewBox="0 0 11 12" fill="none" xmlns="http://www.w3.org/2000/svg" class="transition-transform group-hover/arrow-link:translate-x-2 max-lg:hidden"><path d="M5 1L10 6L5 11" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path></svg></a><p class="jsx-62ee9791d3e4bddb font-roboto max-w-[138px] text-xs leading-5 tracking-wide">Come for the impact, stay for the culture.
</p></li><li class="jsx-62ee9791d3e4bddb lg:flex lg:flex-col lg:gap-3"><a target="_self" _type="link" class="font-roboto border-hc-gray-400 group/arrow-link hover:text-hc-cobalt flex items-center border-b font-bold whitespace-nowrap lg:gap-2 lg:pb-3" href="/news">News<svg width="11" height="12" viewBox="0 0 11 12" fill="none" xmlns="http://www.w3.org/2000/svg" class="transition-transform group-hover/arrow-link:translate-x-2 max-lg:hidden"><path d="M5 1L10 6L5 11" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path></svg></a><p class="jsx-62ee9791d3e4bddb font-roboto max-w-[138px] text-xs leading-5 tracking-wide">See Honeycomb&#x27;s latest press releases, media, and more</p></li><li class="jsx-62ee9791d3e4bddb lg:flex lg:flex-col lg:gap-3"><a target="_self" _type="link" class="font-roboto border-hc-gray-400 group/arrow-link hover:text-hc-cobalt flex items-center border-b font-bold whitespace-nowrap lg:gap-2 lg:pb-3" href="/partners">Partners<svg width="11" height="12" viewBox="0 0 11 12" fill="none" xmlns="http://www.w3.org/2000/svg" class="transition-transform group-hover/arrow-link:translate-x-2 max-lg:hidden"><path d="M5 1L10 6L5 11" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path></svg></a><p class="jsx-62ee9791d3e4bddb font-roboto max-w-[138px] text-xs leading-5 tracking-wide">Learn more about becoming a Honeycomb partner.</p></li></ul><div class="jsx-62ee9791d3e4bddb"></div></div></div></div><a target="_self" _key="b519e18d3109" _type="link" class="font-roboto lg:after:bg-hc-cobalt hover:text-hc-cobalt relative max-lg:flex max-lg:items-center max-lg:justify-between max-lg:text-xl max-lg:font-medium lg:px-1 lg:py-10 lg:after:absolute lg:after:bottom-5 lg:after:left-0 lg:after:h-[2px] lg:after:w-0 lg:after:transition-[width] lg:after:duration-200 lg:after:ease-in-out lg:after:content-[&#x27;&#x27;] lg:hover:after:w-full xl:px-[14px]" href="/pricing">Pricing<svg width="11" height="12" viewBox="0 0 11 12" fill="none" xmlns="http://www.w3.org/2000/svg" class="lg:hidden"><path d="M5 1L10 6L5 11" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path></svg></a></nav><div id="custom-nav-button-target" class="jsx-62ee9791d3e4bddb flex items-center gap-5"><button aria-label="Search" class="jsx-62ee9791d3e4bddb search-icon"><svg xmlns="http://www.w3.org/2000/svg" width="20" height="20" viewBox="0 0 20 20" fill="none" stroke="#25303E"><path d="M8.875 16.75C13.2242 16.75 16.75 13.2242 16.75 8.875C16.75 4.52576 13.2242 1 8.875 1C4.52576 1 1 4.52576 1 8.875C1 13.2242 4.52576 16.75 8.875 16.75Z" stroke="inherit" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"></path><path d="M14.4434 14.4438L18.9997 19.0002" stroke="inherit" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"></path></svg></button><a target="_blank" class="hover:text-hc-cobalt font-roboto login-button max-lg:hidden" href="https://ui.honeycomb.io/login">Login</a><a target="_self" _type="link" class="font-roboto focus-visible:ring-ring inline-block cursor-pointer text-center font-bold tracking-[1.4px] uppercase transition-[color,background-color] [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 border-hc-cobalt bg-hc-cobalt hover:bg-hc-pacific hover:border-hc-pacific border-2 border-solid text-white h-8 content-center rounded-md px-3 py-2 text-xs nav-button max-lg:hidden qdemo get-a-demo-button" href="/get-a-demo"><span class="flex items-center justify-center gap-2.5">Get a demo</span></a><a target="_self" _type="link" class="font-roboto focus-visible:ring-ring inline-block cursor-pointer text-center font-bold tracking-[1.4px] uppercase transition-[color,background-color] [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 border-hc-cobalt text-hc-cobalt hover:text-hc-pacific hover:border-hc-pacific border-2 border-solid bg-transparent h-8 content-center rounded-md px-3 py-2 text-xs nav-button max-lg:hidden" href="https://ui.honeycomb.io/signup"><span class="flex items-center justify-center gap-2.5">Start for free</span></a><button aria-label="Menu" class="jsx-62ee9791d3e4bddb menu-icon lg:hidden"><svg xmlns="http://www.w3.org/2000/svg" width="32" height="22" viewBox="0 0 32 22" fill="none"><path d="M1 1H31" stroke="#25303E" stroke-width="2" stroke-linecap="round"></path><path d="M1 11H31" stroke="#25303E" stroke-width="2" stroke-linecap="round"></path><path d="M1 21H31" stroke="#25303E" stroke-width="2" stroke-linecap="round"></path></svg></button></div><div class="jsx-62ee9791d3e4bddb mt-6 hidden justify-center gap-1 md:justify-start"><p class="jsx-62ee9791d3e4bddb">Already a Honeycomb customer?</p><a target="_blank" class="text-hc-cobalt underline" href="https://ui.honeycomb.io/login">Login</a></div></div></header><script type="application/ld+json">{"@context":"https://schema.org","@graph":[{"@type":["WebPage","CollectionPage"],"@id":"https://www.honeycomb.io/blog","url":"https://www.honeycomb.io/blog","name":"Observability, Distributed Tracing, and More - Honeycomb Blog","isPartOf":{"@id":"https://www.honeycomb.io/#website"},"datePublished":"2018-12-31T15:45:13+00:00","dateModified":"2026-09-11T03:20:08+00:00","description":"Learn about observability vs. monitoring, OpenTelemetry, and more on the Honeycomb blog.","breadcrumb":{"@id":"https://www.honeycomb.io/blog#breadcrumb"},"inLanguage":"en-US","primaryImageOfPage":{"@id":"https://www.honeycomb.io/blog#primaryimage"},"image":{"@id":"https://www.honeycomb.io/blog#primaryimage"},"thumbnailUrl":"https://cdn.sanity.io/images/927dxq0h/production/ff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png"},{"@type":"ImageObject","inLanguage":"en-US","@id":"https://www.honeycomb.io/blog#primaryimage","url":"https://cdn.sanity.io/images/927dxq0h/production/ff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png","contentUrl":"https://cdn.sanity.io/images/927dxq0h/production/ff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png","width":3840,"height":2160,"caption":"Observability, Distributed Tracing, and More - Honeycomb Blog"},{"@type":"BreadcrumbList","@id":"https://www.honeycomb.io/blog#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://www.honeycomb.io/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://www.honeycomb.io/blog"}]},{"@type":"WebSite","@id":"https://www.honeycomb.io/#website","url":"https://www.honeycomb.io/","name":"Honeycomb","description":"Event Driven Debugging","publisher":{"@id":"https://www.honeycomb.io/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://www.honeycomb.io/search?searchTerm={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https://www.honeycomb.io/#organization","name":"Honeycomb","url":"https://www.honeycomb.io/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https://www.honeycomb.io/#/schema/logo/image/","url":"https://www.honeycomb.io/api/assets/honeycomb-logo.svg","contentUrl":"https://www.honeycomb.io/api/assets/honeycomb-logo.svg","width":164,"height":48,"caption":"Honeycomb"},"image":{"@id":"https://www.honeycomb.io/#/schema/logo/image/"},"sameAs":["https://x.com/honeycombio"]}]}</script><main class="my-5"><div class="container justify-items-center px-6 pt-5 pb-9 min-[428px]:px-0 md:justify-items-start md:px-12 md:pb-8 lg:px-12 xl:px-0"><nav aria-label="breadcrumb"><ol class="text-hc-slate flex flex-wrap items-center gap-1.5 text-xs break-words sm:gap-2.5"><li class="inline-flex items-center gap-1.5"><a class="font-roboto font-medium transition-colors hover:underline" href="/resources">Resources</a></li><li role="presentation" aria-hidden="true" class="[&amp;&gt;svg]:h-3.5 [&amp;&gt;svg]:w-3.5"><svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="lucide lucide-chevron-right"><path d="m9 18 6-6-6-6"></path></svg></li><li class="inline-flex items-center gap-1.5"><a class="font-roboto font-medium transition-colors hover:underline" href="/blog">Blog</a></li></ol></nav></div><div class="container mb-8 flex flex-col items-center gap-6 px-6 min-[428px]:px-0 md:px-12 lg:flex-row lg:items-stretch xl:px-0"><div class="flex grow flex-col gap-5"><div class="flex flex-col items-center gap-[10px] md:items-baseline md:px-6"><a href="blog"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Blog</div></a><h1 class="text-h1 text-hc-slate text-balance">Honeycomb Blog</h1></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-hc-gray-50"><a title="AI Norms &amp; Values, Part 3 of 3: Things We Hold True" href="/blog/ai-norms-values-part-3-things-we-hold-true"><div class="relative max-w-full"><img alt="AI Norms &amp; Values, Part 3 of 3: Things We Hold True" fetchPriority="high" loading="eager" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover max-h-[402px]" style="color:transparent" sizes="(max-width: 1024px) 100vw, 50vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 gap-10 max-xl:flex-1 md:h-[304px] xl:justify-between"><div class="flex flex-col gap-4"><div class="flex items-center gap-3"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>September 9, 2026</span></span><span class="font-extralight opacity-30 block"> | </span><div class="flex items-center gap-[6px]"><img alt="Charity Majors" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/charity">Charity Majors</a></p></div></div><a class="flex flex-col gap-[10px]" href="/blog/ai-norms-values-part-3-things-we-hold-true"><h3 class="font-poppins line-clamp-2 text-2xl/tight font-medium md:text-[36px] md:leading-11">AI Norms &amp; Values, Part 3 of 3: Things We Hold True</h3><p class="line-clamp-5 text-sm/normal md:line-clamp-3 md:text-base">The final part of Honeycomb&#x27;s AI Norms &amp; Values series: the principles the company holds true about AI as a tool, ownership of work, and rising standards; how it actually uses AI day to day; usage patterns for respecting each other&#x27;s time; and where it stands on AI&#x27;s ethical externalities like energy use, IP, bias, and wages.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a><a href="/blog/category/culture"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Culture</div></a></div></div></div></div><div class="bg-hc-gray-50 flex w-full shrink-0 flex-col gap-5 rounded-[20px] p-6 lg:w-[375px]"><h2 class="text-h6">Featured</h2><div class="divide-hc-gray-200 flex flex-col gap-5 divide-y"><div class="flex flex-col gap-2 pb-5"><div class="flex items-center gap-3"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>September 2, 2026</span></span><span class="font-extralight opacity-30 block"> | </span><div class="flex items-center gap-[6px]"><img alt="Charity Majors" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/charity">Charity Majors</a></p></div></div><a class="font-roboto text-hc-slate line-clamp-2 text-base/snug font-medium" href="/blog/ai-norms-values-part-2-ai-honeycomb-engineering">AI Norms &amp; Values, Part 2 of 3: AI for Honeycomb Engineering</a><div class="flex flex-wrap gap-3"><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a><a href="/blog/category/culture"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Culture</div></a></div></div><div class="flex flex-col gap-2 pb-5"><div class="flex items-center gap-3"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>August 31, 2026</span></span><span class="font-extralight opacity-30 block"> | </span><div class="flex items-center gap-[6px]"><img alt="Rox Williams" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ffb0dadab9def700cd5661ade34b9557c7d1b18f8-180x200.jpg%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ffb0dadab9def700cd5661ade34b9557c7d1b18f8-180x200.jpg%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ffb0dadab9def700cd5661ade34b9557c7d1b18f8-180x200.jpg%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/rox-williams">Rox Williams</a></p></div></div><a class="font-roboto text-hc-slate line-clamp-2 text-base/snug font-medium" href="/blog/fin-cto-building-great-engineering-organizations-ai-era">Fin&#x27;s CTO on Building Great Engineering Organizations in the AI Era</a><div class="flex flex-wrap gap-3"><a href="/blog/category/llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a><a href="/blog/category/observability"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Observability</div></a><a href="/blog/category/software-engineering"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Software Engineering</div></a></div></div><div class="flex flex-col gap-2 pb-5"><div class="flex items-center gap-3"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>August 20, 2026</span></span><span class="font-extralight opacity-30 block"> | </span><div class="flex items-center gap-[6px]"><img alt="Charity Majors" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/charity">Charity Majors</a></p></div></div><a class="font-roboto text-hc-slate line-clamp-2 text-base/snug font-medium" href="/blog/ai-norms-values-part-1-how-we-do-business-at-honeycomb">AI Norms &amp; Values, Part 1 of 3: How We Do Business at Honeycomb</a><div class="flex flex-wrap gap-3"><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a><a href="/blog/category/culture"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Culture</div></a></div></div><div class="flex flex-col gap-2 pb-5"><div class="flex items-center gap-3"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>July 20, 2026</span></span><span class="font-extralight opacity-30 block"> | </span><div class="flex items-center gap-[6px]"><img alt="Austin Parker" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2a1050e83bac34eea79bd9f2d5bf7c3fc106550f-600x600.jpg%3Fw%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2a1050e83bac34eea79bd9f2d5bf7c3fc106550f-600x600.jpg%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2a1050e83bac34eea79bd9f2d5bf7c3fc106550f-600x600.jpg%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/austin">Austin Parker</a></p></div></div><a class="font-roboto text-hc-slate line-clamp-2 text-base/snug font-medium" href="/blog/what-comes-after-observability">What Comes After Observability?</a><div class="flex flex-wrap gap-3"><a href="/blog/category/observability"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Observability</div></a><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a></div></div></div></div></div><div class="bg-hc-gray-50"><div class="container gap-6"><section class="py-10"><div><div class="flex w-full flex-col items-center gap-3 md:flex-row md:gap-6"><h2 class="text-h2 text-hc-slate order-1 col-span-6 w-full grow text-left text-balance md:w-auto">Explore Blog</h2><div class="relative w-full order-2 md:w-[348px] md:order-3"><input class="file:text-hc-slate focus-visible:ring-hc-cobalt border-hc-gray-300 placeholder:text-hc-gray-300 font-roboto flex h-[46px] w-full rounded-sm border bg-white px-3 py-3 pl-3 text-sm ring-offset-transparent file:border-0 file:bg-transparent file:text-sm file:font-medium focus-visible:ring-2 focus-visible:ring-offset-0 focus-visible:outline-none disabled:cursor-not-allowed disabled:opacity-50 md:text-sm pr-10" placeholder="Search Keywords"/><svg xmlns="http://www.w3.org/2000/svg" width="21" height="22" fill="none" class="absolute top-3 right-3"><path stroke="#25303E" stroke-linecap="round" stroke-linejoin="round" stroke-width="1.313" d="M9.516 16.906a6.89 6.89 0 1 0 0-13.78 6.89 6.89 0 0 0 0 13.78ZM14.388 14.888l3.987 3.987"></path></svg></div></div><div class="hidden gap-3 md:mt-7 md:flex xl:container"><div class="flex flex-wrap gap-3 md:gap-4"><div class="flex cursor-pointer items-center gap-2"><button type="button" role="checkbox" aria-checked="true" data-state="checked" value="on" class="peer border-hc-slate focus-visible:ring-ring data-[state=checked]:text-hc-slate relative h-4 w-4 shrink-0 rounded-sm border-2 shadow focus-visible:ring-1 focus-visible:outline-none disabled:cursor-not-allowed disabled:opacity-50 data-[state=checked]:bg-white ml-2 cursor-pointer md:hidden"><span data-state="checked" class="flex items-center justify-center text-current" style="pointer-events:none"><div class="bg-hc-cobalt absolute top-[1px] left-[1px] h-[10px] w-[10px] rounded-[2px]"></div></span></button><input type="checkbox" aria-hidden="true" tabindex="-1" style="position:absolute;pointer-events:none;opacity:0;margin:0;transform:translateX(-100%)" checked="" value="on"/><button class="font-roboto focus-visible:ring-ring inline-block text-center [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 border-hc-slate hover:border-hc-slate/90 rounded-lg text-sm leading-normal font-semibold tracking-normal normal-case transition-colors duration-100 ease-linear text-hc-slate md:hover:bg-hc-slate cursor-pointer border-0 bg-transparent p-0 !font-semibold hover:bg-transparent md:border md:px-4 md:py-2 md:font-normal md:hover:text-white md:bg-hc-slate md:text-white" title="All">All</button></div><div class="flex cursor-pointer items-center gap-2"><button type="button" role="checkbox" aria-checked="false" data-state="unchecked" value="on" class="peer border-hc-slate focus-visible:ring-ring data-[state=checked]:text-hc-slate relative h-4 w-4 shrink-0 rounded-sm border-2 shadow focus-visible:ring-1 focus-visible:outline-none disabled:cursor-not-allowed disabled:opacity-50 data-[state=checked]:bg-white ml-2 cursor-pointer md:hidden"></button><input type="checkbox" aria-hidden="true" tabindex="-1" style="position:absolute;pointer-events:none;opacity:0;margin:0;transform:translateX(-100%)" value="on"/><button class="font-roboto focus-visible:ring-ring inline-block text-center [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 hover:text-hc-slate/75 border-hc-slate hover:border-hc-slate/75 rounded-lg text-sm leading-normal font-semibold tracking-normal normal-case transition-colors duration-100 ease-linear text-hc-slate md:hover:bg-hc-slate cursor-pointer border-0 bg-transparent p-0 !font-semibold hover:bg-transparent md:border md:bg-transparent md:px-4 md:py-2 md:font-normal md:hover:text-white" title="Observability">Observability</button></div><div class="flex cursor-pointer items-center gap-2"><button type="button" role="checkbox" aria-checked="false" data-state="unchecked" value="on" class="peer border-hc-slate focus-visible:ring-ring data-[state=checked]:text-hc-slate relative h-4 w-4 shrink-0 rounded-sm border-2 shadow focus-visible:ring-1 focus-visible:outline-none disabled:cursor-not-allowed disabled:opacity-50 data-[state=checked]:bg-white ml-2 cursor-pointer md:hidden"></button><input type="checkbox" aria-hidden="true" tabindex="-1" style="position:absolute;pointer-events:none;opacity:0;margin:0;transform:translateX(-100%)" value="on"/><button class="font-roboto focus-visible:ring-ring inline-block text-center [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 hover:text-hc-slate/75 border-hc-slate hover:border-hc-slate/75 rounded-lg text-sm leading-normal font-semibold tracking-normal normal-case transition-colors duration-100 ease-linear text-hc-slate md:hover:bg-hc-slate cursor-pointer border-0 bg-transparent p-0 !font-semibold hover:bg-transparent md:border md:bg-transparent md:px-4 md:py-2 md:font-normal md:hover:text-white" title="Software Engineering">Software Engineering</button></div><div class="flex cursor-pointer items-center gap-2"><button type="button" role="checkbox" aria-checked="false" data-state="unchecked" value="on" class="peer border-hc-slate focus-visible:ring-ring data-[state=checked]:text-hc-slate relative h-4 w-4 shrink-0 rounded-sm border-2 shadow focus-visible:ring-1 focus-visible:outline-none disabled:cursor-not-allowed disabled:opacity-50 data-[state=checked]:bg-white ml-2 cursor-pointer md:hidden"></button><input type="checkbox" aria-hidden="true" tabindex="-1" style="position:absolute;pointer-events:none;opacity:0;margin:0;transform:translateX(-100%)" value="on"/><button class="font-roboto focus-visible:ring-ring inline-block text-center [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 hover:text-hc-slate/75 border-hc-slate hover:border-hc-slate/75 rounded-lg text-sm leading-normal font-semibold tracking-normal normal-case transition-colors duration-100 ease-linear text-hc-slate md:hover:bg-hc-slate cursor-pointer border-0 bg-transparent p-0 !font-semibold hover:bg-transparent md:border md:bg-transparent md:px-4 md:py-2 md:font-normal md:hover:text-white" title="OpenTelemetry">OpenTelemetry</button></div><div class="flex cursor-pointer items-center gap-2"><button type="button" role="checkbox" aria-checked="false" data-state="unchecked" value="on" class="peer border-hc-slate focus-visible:ring-ring data-[state=checked]:text-hc-slate relative h-4 w-4 shrink-0 rounded-sm border-2 shadow focus-visible:ring-1 focus-visible:outline-none disabled:cursor-not-allowed disabled:opacity-50 data-[state=checked]:bg-white ml-2 cursor-pointer md:hidden"></button><input type="checkbox" aria-hidden="true" tabindex="-1" style="position:absolute;pointer-events:none;opacity:0;margin:0;transform:translateX(-100%)" value="on"/><button class="font-roboto focus-visible:ring-ring inline-block text-center [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 hover:text-hc-slate/75 border-hc-slate hover:border-hc-slate/75 rounded-lg text-sm leading-normal font-semibold tracking-normal normal-case transition-colors duration-100 ease-linear text-hc-slate md:hover:bg-hc-slate cursor-pointer border-0 bg-transparent p-0 !font-semibold hover:bg-transparent md:border md:bg-transparent md:px-4 md:py-2 md:font-normal md:hover:text-white" title="AI &amp; LLMs">AI &amp; LLMs</button></div><div class="flex cursor-pointer items-center gap-2"><button type="button" role="checkbox" aria-checked="false" data-state="unchecked" value="on" class="peer border-hc-slate focus-visible:ring-ring data-[state=checked]:text-hc-slate relative h-4 w-4 shrink-0 rounded-sm border-2 shadow focus-visible:ring-1 focus-visible:outline-none disabled:cursor-not-allowed disabled:opacity-50 data-[state=checked]:bg-white ml-2 cursor-pointer md:hidden"></button><input type="checkbox" aria-hidden="true" tabindex="-1" style="position:absolute;pointer-events:none;opacity:0;margin:0;transform:translateX(-100%)" value="on"/><button class="font-roboto focus-visible:ring-ring inline-block text-center [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 hover:text-hc-slate/75 border-hc-slate hover:border-hc-slate/75 rounded-lg text-sm leading-normal font-semibold tracking-normal normal-case transition-colors duration-100 ease-linear text-hc-slate md:hover:bg-hc-slate cursor-pointer border-0 bg-transparent p-0 !font-semibold hover:bg-transparent md:border md:bg-transparent md:px-4 md:py-2 md:font-normal md:hover:text-white" title="Product Updates">Product Updates</button></div><div class="flex cursor-pointer items-center gap-2"><button type="button" role="checkbox" aria-checked="false" data-state="unchecked" value="on" class="peer border-hc-slate focus-visible:ring-ring data-[state=checked]:text-hc-slate relative h-4 w-4 shrink-0 rounded-sm border-2 shadow focus-visible:ring-1 focus-visible:outline-none disabled:cursor-not-allowed disabled:opacity-50 data-[state=checked]:bg-white ml-2 cursor-pointer md:hidden"></button><input type="checkbox" aria-hidden="true" tabindex="-1" style="position:absolute;pointer-events:none;opacity:0;margin:0;transform:translateX(-100%)" value="on"/><button class="font-roboto focus-visible:ring-ring inline-block text-center [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 hover:text-hc-slate/75 border-hc-slate hover:border-hc-slate/75 rounded-lg text-sm leading-normal font-semibold tracking-normal normal-case transition-colors duration-100 ease-linear text-hc-slate md:hover:bg-hc-slate cursor-pointer border-0 bg-transparent p-0 !font-semibold hover:bg-transparent md:border md:bg-transparent md:px-4 md:py-2 md:font-normal md:hover:text-white" title="Dogfooding">Dogfooding</button></div><div class="flex cursor-pointer items-center gap-2"><button type="button" role="checkbox" aria-checked="false" data-state="unchecked" value="on" class="peer border-hc-slate focus-visible:ring-ring data-[state=checked]:text-hc-slate relative h-4 w-4 shrink-0 rounded-sm border-2 shadow focus-visible:ring-1 focus-visible:outline-none disabled:cursor-not-allowed disabled:opacity-50 data-[state=checked]:bg-white ml-2 cursor-pointer md:hidden"></button><input type="checkbox" aria-hidden="true" tabindex="-1" style="position:absolute;pointer-events:none;opacity:0;margin:0;transform:translateX(-100%)" value="on"/><button class="font-roboto focus-visible:ring-ring inline-block text-center [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 hover:text-hc-slate/75 border-hc-slate hover:border-hc-slate/75 rounded-lg text-sm leading-normal font-semibold tracking-normal normal-case transition-colors duration-100 ease-linear text-hc-slate md:hover:bg-hc-slate cursor-pointer border-0 bg-transparent p-0 !font-semibold hover:bg-transparent md:border md:bg-transparent md:px-4 md:py-2 md:font-normal md:hover:text-white" title="News &amp; Announcements">News &amp; Announcements</button></div><button class="w-auto cursor-pointer px-3 py-2 text-left text-base font-normal"><div class="flex items-center justify-start gap-3"><span class="block">Show all</span><svg width="11" height="12" viewBox="0 0 11 12" fill="none" xmlns="http://www.w3.org/2000/svg" class="size-[12px] rotate-90"><path d="M5 1L10 6L5 11" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path></svg></div></button></div></div><div class="flex flex-row gap-3 md:hidden"><div data-state="closed" class="border-hc-gray-300 lead w-full overflow-hidden rounded-b-md border border-t-0"><button type="button" aria-controls="radix-_R_dslubqiudb_" aria-expanded="false" data-state="closed" class="text-hc-slate w-full cursor-pointer px-4 py-2 text-left"><div class="flex w-full items-center justify-between gap-3"><span class="block text-sm font-bold uppercase">Select a Topic</span><svg width="11" height="12" viewBox="0 0 11 12" fill="none" xmlns="http://www.w3.org/2000/svg" class="text-hc-slate size-[12px] rotate-90"><path d="M5 1L10 6L5 11" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"></path></svg></div></button><div data-state="closed" id="radix-_R_dslubqiudb_" hidden="" class="flex flex-col gap-3 px-4 py-[10px] scrollbar-thumb-rounded-sm scrollbar scrollbar-w-1 scrollbar-track-rounded-sm scrollbar-thumb-hc-cobalt scrollbar-track-hc-gray-100 h-32 overflow-y-scroll"></div></div></div></div></section><div class="relative grid grid-cols-1 gap-6 md:grid-cols-2 lg:grid-cols-3 xl:grid-cols-4"><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="AI Norms &amp; Values, Part 3 of 3: Things We Hold True" href="/blog/ai-norms-values-part-3-things-we-hold-true"><div class="relative max-w-full"><img alt="AI Norms &amp; Values, Part 3 of 3: Things We Hold True" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>September 9, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Charity Majors" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/charity">Charity Majors</a></p></div></div><a class="flex flex-col gap-2" href="/blog/ai-norms-values-part-3-things-we-hold-true"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">AI Norms &amp; Values, Part 3 of 3: Things We Hold True</h3><p class="line-clamp-3 text-sm/normal">The final part of Honeycomb&#x27;s AI Norms &amp; Values series: the principles the company holds true about AI as a tool, ownership of work, and rising standards; how it actually uses AI day to day; usage patterns for respecting each other&#x27;s time; and where it stands on AI&#x27;s ethical externalities like energy use, IP, bias, and wages.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a><a href="/blog/category/culture"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Culture</div></a></div></div></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="Wide Events vs. Three Pillars: AI Observability Costs" href="/blog/wide-events-vs-three-pillars-ai-observability-costs"><div class="relative max-w-full"><img alt="Wide Events vs. Three Pillars: AI Observability Costs" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2f5169f0014bd57114e40e9c6b911bf986e9dd74-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2f5169f0014bd57114e40e9c6b911bf986e9dd74-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2f5169f0014bd57114e40e9c6b911bf986e9dd74-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2f5169f0014bd57114e40e9c6b911bf986e9dd74-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2f5169f0014bd57114e40e9c6b911bf986e9dd74-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2f5169f0014bd57114e40e9c6b911bf986e9dd74-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2f5169f0014bd57114e40e9c6b911bf986e9dd74-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2f5169f0014bd57114e40e9c6b911bf986e9dd74-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2f5169f0014bd57114e40e9c6b911bf986e9dd74-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2f5169f0014bd57114e40e9c6b911bf986e9dd74-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2f5169f0014bd57114e40e9c6b911bf986e9dd74-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>September 8, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Nick Travaglini" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fb5f38a9b0b7fbe587c1b0ff1a88b88ce22a30a58-180x200.jpg%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fb5f38a9b0b7fbe587c1b0ff1a88b88ce22a30a58-180x200.jpg%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fb5f38a9b0b7fbe587c1b0ff1a88b88ce22a30a58-180x200.jpg%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/nickt">Nick Travaglini</a></p></div></div><a class="flex flex-col gap-2" href="/blog/wide-events-vs-three-pillars-ai-observability-costs"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">Wide Events vs. Three Pillars: AI Observability Costs</h3><p class="line-clamp-3 text-sm/normal">AI agents make telemetry costs harder to predict. This post compares the three pillars against the wide event model, and explains why wide events keep AI observability costs predictable without sacrificing the context engineers need.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/observability"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Observability</div></a><a href="/blog/category/llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a><a href="/blog/category/engineering-best-practices"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Engineering Best Practices</div></a></div></div></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="Relational Query Superpowers" href="/blog/relational-query-superpowers"><div class="relative max-w-full"><img alt="Relational Query Superpowers" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F1007d98f384979ca99d321c46ed3e11f4c068f90-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F1007d98f384979ca99d321c46ed3e11f4c068f90-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F1007d98f384979ca99d321c46ed3e11f4c068f90-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F1007d98f384979ca99d321c46ed3e11f4c068f90-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F1007d98f384979ca99d321c46ed3e11f4c068f90-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F1007d98f384979ca99d321c46ed3e11f4c068f90-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F1007d98f384979ca99d321c46ed3e11f4c068f90-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F1007d98f384979ca99d321c46ed3e11f4c068f90-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F1007d98f384979ca99d321c46ed3e11f4c068f90-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F1007d98f384979ca99d321c46ed3e11f4c068f90-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F1007d98f384979ca99d321c46ed3e11f4c068f90-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>September 7, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Ken Rimple" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F70ff19725bb74795b106cac1113ed276442bb3bc-1703x1714.png%3Frect%3D0%2C6%2C1703%2C1703%26w%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F70ff19725bb74795b106cac1113ed276442bb3bc-1703x1714.png%3Frect%3D0%2C6%2C1703%2C1703%26w%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F70ff19725bb74795b106cac1113ed276442bb3bc-1703x1714.png%3Frect%3D0%2C6%2C1703%2C1703%26w%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/kenr">Ken Rimple</a></p></div></div><a class="flex flex-col gap-2" href="/blog/relational-query-superpowers"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">Relational Query Superpowers</h3><p class="line-clamp-3 text-sm/normal">See how Honeycomb&#x27;s relational query keywords—root, parent, child, any, any2, any3, and none—let you pull attributes from anywhere in a single trace into one query, walked through with a real checkout-error investigation.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/tracing-blog"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Tracing</div></a><a href="/blog/category/tutorials"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Tutorials</div></a><a href="/blog/category/observability"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Observability</div></a></div></div></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="AI Norms &amp; Values, Part 2 of 3: AI for Honeycomb Engineering" href="/blog/ai-norms-values-part-2-ai-honeycomb-engineering"><div class="relative max-w-full"><img alt="A split illustration contrasting a blue head wearing a VR headset with rising graphs and a checkmark, against a red head with a VR headset with falling graphs and an X-mark." fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F636c5f52ce744d20378443e4eb803189a1df02d4-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F636c5f52ce744d20378443e4eb803189a1df02d4-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F636c5f52ce744d20378443e4eb803189a1df02d4-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F636c5f52ce744d20378443e4eb803189a1df02d4-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F636c5f52ce744d20378443e4eb803189a1df02d4-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F636c5f52ce744d20378443e4eb803189a1df02d4-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F636c5f52ce744d20378443e4eb803189a1df02d4-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F636c5f52ce744d20378443e4eb803189a1df02d4-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F636c5f52ce744d20378443e4eb803189a1df02d4-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F636c5f52ce744d20378443e4eb803189a1df02d4-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F636c5f52ce744d20378443e4eb803189a1df02d4-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>September 2, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Charity Majors" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/charity">Charity Majors</a></p></div></div><a class="flex flex-col gap-2" href="/blog/ai-norms-values-part-2-ai-honeycomb-engineering"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">AI Norms &amp; Values, Part 2 of 3: AI for Honeycomb Engineering</h3><p class="line-clamp-3 text-sm/normal">Charity Majors shares a note from Emily Nakashima, SVP of Engineering, on why Honeycomb&#x27;s engineering org is going all in on AI, the north star it&#x27;s aiming for, and an honest FAQ about what that means day to day.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a><a href="/blog/category/culture"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Culture</div></a></div></div></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="Bringing the Most Advanced Sampling to the OpenTelemetry Collector" href="/blog/bringing-most-advanced-sampling-opentelemetry-collector"><div class="relative max-w-full"><img alt="Bringing the Most Advanced Sampling to the OpenTelemetry Collector" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6019821b62699e57a45c743922f26176f607a520-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6019821b62699e57a45c743922f26176f607a520-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6019821b62699e57a45c743922f26176f607a520-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6019821b62699e57a45c743922f26176f607a520-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6019821b62699e57a45c743922f26176f607a520-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6019821b62699e57a45c743922f26176f607a520-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6019821b62699e57a45c743922f26176f607a520-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6019821b62699e57a45c743922f26176f607a520-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6019821b62699e57a45c743922f26176f607a520-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6019821b62699e57a45c743922f26176f607a520-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6019821b62699e57a45c743922f26176f607a520-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>September 1, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Mike Goldsmith" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F657bd02b8f3d7988efd68dd3d742fadd95597c9c-180x200.png%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F657bd02b8f3d7988efd68dd3d742fadd95597c9c-180x200.png%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F657bd02b8f3d7988efd68dd3d742fadd95597c9c-180x200.png%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/mike">Mike Goldsmith</a></p></div></div><a class="flex flex-col gap-2" href="/blog/bringing-most-advanced-sampling-opentelemetry-collector"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">Bringing the Most Advanced Sampling to the OpenTelemetry Collector</h3><p class="line-clamp-3 text-sm/normal">Honeycomb is donating its adaptive tail sampling processor, built on years of Refinery experience, to the OpenTelemetry Collector. See how adaptive sampling, trace fingerprinting, and sample rate attribution work, and how to try it today with the Honeycomb Collector Distribution.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/sampling"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Sampling</div></a><a href="/blog/category/observability"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Observability</div></a><a href="/blog/category/opentelemetry"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">OpenTelemetry</div></a></div></div></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="Fin&#x27;s CTO on Building Great Engineering Organizations in the AI Era" href="/blog/fin-cto-building-great-engineering-organizations-ai-era"><div class="relative max-w-full"><img alt="Leading With Observability: Fin&#x27;s CTO on Building Great Engineering Organizations in the AI Era" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F4fedda12c7801612e4511ec3998a7985fe954c94-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F4fedda12c7801612e4511ec3998a7985fe954c94-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F4fedda12c7801612e4511ec3998a7985fe954c94-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F4fedda12c7801612e4511ec3998a7985fe954c94-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F4fedda12c7801612e4511ec3998a7985fe954c94-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F4fedda12c7801612e4511ec3998a7985fe954c94-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F4fedda12c7801612e4511ec3998a7985fe954c94-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F4fedda12c7801612e4511ec3998a7985fe954c94-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F4fedda12c7801612e4511ec3998a7985fe954c94-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F4fedda12c7801612e4511ec3998a7985fe954c94-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F4fedda12c7801612e4511ec3998a7985fe954c94-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>August 31, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Rox Williams" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ffb0dadab9def700cd5661ade34b9557c7d1b18f8-180x200.jpg%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ffb0dadab9def700cd5661ade34b9557c7d1b18f8-180x200.jpg%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ffb0dadab9def700cd5661ade34b9557c7d1b18f8-180x200.jpg%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/rox-williams">Rox Williams</a></p></div></div><a class="flex flex-col gap-2" href="/blog/fin-cto-building-great-engineering-organizations-ai-era"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">Fin&#x27;s CTO on Building Great Engineering Organizations in the AI Era</h3><p class="line-clamp-3 text-sm/normal">Fin (formerly Intercom) CTO Darragh Curran set a public goal to double engineering productivity—and nearly tripled it. In the first episode of Leading With Observability, he talks with Charity Majors about AI-driven PR review, hands-on leadership through the transition, and why observability is the trust mechanism that makes it all work.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a><a href="/blog/category/observability"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Observability</div></a><a href="/blog/category/software-engineering"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Software Engineering</div></a></div></div></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="7 Best Datadog Alternatives for AI and Agent Observability" href="/blog/datadog-alternatives"><div class="relative max-w-full"><img alt="7 Best Datadog Alternatives for AI and Agent Observability" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fbaf13252eea10b081f0ed9d22673d734a271226c-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fbaf13252eea10b081f0ed9d22673d734a271226c-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fbaf13252eea10b081f0ed9d22673d734a271226c-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fbaf13252eea10b081f0ed9d22673d734a271226c-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fbaf13252eea10b081f0ed9d22673d734a271226c-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fbaf13252eea10b081f0ed9d22673d734a271226c-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fbaf13252eea10b081f0ed9d22673d734a271226c-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fbaf13252eea10b081f0ed9d22673d734a271226c-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fbaf13252eea10b081f0ed9d22673d734a271226c-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fbaf13252eea10b081f0ed9d22673d734a271226c-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fbaf13252eea10b081f0ed9d22673d734a271226c-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>August 26, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Kale Bogdanovs" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fa85aba826c3692ea82c1ae6e324da5262dcee117-225x300.jpg%3Frect%3D0%2C38%2C225%2C225%26w%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fa85aba826c3692ea82c1ae6e324da5262dcee117-225x300.jpg%3Frect%3D0%2C38%2C225%2C225%26w%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fa85aba826c3692ea82c1ae6e324da5262dcee117-225x300.jpg%3Frect%3D0%2C38%2C225%2C225%26w%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/kale-bogdanovs">Kale Bogdanovs</a></p></div></div><a class="flex flex-col gap-2" href="/blog/datadog-alternatives"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">7 Best Datadog Alternatives for AI and Agent Observability</h3><p class="line-clamp-3 text-sm/normal">Comparing Datadog alternatives for AI and agent observability? See how Honeycomb, New Relic, Dynatrace, Grafana Cloud, Phoenix, Langfuse, and SigNoz stack up on cost, investigation, and OpenTelemetry support.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a><a href="/blog/category/observability"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Observability</div></a></div></div></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="AI Norms &amp; Values, Part 1 of 3: How We Do Business at Honeycomb" href="/blog/ai-norms-values-part-1-how-we-do-business-at-honeycomb"><div class="relative max-w-full"><img alt="AI Norms &amp; Values, Part 1 of 3: How We Do Business at Honeycomb" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd021ecaa62a5011dea08612b6041e4f81224b861-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd021ecaa62a5011dea08612b6041e4f81224b861-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd021ecaa62a5011dea08612b6041e4f81224b861-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd021ecaa62a5011dea08612b6041e4f81224b861-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd021ecaa62a5011dea08612b6041e4f81224b861-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd021ecaa62a5011dea08612b6041e4f81224b861-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd021ecaa62a5011dea08612b6041e4f81224b861-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd021ecaa62a5011dea08612b6041e4f81224b861-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd021ecaa62a5011dea08612b6041e4f81224b861-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd021ecaa62a5011dea08612b6041e4f81224b861-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd021ecaa62a5011dea08612b6041e4f81224b861-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>August 20, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Charity Majors" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/charity">Charity Majors</a></p></div></div><a class="flex flex-col gap-2" href="/blog/ai-norms-values-part-1-how-we-do-business-at-honeycomb"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">AI Norms &amp; Values, Part 1 of 3: How We Do Business at Honeycomb</h3><p class="line-clamp-3 text-sm/normal">It&#x27;s been a year since Honeycomb issued its AI mandate. Charity reflects on what that produced, why AI isn&#x27;t special (it just amplifies what&#x27;s already there), and shares the first of three new documents on Honeycomb&#x27;s AI norms and values: how we do business.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a><a href="/blog/category/culture"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Culture</div></a></div></div></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="How I Support Humans in the AI Era" href="/blog/how-i-support-humans-in-the-ai-era"><div class="relative max-w-full"><img alt="How I Support Humans in the AI Era" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F66d0e7dbe0ea8f5501f64a175eccbab8a3d35a85-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F66d0e7dbe0ea8f5501f64a175eccbab8a3d35a85-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F66d0e7dbe0ea8f5501f64a175eccbab8a3d35a85-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F66d0e7dbe0ea8f5501f64a175eccbab8a3d35a85-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F66d0e7dbe0ea8f5501f64a175eccbab8a3d35a85-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F66d0e7dbe0ea8f5501f64a175eccbab8a3d35a85-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F66d0e7dbe0ea8f5501f64a175eccbab8a3d35a85-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F66d0e7dbe0ea8f5501f64a175eccbab8a3d35a85-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F66d0e7dbe0ea8f5501f64a175eccbab8a3d35a85-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F66d0e7dbe0ea8f5501f64a175eccbab8a3d35a85-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F66d0e7dbe0ea8f5501f64a175eccbab8a3d35a85-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>August 17, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Ileanell Perez" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F52b736a649fa6442c12250b94d09c59f72fd19d0-180x200.jpg%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F52b736a649fa6442c12250b94d09c59f72fd19d0-180x200.jpg%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F52b736a649fa6442c12250b94d09c59f72fd19d0-180x200.jpg%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/ileanell-perez">Ileanell Perez</a></p></div></div><a class="flex flex-col gap-2" href="/blog/how-i-support-humans-in-the-ai-era"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">How I Support Humans in the AI Era</h3><p class="line-clamp-3 text-sm/normal">A remote engineering manager on why she didn&#x27;t write a new AI policy for her team. Instead, she created space: for connection, for collaboration, and for discussion.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a><a href="/blog/category/teams-and-collaboration"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Teams &amp; Collaboration</div></a><a href="/blog/category/culture"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Culture</div></a></div></div></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="AI Model Drift: How to Keep Models Reliable" href="/blog/ai-model-drift"><div class="relative max-w-full"><img alt="AI Model Drift: How to Keep Models Reliable" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe40375dd42c11ee2ab56187a5b1de28bc85c6853-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe40375dd42c11ee2ab56187a5b1de28bc85c6853-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe40375dd42c11ee2ab56187a5b1de28bc85c6853-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe40375dd42c11ee2ab56187a5b1de28bc85c6853-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe40375dd42c11ee2ab56187a5b1de28bc85c6853-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe40375dd42c11ee2ab56187a5b1de28bc85c6853-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe40375dd42c11ee2ab56187a5b1de28bc85c6853-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe40375dd42c11ee2ab56187a5b1de28bc85c6853-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe40375dd42c11ee2ab56187a5b1de28bc85c6853-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe40375dd42c11ee2ab56187a5b1de28bc85c6853-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe40375dd42c11ee2ab56187a5b1de28bc85c6853-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>August 10, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Dan Juengst" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F9a49fe3f0c44d40c477e20e33ac76ea2608f2bdf-600x600.png%3Fw%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F9a49fe3f0c44d40c477e20e33ac76ea2608f2bdf-600x600.png%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F9a49fe3f0c44d40c477e20e33ac76ea2608f2bdf-600x600.png%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/dan-juengst">Dan Juengst</a></p></div></div><a class="flex flex-col gap-2" href="/blog/ai-model-drift"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">AI Model Drift: How to Keep Models Reliable</h3><p class="line-clamp-3 text-sm/normal">Learn what AI model drift is, why it happens, and how production teams detect changes in model quality, inputs, prompts, and behavior.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a></div></div></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="Introducing AI BubbleUp" href="/blog/introducing-ai-bubbleup"><div class="relative max-w-full"><img alt="Introducing AI BubbleUp" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F8afe3c1ed60b3bc3bee1aaabff66375cf142d095-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F8afe3c1ed60b3bc3bee1aaabff66375cf142d095-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F8afe3c1ed60b3bc3bee1aaabff66375cf142d095-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F8afe3c1ed60b3bc3bee1aaabff66375cf142d095-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F8afe3c1ed60b3bc3bee1aaabff66375cf142d095-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F8afe3c1ed60b3bc3bee1aaabff66375cf142d095-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F8afe3c1ed60b3bc3bee1aaabff66375cf142d095-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F8afe3c1ed60b3bc3bee1aaabff66375cf142d095-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F8afe3c1ed60b3bc3bee1aaabff66375cf142d095-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F8afe3c1ed60b3bc3bee1aaabff66375cf142d095-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F8afe3c1ed60b3bc3bee1aaabff66375cf142d095-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>August 5, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Kale Bogdanovs" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fa85aba826c3692ea82c1ae6e324da5262dcee117-225x300.jpg%3Frect%3D0%2C38%2C225%2C225%26w%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fa85aba826c3692ea82c1ae6e324da5262dcee117-225x300.jpg%3Frect%3D0%2C38%2C225%2C225%26w%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fa85aba826c3692ea82c1ae6e324da5262dcee117-225x300.jpg%3Frect%3D0%2C38%2C225%2C225%26w%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/kale-bogdanovs">Kale Bogdanovs</a></p></div></div><a class="flex flex-col gap-2" href="/blog/introducing-ai-bubbleup"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">Introducing AI BubbleUp</h3><p class="line-clamp-3 text-sm/normal">Every BubbleUp query now surfaces significant correlations based on relevance, not just statistical analysis. Available today to all Honeycomb customers who have enabled Honeycomb Intelligence.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a><a href="/blog/category/product-updates"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Product Updates</div></a></div></div></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="AMA Recap: More Answers From the Observability Engineering Authors" href="/blog/ama-recap-observability-engineering-authors-more-answers"><div class="relative max-w-full"><img alt="AMA: More Answers From the Observability Engineering Authors" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2756994c4483897f91816d9364132b01ba4cc2d0-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2756994c4483897f91816d9364132b01ba4cc2d0-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2756994c4483897f91816d9364132b01ba4cc2d0-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2756994c4483897f91816d9364132b01ba4cc2d0-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2756994c4483897f91816d9364132b01ba4cc2d0-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2756994c4483897f91816d9364132b01ba4cc2d0-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2756994c4483897f91816d9364132b01ba4cc2d0-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2756994c4483897f91816d9364132b01ba4cc2d0-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2756994c4483897f91816d9364132b01ba4cc2d0-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2756994c4483897f91816d9364132b01ba4cc2d0-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2756994c4483897f91816d9364132b01ba4cc2d0-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>August 4, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Rox Williams" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ffb0dadab9def700cd5661ade34b9557c7d1b18f8-180x200.jpg%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ffb0dadab9def700cd5661ade34b9557c7d1b18f8-180x200.jpg%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ffb0dadab9def700cd5661ade34b9557c7d1b18f8-180x200.jpg%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/rox-williams">Rox Williams</a></p></div></div><a class="flex flex-col gap-2" href="/blog/ama-recap-observability-engineering-authors-more-answers"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">AMA Recap: More Answers From the Observability Engineering Authors</h3><p class="line-clamp-3 text-sm/normal">We couldn&#x27;t get through every question during our live AMA with the authors of Observability Engineering, so Charity, Liz, George, and Austin stuck around to answer more on AI, telemetry, and what still needs a human in the loop.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a><a href="/blog/category/observability"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Observability</div></a></div></div></div><section class="col-span-full py-10"><div class="newsletter-cta-banner bg-hc-slate relative flex flex-col gap-6 overflow-hidden rounded-2xl p-5 text-white md:flex-row md:items-center md:gap-10 md:p-7 lg:p-10 xl:items-end xl:gap-32"><div class="flex flex-col gap-1 md:max-w-[340px] xl:w-[585px] xl:max-w-none xl:py-6"><h3 class="font-poppins tracking-heading text-xl leading-tight font-bold md:text-3xl md:tracking-tighter xl:text-4xl">Love our content?</h3><p class="font-poppins text-hc-sky-300 tracking-heading text-xl leading-tight font-bold md:text-3xl md:tracking-tighter xl:text-4xl">Get it delivered straight to your inbox.</p></div><div class="flex grow flex-col gap-2"><div id="blog-grid-newsletter-form" data-form-id="6ad8ab28-e5df-4a57-a1eb-b5fad2435f8d" class="hbspt-form [&amp;_.submitted-message]:!block [&amp;_.submitted-message_p]:my-4 [&amp;_.submitted-message_p]:text-center [&amp;_.submitted-message_p]:font-bold [&amp;_.submitted-message_p]:tracking-wide hubspot-form"></div><p class="text-hc-gray-200 text-xs leading-[150%]">By subscribing to our newsletter, you agree to Honeycomb’s<!-- --> <a target="_self" _key="4042940388e7" _type="link" class="text-hc-sky-300 underline hover:text-white" href="/terms">Terms of Service</a> and<!-- --> <a target="_self" _key="de1418f17f9f" _type="link" class="text-hc-sky-300 underline hover:text-white" href="/privacy">Privacy Notice</a>.</p></div></div></section><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="Spend More Time Talking to Humans" href="/blog/spend-more-time-talking-to-humans"><div class="relative max-w-full"><img alt="Spend More Time Talking to Humans" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fcffd9ef004452eb3744bfec81c30220785fc6ea8-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fcffd9ef004452eb3744bfec81c30220785fc6ea8-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fcffd9ef004452eb3744bfec81c30220785fc6ea8-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fcffd9ef004452eb3744bfec81c30220785fc6ea8-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fcffd9ef004452eb3744bfec81c30220785fc6ea8-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fcffd9ef004452eb3744bfec81c30220785fc6ea8-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fcffd9ef004452eb3744bfec81c30220785fc6ea8-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fcffd9ef004452eb3744bfec81c30220785fc6ea8-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fcffd9ef004452eb3744bfec81c30220785fc6ea8-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fcffd9ef004452eb3744bfec81c30220785fc6ea8-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fcffd9ef004452eb3744bfec81c30220785fc6ea8-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>August 3, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Douglas Soo" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F14f4a72c04d74eab745c26f731ece5189274e6b4-180x200.png%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F14f4a72c04d74eab745c26f731ece5189274e6b4-180x200.png%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F14f4a72c04d74eab745c26f731ece5189274e6b4-180x200.png%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/doug">Douglas Soo</a></p></div></div><a class="flex flex-col gap-2" href="/blog/spend-more-time-talking-to-humans"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">Spend More Time Talking to Humans</h3><p class="line-clamp-3 text-sm/normal">LLMs have reshaped the day-to-day work of software engineering, leaving senior engineers exhausted by context-switching and junior engineers unsure how to grow. The fix isn’t a better prompt — it’s spending more time talking to humans: reducing context churn, pairing across seniority levels, and communicating more across teams.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a><a href="/blog/category/teams-and-collaboration"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Teams &amp; Collaboration</div></a></div></div></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="Honeycomb Named a Visionary in the 2026 Gartner® Magic Quadrant™ for Observability Platforms" href="/blog/honeycomb-named-visionary-2026-gartner-magic-quadrant-observability-platforms"><div class="relative max-w-full"><img alt="Honeycomb Named a Visionary in the 2026 Gartner® Magic Quadrant™ for Observability Platforms" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F0dc73b52e47cba09bbbe9d43eee242edfaa03fe3-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F0dc73b52e47cba09bbbe9d43eee242edfaa03fe3-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F0dc73b52e47cba09bbbe9d43eee242edfaa03fe3-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F0dc73b52e47cba09bbbe9d43eee242edfaa03fe3-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F0dc73b52e47cba09bbbe9d43eee242edfaa03fe3-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F0dc73b52e47cba09bbbe9d43eee242edfaa03fe3-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F0dc73b52e47cba09bbbe9d43eee242edfaa03fe3-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F0dc73b52e47cba09bbbe9d43eee242edfaa03fe3-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F0dc73b52e47cba09bbbe9d43eee242edfaa03fe3-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F0dc73b52e47cba09bbbe9d43eee242edfaa03fe3-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F0dc73b52e47cba09bbbe9d43eee242edfaa03fe3-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>July 29, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Shabih Syed" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F45de15053db3321b1c2e8fbb963688ab67a310b7-271x300.jpg%3Frect%3D0%2C15%2C271%2C271%26w%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F45de15053db3321b1c2e8fbb963688ab67a310b7-271x300.jpg%3Frect%3D0%2C15%2C271%2C271%26w%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F45de15053db3321b1c2e8fbb963688ab67a310b7-271x300.jpg%3Frect%3D0%2C15%2C271%2C271%26w%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/shabih-syed">Shabih Syed</a></p></div></div><a class="flex flex-col gap-2" href="/blog/honeycomb-named-visionary-2026-gartner-magic-quadrant-observability-platforms"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">Honeycomb Named a Visionary in the 2026 Gartner® Magic Quadrant™ for Observability Platforms</h3><p class="line-clamp-3 text-sm/normal">For the third consecutive year, Honeycomb has been named a Visionary in the Gartner® Magic Quadrant™ for Observability Platforms. The recognition reflects Honeycomb&#x27;s vision for fast, flexible, high-cardinality querying, agent-era observability with Agent Timeline and Canvas, and predictable event-based pricing at trillions of events.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/news-and-announcements"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">News &amp; Announcements</div></a><a href="/blog/category/observability"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Observability</div></a><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a></div></div></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="Embracing the Code Review Bottleneck" href="/blog/embracing-code-review-bottleneck"><div class="relative max-w-full"><img alt="Embracing the Code Review Bottleneck" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ff8e9e31a0ddf45434c3780b50ee6f69887015c98-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ff8e9e31a0ddf45434c3780b50ee6f69887015c98-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ff8e9e31a0ddf45434c3780b50ee6f69887015c98-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ff8e9e31a0ddf45434c3780b50ee6f69887015c98-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ff8e9e31a0ddf45434c3780b50ee6f69887015c98-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ff8e9e31a0ddf45434c3780b50ee6f69887015c98-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ff8e9e31a0ddf45434c3780b50ee6f69887015c98-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ff8e9e31a0ddf45434c3780b50ee6f69887015c98-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ff8e9e31a0ddf45434c3780b50ee6f69887015c98-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ff8e9e31a0ddf45434c3780b50ee6f69887015c98-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ff8e9e31a0ddf45434c3780b50ee6f69887015c98-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>July 22, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Fred Hebert" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F7b06f417ac780bd2e4f02707bab2ec76cfd56665-180x200.png%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F7b06f417ac780bd2e4f02707bab2ec76cfd56665-180x200.png%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F7b06f417ac780bd2e4f02707bab2ec76cfd56665-180x200.png%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/fred-hebert">Fred Hebert</a></p></div></div><a class="flex flex-col gap-2" href="/blog/embracing-code-review-bottleneck"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">Embracing the Code Review Bottleneck</h3><p class="line-clamp-3 text-sm/normal">Faced with an endless stream of AI-generated code reviews, our team made the counterintuitive choice to lean into the bottleneck rather than reduce it. Surprisingly, velocity held up, knowledge sharing improved, and we developed a collective system ownership that stuck.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/software-engineering"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Software Engineering</div></a><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a></div></div></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="What Comes After Observability?" href="/blog/what-comes-after-observability"><div class="relative max-w-full"><img alt="What Comes After Observability?" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe074790a74ac795de3c41ddaceb84ff80f8393e3-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe074790a74ac795de3c41ddaceb84ff80f8393e3-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe074790a74ac795de3c41ddaceb84ff80f8393e3-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe074790a74ac795de3c41ddaceb84ff80f8393e3-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe074790a74ac795de3c41ddaceb84ff80f8393e3-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe074790a74ac795de3c41ddaceb84ff80f8393e3-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe074790a74ac795de3c41ddaceb84ff80f8393e3-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe074790a74ac795de3c41ddaceb84ff80f8393e3-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe074790a74ac795de3c41ddaceb84ff80f8393e3-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe074790a74ac795de3c41ddaceb84ff80f8393e3-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fe074790a74ac795de3c41ddaceb84ff80f8393e3-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>July 20, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Austin Parker" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2a1050e83bac34eea79bd9f2d5bf7c3fc106550f-600x600.jpg%3Fw%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2a1050e83bac34eea79bd9f2d5bf7c3fc106550f-600x600.jpg%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F2a1050e83bac34eea79bd9f2d5bf7c3fc106550f-600x600.jpg%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/austin">Austin Parker</a></p></div></div><a class="flex flex-col gap-2" href="/blog/what-comes-after-observability"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">What Comes After Observability?</h3><p class="line-clamp-3 text-sm/normal">A year ago, I predicted ways in which AI was about to fundamentally change observability as we knew it. Here&#x27;s what we&#x27;ve seen happen since—both at Honeycomb and with our customers—and what we&#x27;re building for the future.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/observability"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Observability</div></a><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a></div></div></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="30 to 70 PRs a Day: How We Managed to Not Wreck Our Systems" href="/blog/30-70-prs-day-how-we-managed-not-wreck-systems"><div class="relative max-w-full"><img alt="30 to 70 PRs a Day: How We Managed to Not Wreck Our Systems" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F5e261bbd627f0eede01281d7766cc21a4245155b-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F5e261bbd627f0eede01281d7766cc21a4245155b-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F5e261bbd627f0eede01281d7766cc21a4245155b-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F5e261bbd627f0eede01281d7766cc21a4245155b-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F5e261bbd627f0eede01281d7766cc21a4245155b-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F5e261bbd627f0eede01281d7766cc21a4245155b-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F5e261bbd627f0eede01281d7766cc21a4245155b-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F5e261bbd627f0eede01281d7766cc21a4245155b-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F5e261bbd627f0eede01281d7766cc21a4245155b-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F5e261bbd627f0eede01281d7766cc21a4245155b-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F5e261bbd627f0eede01281d7766cc21a4245155b-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>July 16, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Liz Fong-Jones" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ff6f77e2c3753d50fc961f3d1b48b28b3ba91008b-3146x3146.jpg%3Fw%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ff6f77e2c3753d50fc961f3d1b48b28b3ba91008b-3146x3146.jpg%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ff6f77e2c3753d50fc961f3d1b48b28b3ba91008b-3146x3146.jpg%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/lizf">Liz Fong-Jones</a></p></div></div><a class="flex flex-col gap-2" href="/blog/30-70-prs-day-how-we-managed-not-wreck-systems"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">30 to 70 PRs a Day: How We Managed to Not Wreck Our Systems</h3><p class="line-clamp-3 text-sm/normal">The Honeycomb engineering team set out to double our productivity in a year. This is how we did it, what we did to keep things stable, what it cost us, and what we’re still figuring out.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a><a href="/blog/category/software-engineering"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Software Engineering</div></a></div></div></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="AI Amplifies Your Existing Practices: Lessons from Our Shift to an AI-First Strategy" href="/blog/ai-amplifies-existing-practices-lessons-ai-first-strategy"><div class="relative max-w-full"><img alt="AI Amplifies Your Existing Practices: Lessons from Our Shift to an AI-First Strategy" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd79aa05cd396ba3f92b7f9b4df294c138b62f347-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd79aa05cd396ba3f92b7f9b4df294c138b62f347-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd79aa05cd396ba3f92b7f9b4df294c138b62f347-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd79aa05cd396ba3f92b7f9b4df294c138b62f347-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd79aa05cd396ba3f92b7f9b4df294c138b62f347-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd79aa05cd396ba3f92b7f9b4df294c138b62f347-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd79aa05cd396ba3f92b7f9b4df294c138b62f347-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd79aa05cd396ba3f92b7f9b4df294c138b62f347-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd79aa05cd396ba3f92b7f9b4df294c138b62f347-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd79aa05cd396ba3f92b7f9b4df294c138b62f347-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Fd79aa05cd396ba3f92b7f9b4df294c138b62f347-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>July 16, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Liz Fong-Jones" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ff6f77e2c3753d50fc961f3d1b48b28b3ba91008b-3146x3146.jpg%3Fw%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ff6f77e2c3753d50fc961f3d1b48b28b3ba91008b-3146x3146.jpg%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2Ff6f77e2c3753d50fc961f3d1b48b28b3ba91008b-3146x3146.jpg%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/lizf">Liz Fong-Jones</a></p></div></div><a class="flex flex-col gap-2" href="/blog/ai-amplifies-existing-practices-lessons-ai-first-strategy"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">AI Amplifies Your Existing Practices: Lessons from Our Shift to an AI-First Strategy</h3><p class="line-clamp-3 text-sm/normal">As the Honeycomb engineering team worked to double our productivity, we learned a lot. The most important takeaway? Nothing anyone tells you about AI will land if your starting substrate is unhealthy.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a><a href="/blog/category/software-engineering"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Software Engineering</div></a></div></div></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="Transforming How We Run Kafka at Honeycomb" href="/blog/transforming-how-we-run-kafka-honeycomb"><div class="relative max-w-full"><img alt="How we run Kafka at Honeycomb" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F9a3a884b5eb123975dbb6815fd396be69cdee058-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F9a3a884b5eb123975dbb6815fd396be69cdee058-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F9a3a884b5eb123975dbb6815fd396be69cdee058-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F9a3a884b5eb123975dbb6815fd396be69cdee058-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F9a3a884b5eb123975dbb6815fd396be69cdee058-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F9a3a884b5eb123975dbb6815fd396be69cdee058-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F9a3a884b5eb123975dbb6815fd396be69cdee058-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F9a3a884b5eb123975dbb6815fd396be69cdee058-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F9a3a884b5eb123975dbb6815fd396be69cdee058-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F9a3a884b5eb123975dbb6815fd396be69cdee058-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F9a3a884b5eb123975dbb6815fd396be69cdee058-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>July 15, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Josh Parsons" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F1fc7eb47fcf3289e675d70eec7f1c82f15cd629c-180x200.jpg%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F1fc7eb47fcf3289e675d70eec7f1c82f15cd629c-180x200.jpg%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F1fc7eb47fcf3289e675d70eec7f1c82f15cd629c-180x200.jpg%3Frect%3D0%2C10%2C180%2C180%26w%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/josh-parsons">Josh Parsons</a></p></div></div><a class="flex flex-col gap-2" href="/blog/transforming-how-we-run-kafka-honeycomb"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">Transforming How We Run Kafka at Honeycomb</h3><p class="line-clamp-3 text-sm/normal">We just completed a large-scale, multi-month Kafka migration project. We couldn&#x27;t have done it without learning from past mistakes, prioritizing rollback safety, and building shared knowledge across the team through repeated migration practice.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/migrations"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Migrations</div></a><a href="/blog/category/best-practices"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Best Practices</div></a></div></div></div><div class="relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-white"><a title="Shipping Is Your Company&#x27;s Heartbeat: A Letter from a CTO" href="/blog/shipping-is-your-companys-heartbeat-letter-from-cto"><div class="relative max-w-full"><img alt="Shipping Is Your Company&#x27;s Heartbeat: A Letter from a CTO" fetchPriority="low" loading="lazy" width="3840" height="2160" decoding="async" data-nimg="1" class="w-full max-w-none rounded-t-[20px] object-cover h-[178.8px]" style="color:transparent" sizes="(max-width: 768px) 100vw, (max-width: 1024px) 50vw, 33vw" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F3164e7a63d6badbcd48f49cd26a3fa1e5930c7df-3840x2160.png&amp;w=256&amp;q=75 256w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F3164e7a63d6badbcd48f49cd26a3fa1e5930c7df-3840x2160.png&amp;w=384&amp;q=75 384w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F3164e7a63d6badbcd48f49cd26a3fa1e5930c7df-3840x2160.png&amp;w=640&amp;q=75 640w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F3164e7a63d6badbcd48f49cd26a3fa1e5930c7df-3840x2160.png&amp;w=750&amp;q=75 750w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F3164e7a63d6badbcd48f49cd26a3fa1e5930c7df-3840x2160.png&amp;w=828&amp;q=75 828w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F3164e7a63d6badbcd48f49cd26a3fa1e5930c7df-3840x2160.png&amp;w=1080&amp;q=75 1080w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F3164e7a63d6badbcd48f49cd26a3fa1e5930c7df-3840x2160.png&amp;w=1200&amp;q=75 1200w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F3164e7a63d6badbcd48f49cd26a3fa1e5930c7df-3840x2160.png&amp;w=1920&amp;q=75 1920w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F3164e7a63d6badbcd48f49cd26a3fa1e5930c7df-3840x2160.png&amp;w=2048&amp;q=75 2048w, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F3164e7a63d6badbcd48f49cd26a3fa1e5930c7df-3840x2160.png&amp;w=3840&amp;q=75 3840w" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F3164e7a63d6badbcd48f49cd26a3fa1e5930c7df-3840x2160.png&amp;w=3840&amp;q=75"/></div></a><div class="flex flex-col p-5 h-[327px] justify-between"><div class="flex flex-col gap-2"><div class="flex flex-col items-baseline gap-2"><span class="text-hc-slate/70 font-roboto text-xs/relaxed font-medium"><span>July 14, 2026</span></span><span class="font-extralight opacity-30 hidden"> | </span><div class="flex items-center gap-[6px]"><img alt="Charity Majors" loading="lazy" width="80" height="80" decoding="async" data-nimg="1" class="bg-hc-gray-50 size-6 rounded-full" style="color:transparent" srcSet="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=96&amp;q=75 1x, /_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75 2x" src="/_next/image?url=https%3A%2F%2Fcdn.sanity.io%2Fimages%2F927dxq0h%2Fproduction%2F6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png%3Fw%3D80%26h%3D80&amp;w=256&amp;q=75"/><p class="text-hc-slate text-sm"><a class="text-hc-cobalt underline hover:no-underline" href="/author/charity">Charity Majors</a></p></div></div><a class="flex flex-col gap-2" href="/blog/shipping-is-your-companys-heartbeat-letter-from-cto"><h3 class="font-roboto line-clamp-3 text-base/snug font-medium">Shipping Is Your Company&#x27;s Heartbeat: A Letter from a CTO</h3><p class="line-clamp-3 text-sm/normal">In an open letter to engineering leaders everywhere, Fin CTO Darragh Curran explains that AI isn&#x27;t a magic wand but rather an amplifier—of the good and the bad—of your engineering practices. And engineering rigor is more important than ever.</p></a></div><div class="flex flex-wrap gap-3"><a href="/blog/category/ai-llms"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">AI &amp; LLMs</div></a><a href="/blog/category/observability"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Observability</div></a><a href="/blog/category/software-engineering"><div class="font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate">Software Engineering</div></a></div></div></div></div><nav role="navigation" aria-label="pagination" class="mx-auto flex w-full justify-center py-16"><ul class="flex flex-row items-center gap-1"><li class=""><a target="_self" _type="link" aria-current="page" class="font-roboto focus-visible:ring-ring inline-block cursor-pointer text-center [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 border-none rounded-lg border py-2 text-sm leading-normal tracking-normal normal-case transition-colors duration-100 ease-linear hover:text-hc-cobalt px-2 font-normal text-hc-cobalt underline" href="?page=1"><span class="flex items-center justify-center gap-2.5">1</span></a></li><li class=""><a target="_self" _type="link" class="font-roboto focus-visible:ring-ring inline-block cursor-pointer text-center [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 text-hc-slate border-none rounded-lg border py-2 text-sm leading-normal tracking-normal normal-case transition-colors duration-100 ease-linear hover:text-hc-cobalt px-2 font-normal" href="?page=2"><span class="flex items-center justify-center gap-2.5">2</span></a></li><li class=""><a target="_self" _type="link" class="font-roboto focus-visible:ring-ring inline-block cursor-pointer text-center [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 text-hc-slate border-none rounded-lg border py-2 text-sm leading-normal tracking-normal normal-case transition-colors duration-100 ease-linear hover:text-hc-cobalt px-2 font-normal" href="?page=3"><span class="flex items-center justify-center gap-2.5">3</span></a></li><li class=""><a target="_self" _type="link" class="font-roboto focus-visible:ring-ring inline-block cursor-pointer text-center [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 text-hc-slate border-none rounded-lg border py-2 text-sm leading-normal tracking-normal normal-case transition-colors duration-100 ease-linear hover:text-hc-cobalt px-2 font-normal" href="?page=4"><span class="flex items-center justify-center gap-2.5">4</span></a></li><li class=""><a target="_self" _type="link" class="font-roboto focus-visible:ring-ring inline-block cursor-pointer text-center [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 text-hc-slate border-none rounded-lg border py-2 text-sm leading-normal tracking-normal normal-case transition-colors duration-100 ease-linear hover:text-hc-cobalt px-2 font-normal" href="?page=5"><span class="flex items-center justify-center gap-2.5">5</span></a></li><li class=""><a target="_self" _type="link" class="font-roboto focus-visible:ring-ring inline-block cursor-pointer text-center [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 text-hc-slate border-none rounded-lg border py-2 text-sm leading-normal tracking-normal normal-case transition-colors duration-100 ease-linear hover:text-hc-cobalt px-2 font-normal" href="?page=6"><span class="flex items-center justify-center gap-2.5">6</span></a></li><li class=""><a target="_self" _type="link" class="font-roboto focus-visible:ring-ring inline-block cursor-pointer text-center [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 text-hc-slate border-none rounded-lg border py-2 text-sm leading-normal tracking-normal normal-case transition-colors duration-100 ease-linear hover:text-hc-cobalt px-2 font-normal" href="?page=7"><span class="flex items-center justify-center gap-2.5">7</span></a></li><li class=""><a target="_self" _type="link" class="font-roboto focus-visible:ring-ring inline-block cursor-pointer text-center [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 text-hc-slate border-none rounded-lg border py-2 text-sm leading-normal tracking-normal normal-case transition-colors duration-100 ease-linear hover:text-hc-cobalt px-2 font-normal" href="?page=8"><span class="flex items-center justify-center gap-2.5">8</span></a></li><li class=""><a target="_self" _type="link" class="font-roboto focus-visible:ring-ring inline-block cursor-pointer text-center [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 text-hc-slate border-none rounded-lg border py-2 text-sm leading-normal tracking-normal normal-case transition-colors duration-100 ease-linear hover:text-hc-cobalt px-2 font-normal" href="?page=9"><span class="flex items-center justify-center gap-2.5">9</span></a></li><li class=""><span aria-hidden="true" class="flex h-9 w-9 items-center justify-center"><svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="lucide lucide-ellipsis h-4 w-4"><circle cx="12" cy="12" r="1"></circle><circle cx="19" cy="12" r="1"></circle><circle cx="5" cy="12" r="1"></circle></svg><span class="sr-only">More pages</span></span></li><li class=""><a target="_self" _type="link" class="font-roboto focus-visible:ring-ring inline-block cursor-pointer text-center [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 text-hc-slate border-none rounded-lg border py-2 text-sm leading-normal tracking-normal normal-case transition-colors duration-100 ease-linear hover:text-hc-cobalt px-2 font-normal" href="?page=32"><span class="flex items-center justify-center gap-2.5">32</span></a></li><li class=""><a target="_self" _type="link" aria-label="Go to next page" class="font-roboto focus-visible:ring-ring inline-block cursor-pointer rounded-sm text-center font-bold tracking-[1.4px] uppercase transition-[color,background-color] [transition-duration:300ms,500ms] focus-visible:ring-1 focus-visible:outline-none disabled:pointer-events-none disabled:opacity-50 border-hc-cobalt bg-hc-cobalt hover:bg-hc-pacific hover:border-hc-pacific border-2 border-solid text-white text-[14px] leading-[14px] p-[6px]" href="?page=2"><span class="flex items-center justify-center gap-2.5"><svg xmlns="http://www.w3.org/2000/svg" width="24" height="24" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round" class="lucide lucide-chevron-right size-5"><path d="m9 18 6-6-6-6"></path></svg></span></a></li></ul></nav></div></div></main><!--$--><!--/$--><footer class="original-footer font-roboto text-hc-slate mx-auto max-w-[1152px] px-4"><div class="flex w-full flex-col items-center gap-[40px] py-[80px] lg:flex-row lg:items-stretch lg:gap-[132px]"><div class="order-2 flex-1 lg:order-1"><div class="hidden flex-1 flex-row justify-between pb-[74px] lg:flex"><div class="flex flex-col gap-3"><span class="text-base leading-[150%] font-semibold">Observability Platform</span><ul><li class="pb-1"><a target="_self" _key="3709d74ab43c" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/pricing">Pricing</a></li><li class="pb-1"><a target="_self" _key="c73c8241288b" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/platform">Platform Overview</a></li><li class="pb-1"><a target="_self" _key="7270c5c87c85" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/platform/frontend-observability">Frontend Observability</a></li><li class="pb-1"><a target="_self" _key="db25504b1c78" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/platform/log-analytics">Log Analytics</a></li><li class="pb-1"><a target="_self" _key="ea87e5e00146" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/platform/distributed-tracing">Distributed Tracing</a></li><li class="pb-1"><a target="_self" _key="045ae34eb65d" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/platform/metrics">Metrics</a></li><li class="pb-1"><a target="_self" _key="3d1692a51e34" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/platform/telemetry-pipeline">Telemetry Pipeline</a></li><li class="pb-1"><a target="_self" _key="4196f597a92d" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/platform/private-cloud">Private Cloud</a></li><li class="pb-1"><a target="_self" _key="b22d2cde4a3d" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/platform/slos">SLOs</a></li><li class="pb-1"><a target="_self" _key="0f5a9a5f7aa7" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/platform/service-map">Service Map</a></li><li class="pb-1"><a target="_self" _key="6db0fbacbbc4" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/platform/bubbleup">BubbleUp</a></li><li class="pb-1"><a target="_self" _key="d672da05edda" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/platform/opentelemetry">OpenTelemetry</a></li><li class="pb-1"><a target="_self" _key="80b1b84cfd32" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/platform/integrations">App Integrations</a></li></ul></div><div class="flex flex-col gap-3"><span class="text-base leading-[150%] font-semibold">Solutions</span><ul><li class="pb-1"><a target="_self" _key="8f77d4ed6602" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/why-honeycomb">Why Honeycomb</a></li><li class="pb-1"><a target="_self" _key="7fb03607561c" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/why-honeycomb/enterprise">Enterprise</a></li><li class="pb-1"><a target="_self" _key="d0d6163b27ff" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/technologies/ai-agents">AI Agents</a></li><li class="pb-1"><a target="_self" _key="2b90f65f46e6" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/technologies/aws">Amazon Web Services</a></li><li class="pb-1"><a target="_self" _key="c3dff0996d2b" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/technologies/microsoft-azure">Microsoft Azure</a></li><li class="pb-1"><a target="_self" _key="d0caa1e4eb66" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/technologies/kubernetes">Kubernetes</a></li><li class="pb-1"><a target="_self" _key="9ceaefb31039" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/technologies/google-cloud">Google Cloud</a></li></ul></div><div class="flex flex-col gap-3"><span class="text-base leading-[150%] font-semibold">Company</span><ul><li class="pb-1"><a target="_self" _key="26df551d2e36" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/about">About Us</a></li><li class="pb-1"><a target="_self" _key="cd5a23b41429" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/about/team">Team</a></li><li class="pb-1"><a target="_self" _key="9e8d0ae5c80c" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/careers">Careers</a></li><li class="pb-1"><a target="_self" _key="21e1fb267d5e" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/news">News</a></li><li class="pb-1"><a target="_self" _key="bb5ab8caffa9" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/events">Events</a></li><li class="pb-1"><a target="_self" _key="f8a10f88008f" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/why-honeycomb/customers">Customers</a></li><li class="pb-1"><a target="_self" _key="bf0deb38bf75" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/partners">Partners</a></li><li class="pb-1"><a target="_blank" rel="noopener noreferrer" _key="15f6dabb07e6" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="https://docs.honeycomb.io/security-compliance">Security</a></li><li class="pb-1"><a target="_self" _key="85057eb711e5" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/support">Support</a></li><li class="pb-1"><a target="_blank" rel="noopener noreferrer" _key="e94d32b2d070" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="https://status.honeycomb.io/">Status</a></li><li class="pb-1"><a target="_self" _key="0ea03725759b" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="https://changelog.honeycomb.io/">Changelog</a></li></ul></div><div class="flex flex-col gap-3"><span class="text-base leading-[150%] font-semibold">Resources</span><ul><li class="pb-1"><a target="_self" _key="671f18da9b3f" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/blog">Blog</a></li><li class="pb-1"><a target="_self" _key="92ccb060bb8f" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="https://docs.honeycomb.io">Documentation</a></li><li class="pb-1"><a target="_self" _key="db87d691804a" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/resources/getting-started">Getting Started</a></li><li class="pb-1"><a target="_self" _key="ba793c2d2aec" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/resources/case-studies">Case Studies</a></li><li class="pb-1"><a target="_self" _key="b6324b7fa3ad" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/why-honeycomb/comparisons">Comparisons</a></li><li class="pb-1"><a target="_self" _key="8dacd4366e92" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/resources/webinars">Webinars</a></li><li class="pb-1"><a target="_self" _key="2e34173dd022" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/blog/what-is-observability-key-components-best-practices">What Is Observability?</a></li><li class="pb-1"><a target="_self" _key="52309d8a3d42" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/resources/getting-started/what-is-ai-observability">What Is AI Observability?</a></li><li class="pb-1"><a target="_self" _key="a1a79caf1ea6" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/resources/getting-started/what-is-llm-observability">What Is LLM Observability?</a></li><li class="pb-1"><a target="_self" _key="9cf8c6d40ac4" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/resources/getting-started/application-performance-monitoring-vs-observability">APM vs Observability</a></li><li class="pb-1"><a target="_self" _key="b20174d4157b" _type="link" class="text-sm leading-[20px] tracking-[0.02em]" href="/resources/getting-started/getting-started-with-opentelemetry">OpenTelemetry Guide</a></li></ul></div></div><div class="flex flex-col items-baseline gap-2 text-xs leading-[150%] tracking-[0] lg:flex-row lg:gap-3"><span>© <!-- -->2026<!-- --> <!-- -->Hound Technology, Inc.</span><ul class="flex flex-row gap-3"><li class="pb-1"><a target="_self" _key="4042940388e7" _type="link" class="text-hc-cobalt text-xs leading-[20px] tracking-[0.02em] underline" href="/terms">Terms of Service</a></li><li class="pb-1"><a target="_self" _key="df3d0de1abf9" _type="link" class="text-hc-cobalt text-xs leading-[20px] tracking-[0.02em] underline" href="/acceptable-use-policy">Acceptable Use Policy</a></li><li class="pb-1"><a target="_self" _key="de1418f17f9f" _type="link" class="text-hc-cobalt text-xs leading-[20px] tracking-[0.02em] underline" href="/privacy">Privacy Notice</a></li><li class="pb-1"><a href="#" class="text-hc-cobalt cky-banner-element text-xs leading-[20px] tracking-[0.02em] underline">Your Privacy Choices</a></li></ul></div></div><div class="order-1 flex w-full flex-grow flex-col items-center justify-between self-stretch lg:order-2 lg:max-w-[295px]"><div id="footer-newsletter" class="flex-1 lg:px-4"><p class="font-roboto pb-[15px] text-center text-lg leading-[22px] font-bold tracking-[0.02em]">Sign up for updates from Honeycomb</p><div id="footer-form" data-form-id="6ad8ab28-e5df-4a57-a1eb-b5fad2435f8d" class="hbspt-form [&amp;_.submitted-message]:!block [&amp;_.submitted-message_p]:my-4 [&amp;_.submitted-message_p]:text-center [&amp;_.submitted-message_p]:font-bold [&amp;_.submitted-message_p]:tracking-wide"></div></div><div class="mt-auto pt-4"><div class="mt-4 flex gap-4"><a href="https://bsky.app/profile/honeycomb.io" target="_blank" rel="noopener noreferrer" aria-label="Bluesky" class="transition-opacity hover:opacity-80"><div class="border-hc-slate flex size-9 items-center justify-center rounded-full border-[2px]"><img alt="Bluesky" loading="lazy" width="600" height="530" decoding="async" data-nimg="1" class="h-3.5 w-3.5 object-contain" style="color:transparent" src="https://cdn.sanity.io/images/927dxq0h/production/b791a32106224d6a8c17908d9e10a1098ecd033e-600x530.svg"/></div></a><a href="https://www.linkedin.com/company/honeycomb.io" target="_blank" rel="noopener noreferrer" aria-label="linkedin" class="transition-opacity hover:opacity-80"><div class="border-hc-slate flex size-9 items-center justify-center rounded-full border-[2px]"><img alt="Linkedin" loading="lazy" width="36" height="36" decoding="async" data-nimg="1" class="h-3.5 w-3.5 object-contain" style="color:transparent" src="https://cdn.sanity.io/images/927dxq0h/production/2129b6ff6ad7d0a679bcde4a6d1f3498d2c5c2c3-36x36.svg"/></div></a><a href="https://www.youtube.com/channel/UCty8KGQ3oAP0MQQmLIv7k0Q" target="_blank" rel="noopener noreferrer" aria-label="youtube" class="transition-opacity hover:opacity-80"><div class="border-hc-slate flex size-9 items-center justify-center rounded-full border-[2px]"><img alt="YouTube" loading="lazy" width="256" height="256" decoding="async" data-nimg="1" class="h-3.5 w-3.5 object-contain" style="color:transparent" src="https://cdn.sanity.io/images/927dxq0h/production/6949a9f5fcdca86c2505079300c317729031c030-256x256.svg"/></div></a><a href="https://www.honeycomb.io/rss/blog.xml" target="_blank" rel="noopener noreferrer" aria-label="RSS" class="transition-opacity hover:opacity-80"><div class="border-hc-slate flex size-9 items-center justify-center rounded-full border-[2px]"><img alt="RSS" loading="lazy" width="800" height="800" decoding="async" data-nimg="1" class="h-3.5 w-3.5 object-contain" style="color:transparent" src="https://cdn.sanity.io/images/927dxq0h/production/c0e681e6a520b9ddc9b0beb072859fd9b6e7e20e-800x800.svg"/></div></a></div></div></div></div></footer><footer class="font-roboto text-hc-slate small-footer container hidden flex-col items-center justify-between gap-10 py-10 lg:flex-row lg:gap-5 xl:gap-0"><ul class="flex flex-1 flex-col justify-between gap-5 text-center lg:flex-2/3 lg:flex-row lg:gap-0 lg:text-left"><li><a class="text-hc-cobalt leading-[20px] tracking-[0.02em] underline" href="https://honeycomb.io">Honeycomb.io</a></li><li><a target="_self" _key="4042940388e7" _type="link" class="text-hc-cobalt leading-[20px] tracking-[0.02em] text-nowrap underline" href="/terms">Terms of Service</a></li><li><a target="_self" _key="df3d0de1abf9" _type="link" class="text-hc-cobalt leading-[20px] tracking-[0.02em] text-nowrap underline" href="/acceptable-use-policy">Acceptable Use Policy</a></li><li><a target="_self" _key="de1418f17f9f" _type="link" class="text-hc-cobalt leading-[20px] tracking-[0.02em] text-nowrap underline" href="/privacy">Privacy Notice</a></li><li><a class="cky-banner-element text-hc-cobalt leading-[20px] tracking-[0.02em] text-nowrap underline" href="#">Your Privacy Choices</a></li></ul><span class="text-end leading-[20px] tracking-[0.02em] lg:max-w-fit xl:max-w-none xl:flex-1/3">© <!-- -->2026<!-- --> <!-- -->Hound Technology, Inc.</span></footer><script src="/_next/static/chunks/05gogik_6g8vk.js" id="_R_" async=""></script><script>(self.__next_f=self.__next_f||[]).push([0])</script><script>self.__next_f.push([1,"1:\"$Sreact.fragment\"\n2:I[516503,[\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"/_next/static/chunks/019vi3l~x0zoc.js\"],\"\"]\n3:I[483136,[\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"/_next/static/chunks/019vi3l~x0zoc.js\"],\"default\"]\n4:I[758298,[\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"/_next/static/chunks/019vi3l~x0zoc.js\",\"/_next/static/chunks/12~zlyzq33k~1.js\"],\"default\"]\n5:I[229390,[\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"/_next/static/chunks/019vi3l~x0zoc.js\"],\"default\"]\nf:I[563491,[\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"/_next/static/chunks/019vi3l~x0zoc.js\",\"/_next/static/chunks/025lo2k4b20~m.js\"],\"default\"]\n12:I[694113,[\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"/_next/static/chunks/019vi3l~x0zoc.js\"],\"GoogleAnalytics\"]\n13:I[196641,[\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"/_next/static/chunks/019vi3l~x0zoc.js\"],\"GoogleTagManager\"]\n16:I[351397,[\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"/_next/static/chunks/019vi3l~x0zoc.js\"],\"OutletBoundary\"]\n17:\"$Sreact.suspense\"\n1a:I[351397,[\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"/_next/static/chunks/019vi3l~x0zoc.js\"],\"ViewportBoundary\"]\n1c:I[351397,[\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"/_next/static/chunks/019vi3l~x0zoc.js\"],\"MetadataBoundary\"]\n:HL[\"/_next/static/chunks/0-a~7ljgpwyij.css\",\"style\"]\n:HL[\"/_next/static/chunks/0k9no2apwmz~n.css\",\"style\"]\n:HL[\"/_next/static/chunks/0nuksys438q2t.css\",\"style\"]\n:HL[\"/_next/static/media/345b029bff63acdd-s.p.14zxo1jbez.lc.woff2\",\"font\",{\"crossOrigin\":\"\",\"type\":\"font/woff2\"}]\n:HL[\"/_next/static/media/8e6fa89aa22d24ec-s.p.0uvzar8hswo3p.woff2\",\"font\",{\"crossOrigin\":\"\",\"type\":\"font/woff2\"}]\n:HL[\"/_next/static/media/ce62453a442c7f35-s.p.0333ktddfbsxy.woff2\",\"font\",{\"crossOrigin\":\"\",\"type\":\"font/woff2\"}]\n:HL[\"/_next/static/media/e2334d715941921e-s.p.12skym0rqknxy.woff2\",\"font\",{\"crossOrigin\":\"\",\"type\":\"font/woff2\"}]\n"])</script><script>self.__next_f.push([1,"0:{\"P\":null,\"c\":[\"\",\"blog\"],\"q\":\"\",\"i\":false,\"f\":[[[\"\",{\"children\":[\"(frontend)\",{\"children\":[\"blog\",{\"children\":[\"__PAGE__\",{}]}]}]},\"$undefined\",\"$undefined\",16],[[\"$\",\"$1\",\"c\",{\"children\":[[[\"$\",\"link\",\"0\",{\"rel\":\"stylesheet\",\"href\":\"/_next/static/chunks/0-a~7ljgpwyij.css\",\"precedence\":\"next\",\"crossOrigin\":\"$undefined\",\"nonce\":\"$undefined\"}],[\"$\",\"link\",\"1\",{\"rel\":\"stylesheet\",\"href\":\"/_next/static/chunks/0k9no2apwmz~n.css\",\"precedence\":\"next\",\"crossOrigin\":\"$undefined\",\"nonce\":\"$undefined\"}],[\"$\",\"script\",\"script-0\",{\"src\":\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"async\":true,\"nonce\":\"$undefined\"}],[\"$\",\"script\",\"script-1\",{\"src\":\"/_next/static/chunks/019vi3l~x0zoc.js\",\"async\":true,\"nonce\":\"$undefined\"}]],[\"$\",\"html\",null,{\"lang\":\"en\",\"children\":[[\"$\",\"head\",null,{\"children\":[[[\"$\",\"link\",null,{\"rel\":\"preconnect\",\"href\":\"https://cdn-cookieyes.com\"}],[\"$\",\"link\",null,{\"rel\":\"dns-prefetch\",\"href\":\"https://cdn-cookieyes.com\"}],[\"$\",\"$L2\",null,{\"id\":\"cookieyes-preserve-native\",\"strategy\":\"beforeInteractive\",\"children\":\"window.ckySettings=window.ckySettings||{};window.ckySettings.nativeFunctions={fetch:window.fetch,xhr:window.XMLHttpRequest};\"}],[\"$\",\"$L2\",null,{\"id\":\"cookieyes\",\"src\":\"https://cdn-cookieyes.com/client_data/497224d8995aa8565cbc3037/script.js\",\"strategy\":\"beforeInteractive\"}]],[\"$\",\"script\",null,{\"referrerPolicy\":\"no-referrer-when-downgrade\",\"src\":\"https://edge.wingify.net/tag/1272784.js\"}],[[\"$\",\"$L2\",null,{\"src\":\"/hny.min.js\",\"strategy\":\"beforeInteractive\"}],[\"$\",\"$L2\",null,{\"id\":\"hny-init\",\"strategy\":\"beforeInteractive\",\"children\":\"\\n window.Hny.initializeTracing({\\n debug: false,\\n apiKey: \\\"hcaik_01kc76rhfsq3kjf9tdmx6f7bmhhd0rzcdrpbtbgk31bpj4nezy2frmbqx8\\\",\\n serviceName: \\\"www-next\\\",\\n configDefaults: {\\n ignoreNetworkEvents: true,\\n propagateTraceHeaderCorsUrls: [\\n /https:\\\\/\\\\/www\\\\.honeycomb\\\\.io/,\\n /https:\\\\/\\\\/www-stage\\\\.honeycomb\\\\.io/,\\n /https:\\\\/\\\\/honeycomb\\\\.vercel\\\\.app/,\\n /https:\\\\/\\\\/honeycomb-stage\\\\.vercel\\\\.app/\\n ]\\n }\\n });\\n \"}]],[\"$\",\"$L2\",null,{\"src\":\"https://stats.honeycomb.io/js/pa-DJvf3AtvU5wDjKkEU-JVs.js\",\"strategy\":\"beforeInteractive\",\"async\":true,\"id\":\"plausible-script\"}],[\"$\",\"$L2\",null,{\"id\":\"plausible-init\",\"strategy\":\"beforeInteractive\",\"children\":\"\\n window.plausible = window.plausible || function() {\\n (plausible.q = plausible.q || []).push(arguments)\\n };\\n plausible.init = plausible.init || function(i) {\\n plausible.o = i || {}\\n };\\n plausible.init();\\n \"}]]}],[\"$\",\"body\",null,{\"className\":\"roboto_a526148e-module__zhi6Uq__className poppins_b750422f-module__FR8AEW__className roboto_459e8801-module__Bzopaa__className poppins_c92f7652-module__gE1l-G__className\",\"children\":[[\"$\",\"$L3\",null,{\"parallelRouterKey\":\"children\",\"error\":\"$4\",\"errorStyles\":[],\"errorScripts\":[[\"$\",\"script\",\"script-0\",{\"src\":\"/_next/static/chunks/12~zlyzq33k~1.js\",\"async\":true}]],\"template\":[\"$\",\"$L5\",null,{}],\"templateStyles\":\"$undefined\",\"templateScripts\":\"$undefined\",\"notFound\":[[[\"$\",\"title\",null,{\"children\":\"404: This page could not be found.\"}],[\"$\",\"div\",null,{\"style\":{\"fontFamily\":\"system-ui,\\\"Segoe UI\\\",Roboto,Helvetica,Arial,sans-serif,\\\"Apple Color Emoji\\\",\\\"Segoe UI Emoji\\\"\",\"height\":\"100vh\",\"textAlign\":\"center\",\"display\":\"flex\",\"flexDirection\":\"column\",\"alignItems\":\"center\",\"justifyContent\":\"center\"},\"children\":[\"$\",\"div\",null,{\"children\":[[\"$\",\"style\",null,{\"dangerouslySetInnerHTML\":{\"__html\":\"body{color:#000;background:#fff;margin:0}.next-error-h1{border-right:1px solid rgba(0,0,0,.3)}@media (prefers-color-scheme:dark){body{color:#fff;background:#000}.next-error-h1{border-right:1px solid rgba(255,255,255,.3)}}\"}}],[\"$\",\"h1\",null,{\"className\":\"next-error-h1\",\"style\":{\"display\":\"inline-block\",\"margin\":\"0 20px 0 0\",\"padding\":\"0 23px 0 0\",\"fontSize\":24,\"fontWeight\":500,\"verticalAlign\":\"top\",\"lineHeight\":\"49px\"},\"children\":404}],\"$L6\"]}]}]],[]],\"forbidden\":\"$undefined\",\"unauthorized\":\"$undefined\"}],\"$L7\",\"$L8\",\"$L9\"]}]]}]]}],{\"children\":[\"$La\",{\"children\":[\"$Lb\",{\"children\":[\"$Lc\",{},null,false,null]},null,false,\"$@d\"]},null,false,null]},null,false,null],\"$Le\",false]],\"m\":\"$undefined\",\"G\":[\"$f\",[\"$L10\",\"$L11\"]],\"S\":false,\"h\":null,\"s\":\"$undefined\",\"l\":\"$undefined\",\"p\":\"$undefined\",\"d\":\"$undefined\",\"b\":\"VVuS_Z0Yp8bYu3V6Xy5hL\"}\n"])</script><script>self.__next_f.push([1,"6:[\"$\",\"div\",null,{\"style\":{\"display\":\"inline-block\"},\"children\":[\"$\",\"h2\",null,{\"style\":{\"fontSize\":14,\"fontWeight\":400,\"lineHeight\":\"49px\",\"margin\":0},\"children\":\"This page could not be found.\"}]}]\n7:[\"$\",\"$L12\",null,{\"gaId\":\"G-DJM5ZXPGB0\"}]\n8:[\"$\",\"$L13\",null,{\"gtmId\":\"GTM-KH7NL6K\"}]\n9:[\"$\",\"$L2\",null,{\"strategy\":\"afterInteractive\",\"id\":\"wphs\",\"src\":\"https://cdn.jsdelivr.net/npm/hockeystack@latest/hockeystack.min.js\",\"async\":true,\"data-apikey\":\"b7867a90ef8ece343a6e29fc6aa01e\",\"data-cookieless\":\"1\",\"data-auto-identify\":\"1\"}]\na:[\"$\",\"$1\",\"c\",{\"children\":[[[\"$\",\"link\",\"0\",{\"rel\":\"stylesheet\",\"href\":\"/_next/static/chunks/0nuksys438q2t.css\",\"precedence\":\"next\",\"crossOrigin\":\"$undefined\",\"nonce\":\"$undefined\"}],[\"$\",\"script\",\"script-0\",{\"src\":\"/_next/static/chunks/0ku~nn_l8-fol.js\",\"async\":true,\"nonce\":\"$undefined\"}],[\"$\",\"script\",\"script-1\",{\"src\":\"/_next/static/chunks/039u5_5hlemld.js\",\"async\":true,\"nonce\":\"$undefined\"}],[\"$\",\"script\",\"script-2\",{\"src\":\"/_next/static/chunks/189hrhe.fk4af.js\",\"async\":true,\"nonce\":\"$undefined\"}],[\"$\",\"script\",\"script-3\",{\"src\":\"/_next/static/chunks/0oz-qxk30w~qw.js\",\"async\":true,\"nonce\":\"$undefined\"}],[\"$\",\"script\",\"script-4\",{\"src\":\"/_next/static/chunks/0vx_phl8cla2s.js\",\"async\":true,\"nonce\":\"$undefined\"}],[\"$\",\"script\",\"script-5\",{\"src\":\"/_next/static/chunks/0xywjwd04osrr.js\",\"async\":true,\"nonce\":\"$undefined\"}],[\"$\",\"script\",\"script-6\",{\"src\":\"/_next/static/chunks/0t1~yeqvn891r.js\",\"async\":true,\"nonce\":\"$undefined\"}],[\"$\",\"script\",\"script-7\",{\"src\":\"/_next/static/chunks/0ks4m351.jbv2.js\",\"async\":true,\"nonce\":\"$undefined\"}],[\"$\",\"script\",\"script-8\",{\"src\":\"/_next/static/chunks/01gy5f4286e6a.js\",\"async\":true,\"nonce\":\"$undefined\"}]],\"$L14\"]}]\nb:[\"$\",\"$1\",\"c\",{\"children\":[null,[\"$\",\"$L3\",null,{\"parallelRouterKey\":\"children\",\"error\":\"$undefined\",\"errorStyles\":\"$undefined\",\"errorScripts\":\"$undefined\",\"template\":[\"$\",\"$L5\",null,{}],\"templateStyles\":\"$undefined\",\"templateScripts\":\"$undefined\",\"notFound\":\"$undefined\",\"forbidden\":\"$undefined\",\"unauthorized\":\"$undefined\"}]]}]\nc:[\"$\",\"$1\",\"c\",{\"children\":[\"$L15\",[[\"$\",\"script\",\"script-0\",{\"src\":\"/_next/static/chunks/09mg9tc2w3ag6.js\",\"async\":true,\"nonce\":\"$undefined\"}],[\"$\",\"script\",\"script-1\",{\"src\":\"/_next/static/chunks/0~-xo~ilf3e0r.js\",\"async\":true,\"nonce\":\"$undefined\"}]],[\"$\",\"$L16\",null,{\"children\":[\"$\",\"$17\",null,{\"name\":\"Next.MetadataOutlet\",\"children\":\"$@18\"}]}]]}]\n19:[]\nd:\"$W19\"\ne:[\"$\",\"$1\",\"h\",{\"children\":[null,[\"$\",\"$L1a\",null,{\"children\":\"$L1b\"}],[\"$\",\"div\",null,{\"hidden\":true,\"children\":[\"$\",\"$L1c\",null,{\"children\":[\"$\",\"$17\",null,{\"name\":\"Next.Metadata\",\"children\":\"$L1d\"}]}]}],[\"$\",\"meta\",null,{\"name\":\"next-size-adjust\",\"content\":\"\"}]]}]\n10:[\"$\",\"link\",\"0\",{\"rel\":\"stylesheet\",\"href\":\"/_next/static/chunks/0-a~7ljgpwyij.css\",\"precedence\":\"next\",\"crossOrigin\":\"$undefined\",\"nonce\":\"$undefined\"}]\n11:[\"$\",\"link\",\"1\",{\"rel\":\"stylesheet\",\"href\":\"/_next/static/chunks/0k9no2apwmz~n.css\",\"precedence\":\"next\",\"crossOrigin\":\"$undefined\",\"nonce\":\"$undefined\"}]\n1b:[[\"$\",\"meta\",\"0\",{\"charSet\":\"utf-8\"}],[\"$\",\"meta\",\"1\",{\"name\":\"viewport\",\"content\":\"width=device-width, initial-scale=1\"}]]\n"])</script><script>self.__next_f.push([1,"1e:I[955297,[\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"/_next/static/chunks/019vi3l~x0zoc.js\",\"/_next/static/chunks/0ku~nn_l8-fol.js\",\"/_next/static/chunks/039u5_5hlemld.js\",\"/_next/static/chunks/189hrhe.fk4af.js\",\"/_next/static/chunks/0oz-qxk30w~qw.js\",\"/_next/static/chunks/0vx_phl8cla2s.js\",\"/_next/static/chunks/0xywjwd04osrr.js\",\"/_next/static/chunks/0t1~yeqvn891r.js\",\"/_next/static/chunks/0ks4m351.jbv2.js\",\"/_next/static/chunks/01gy5f4286e6a.js\"],\"MobileMenuProvider\"]\n1f:I[303231,[\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"/_next/static/chunks/019vi3l~x0zoc.js\",\"/_next/static/chunks/0ku~nn_l8-fol.js\",\"/_next/static/chunks/039u5_5hlemld.js\",\"/_next/static/chunks/189hrhe.fk4af.js\",\"/_next/static/chunks/0oz-qxk30w~qw.js\",\"/_next/static/chunks/0vx_phl8cla2s.js\",\"/_next/static/chunks/0xywjwd04osrr.js\",\"/_next/static/chunks/0t1~yeqvn891r.js\",\"/_next/static/chunks/0ks4m351.jbv2.js\",\"/_next/static/chunks/01gy5f4286e6a.js\"],\"Header\"]\n"])</script><script>self.__next_f.push([1,"14:[[\"$\",\"$L1e\",null,{\"children\":[\"$\",\"$L1f\",null,{\"buttons\":[{\"_key\":\"9979c08d8605\",\"_type\":\"button\",\"iconReference\":null,\"link\":{\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"internalLink\":{\"_id\":\"76c12af0-d65b-4e4f-ba3f-c25e9d904ad1\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"get-a-demo\",\"summary\":null,\"title\":\"Get a Honeycomb Demo\"},\"target\":\"_self\",\"text\":\"Get a demo\"},\"modalForm\":null,\"modalVideo\":{\"_type\":\"videoPlayer\",\"uploadedVideo\":null,\"videoSource\":\"upload\"},\"variant\":\"solid\"},{\"_key\":\"f1b0985cac23\",\"_type\":\"button\",\"iconReference\":null,\"link\":{\"_type\":\"link\",\"externalLink\":\"https://ui.honeycomb.io/signup\",\"internalLink\":null,\"target\":\"_self\",\"text\":\"Start for free\"},\"modalForm\":null,\"modalVideo\":null,\"variant\":\"outline\"}],\"loginUrl\":\"https://ui.honeycomb.io/login\",\"preHeader\":{\"button\":{\"_type\":\"button\",\"iconReference\":null,\"link\":{\"_type\":\"link\",\"internalLink\":{\"_id\":\"da07f58b-9f3f-4e77-9ebc-140a67c2dc94\",\"_type\":\"page\",\"download\":null,\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Observability Engineering O'Reilly Book\",\"asset\":{\"_ref\":\"image-823053e26c243df14b4e682ba2e91d260e06f401-2880x1590-png\",\"_type\":\"reference\"}}},\"resourceType\":null,\"slug\":\"observability-engineering-oreilly-book\",\"summary\":null,\"title\":\"Observability Engineering O'Reilly Book\"},\"target\":\"_self\",\"text\":\"Get your copy\"},\"modalForm\":null,\"modalVideo\":null,\"variant\":\"solid-secondary\"},\"text\":\"Observability Engineering second edition out now! 27 net-new chapters written for today's observability challenges.\"},\"sections\":[{\"_key\":\"b97aeefe06e8\",\"_type\":\"section\",\"featured\":{\"featuredDescription\":\"Honeycomb was built for the AI era. Learn how to futureproof your software for what comes next.\",\"featuredLink\":{\"_type\":\"link\",\"internalLink\":{\"_id\":\"d5963fdd-59ef-4656-9227-e8185cd2a2f3\",\"_type\":\"page\",\"download\":null,\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"The observability platform for the AI era\",\"asset\":{\"_ref\":\"image-63a3ac161c99c1796fc5a7974c3d092f1cfa33b8-1440x795-png\",\"_type\":\"reference\"}}},\"resourceType\":null,\"slug\":\"platform\",\"summary\":null,\"title\":\"Platform\"},\"target\":\"_self\",\"text\":\"See overview\"},\"featuredTitle\":\"Explore the platform\"},\"sectionTitle\":\"Observability Platform\",\"submenues\":[{\"_key\":\"6f71ed942fc9\",\"_type\":\"submenu\",\"submenuLinks\":[{\"_key\":\"3a7e355c0c21\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"8812e19c-592e-4c61-84c1-2651e0a954d9\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"platform/distributed-tracing\",\"summary\":null,\"title\":\"Distributed Tracing\"},\"target\":\"_self\",\"text\":\"Distributed Tracing\"},{\"_key\":\"57c3e96709fa\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"d0b34557-8feb-4ba5-b2eb-01f432178b13\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"platform/log-analytics\",\"summary\":null,\"title\":\"Log Analytics\"},\"target\":\"_self\",\"text\":\"Log Analytics\"},{\"_key\":\"7c7fa92d4ab4\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"bbf5cba4-e312-413d-a408-3309d4658981\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"platform/metrics\",\"summary\":null,\"title\":\"Metrics\"},\"target\":\"_self\",\"text\":\"Time Series Metrics\"},{\"_key\":\"62cd2b120845\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"075a1a4e-92e4-4f79-8467-c26c60d13c9f\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"platform/frontend-observability\",\"summary\":null,\"title\":\"Frontend Observability\"},\"target\":\"_self\",\"text\":\"Frontend Observability\"},{\"_key\":\"1c28ef24a5cd\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"1823678b-ccc8-4979-8c9f-462d7ec3e2d2\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"platform/telemetry-pipeline\",\"summary\":null,\"title\":\"Telemetry Pipeline\"},\"target\":\"_self\",\"text\":\"Telemetry Pipeline\"},{\"_key\":\"a352c53a8036\",\"_type\":\"link\",\"anchorLink\":\"/platform/private-cloud\",\"enableDownloadFunctionality\":false,\"internalLink\":null,\"target\":\"_self\",\"text\":\"Private Cloud\"}],\"submenuTitle\":{\"link\":{\"_type\":\"link\",\"internalLink\":{\"_id\":\"d5963fdd-59ef-4656-9227-e8185cd2a2f3\",\"_type\":\"page\",\"download\":null,\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"The observability platform for the AI era\",\"asset\":{\"_ref\":\"image-63a3ac161c99c1796fc5a7974c3d092f1cfa33b8-1440x795-png\",\"_type\":\"reference\"}}},\"resourceType\":null,\"slug\":\"platform\",\"summary\":null,\"title\":\"Platform\"},\"target\":\"_self\",\"text\":\"Core Observability\"}}},{\"_key\":\"776067ac438a\",\"_type\":\"submenu\",\"submenuLinks\":[{\"_key\":\"6218cd7e67db\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"internalLink\":{\"_id\":\"17b07749-37e6-434c-81fe-496d29fdac7b\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"platform/agent-timeline\",\"summary\":null,\"title\":\"Agent Timeline\"},\"target\":\"_self\",\"text\":\"Agent Timeline\"},{\"_key\":\"4f3399612de8\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"internalLink\":{\"_id\":\"152efaa5-299f-4c15-818b-7dda6faaf550\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"use-cases/ai-llm-observability\",\"summary\":null,\"title\":\"AI \u0026 LLMs\"},\"target\":\"_self\",\"text\":\"LLM Observability\"}],\"submenuTitle\":{\"link\":{\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"internalLink\":null,\"target\":\"_self\"},\"string\":\"AI Agent Observability\"}},{\"_key\":\"f930b4882a79\",\"_type\":\"submenu\",\"submenuLinks\":[{\"_key\":\"bafda870cc04\",\"_type\":\"link\",\"anchorLink\":\"/platform/canvas\",\"enableDownloadFunctionality\":false,\"internalLink\":null,\"target\":\"_self\",\"text\":\"Canvas\"},{\"_key\":\"e4c44c9abcc8\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"internalLink\":{\"_id\":\"099fc215-3076-4b38-9cae-69574de9b848\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"technologies/ai-agents\",\"summary\":null,\"title\":\"AI Agents\"},\"target\":\"_self\",\"text\":\"MCP\"},{\"_key\":\"146b1517edde\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"internalLink\":{\"_id\":\"1fd45d6f-7bde-43bb-a3da-1c97fe37fa5f\",\"_type\":\"blogArticle\",\"download\":null,\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"advanced\":{\"highPriority\":false},\"alt\":\"Accelerate Your OpenTelemetry Migrations With Honeycomb's Agent Skills\",\"asset\":{\"_ref\":\"image-cc8a44b656f324560a0aa7ec2d16dc0f72777a5d-3840x2160-png\",\"_type\":\"reference\"}}},\"resourceType\":null,\"slug\":\"accelerate-opentelemetry-migrations-honeycomb-agent-skills\",\"summary\":\"With the release of our Agent Skills, we’ve used our domain knowledge to make your agents even more powerful. Instead of having to copy and paste blocks of markdown into Claude Code, we've distilled everything we know about using Honeycomb into a set of core skills, packaged it up, and are making it open source today!\",\"title\":\"Accelerate Your OpenTelemetry Migrations With Honeycomb's Agent Skills\"},\"target\":\"_self\",\"text\":\"MCP Skills\"},{\"_key\":\"89cfc92cfad2\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"internalLink\":{\"_id\":\"733a21e1-1066-4e73-b140-7dc621bdd3bc\",\"_type\":\"blogArticle\",\"download\":null,\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Introducing Anomaly Detection: Your Early Warning System for Service Health\",\"asset\":{\"_ref\":\"image-39c5ee873d3c0bef49f04aacf5fdd02d8fa69399-1920x1080-png\",\"_type\":\"reference\"}}},\"resourceType\":null,\"slug\":\"introducing-anomaly-detection-early-warning-system-service-health\",\"summary\":\"Today, we're excited to announce the release of Anomaly Detection (currently in alpha), Honeycomb's proactive approach to understanding and acting on service health.\",\"title\":\"Introducing Anomaly Detection: Your Early Warning System for Service Health\"},\"target\":\"_self\",\"text\":\"Anomaly Detection\"}],\"submenuTitle\":{\"_type\":\"object\",\"link\":{\"_type\":\"link\",\"internalLink\":{\"_id\":\"58f6403e-b402-449a-90d4-57d9c0122631\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"platform/intelligence\",\"summary\":null,\"title\":\"Honeycomb Intelligence\"},\"target\":\"_self\",\"text\":\"Agentic Intelligence\"}}},{\"_key\":\"670154802905\",\"_type\":\"submenu\",\"submenuLinks\":[{\"_key\":\"043ac481e220\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"7ce2e31d-1fab-44a2-9588-7fe48fa624fe\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"platform/slos\",\"summary\":null,\"title\":\"SLOs\"},\"target\":\"_self\",\"text\":\"SLOs\"},{\"_key\":\"ad585cbbd043\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"bd42c0ad-4815-4c0d-9eab-329d61d3255b\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"platform/service-map\",\"summary\":null,\"title\":\"Service Map\"},\"target\":\"_self\",\"text\":\"Service Map\"},{\"_key\":\"bafe0c86bbaf\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"63e6273c-ad42-4ca7-84d1-f2add5448f13\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"platform/bubbleup\",\"summary\":null,\"title\":\"BubbleUp\"},\"target\":\"_self\",\"text\":\"BubbleUp\"},{\"_key\":\"e8757ff0a28a\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"e97d4cd4-a2fd-4c54-b847-14cbe27cb025\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"platform/opentelemetry\",\"summary\":null,\"title\":\"OpenTelemetry\"},\"target\":\"_self\",\"text\":\"OpenTelemetry\"},{\"_key\":\"d1f9cc290db7\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"e69a7bb2-8b05-4a53-9d1d-c86f958b719b\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"platform/integrations\",\"summary\":null,\"title\":\"Honeycomb Integrations\"},\"target\":\"_self\",\"text\":\"App Integrations\"}],\"submenuTitle\":{\"link\":{\"_type\":\"link\",\"internalLink\":null,\"target\":\"_self\"},\"string\":\"Built-in Features\"}}]},{\"_key\":\"afac2aa97881\",\"_type\":\"section\",\"featured\":{\"featuredDescription\":\"Discover why Honeycomb is the better choice for your engineers, your customers, and your bottom line.\",\"featuredLink\":{\"_type\":\"link\",\"internalLink\":{\"_id\":\"d52bd9a3-ba69-4820-9781-69ceb0477d0b\",\"_type\":\"page\",\"download\":null,\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Why Honeycomb? We were built for this.\",\"asset\":{\"_ref\":\"image-aed26058103b0dab7df8f82907350fcbb72a6b60-2880x1590-png\",\"_type\":\"reference\"}}},\"resourceType\":null,\"slug\":\"why-honeycomb\",\"summary\":null,\"title\":\"Why Honeycomb?\"},\"target\":\"_self\",\"text\":\"Learn More\"},\"featuredTitle\":\"Why Honeycomb\"},\"sectionTitle\":\"Solutions\",\"submenues\":[{\"_key\":\"a62453edc69e\",\"_type\":\"submenu\",\"submenuLinks\":[{\"_key\":\"973236213b56\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"e97d4cd4-a2fd-4c54-b847-14cbe27cb025\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"platform/opentelemetry\",\"summary\":null,\"title\":\"OpenTelemetry\"},\"target\":\"_self\",\"text\":\"OpenTelemetry\"},{\"_key\":\"31d4054b0539\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"2de474c6-ecb5-4c29-a908-36e791461ac3\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"technologies/aws\",\"summary\":null,\"title\":\"AWS\"},\"target\":\"_self\",\"text\":\"Amazon Web Services\"},{\"_key\":\"e4533f4323a3\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"d75068e4-4e97-49fc-a85a-c00e5e2494b9\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"technologies/microsoft-azure\",\"summary\":null,\"title\":\"Microsoft Azure\"},\"target\":\"_self\",\"text\":\"Microsoft Azure\"},{\"_key\":\"37dbd8aeb8c4\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"bcff775b-f39f-4caf-a5c5-2923ddcc6636\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"technologies/kubernetes\",\"summary\":null,\"title\":\"Kubernetes\"},\"target\":\"_self\",\"text\":\"Kubernetes\"},{\"_key\":\"6413768f27dc\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"d122bbbc-30d1-4fe8-affc-e85ea473483b\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"technologies/google-cloud\",\"summary\":null,\"title\":\"Google Cloud\"},\"target\":\"_self\",\"text\":\"Google Cloud\"},{\"_key\":\"e3ba65b3e56a\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"099fc215-3076-4b38-9cae-69574de9b848\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"technologies/ai-agents\",\"summary\":null,\"title\":\"AI Agents\"},\"target\":\"_self\",\"text\":\"AI Agents\"}],\"submenuTitle\":{\"link\":{\"_type\":\"link\",\"internalLink\":null,\"target\":\"_self\"},\"string\":\"Technologies\"}},{\"_key\":\"83b3f15dfc78\",\"_type\":\"submenu\",\"submenuLinks\":[{\"_key\":\"12dfc27e1b09\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"152efaa5-299f-4c15-818b-7dda6faaf550\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"use-cases/ai-llm-observability\",\"summary\":null,\"title\":\"AI \u0026 LLMs\"},\"target\":\"_self\",\"text\":\"LLM Observability\"},{\"_key\":\"ag3nt0bs3rv01\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"8f7dab23-a9ba-4218-9ab8-a6afee24d87d\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"use-cases/agent-observability\",\"summary\":null,\"title\":\"Agent Observability\"},\"target\":\"_self\",\"text\":\"Agent Observability\"},{\"_key\":\"cdb5d85b653f\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"de213f02-45ba-46b3-b18f-596eadce44f0\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"use-cases/incident-response\",\"summary\":null,\"title\":\"Incident Response\"},\"target\":\"_self\",\"text\":\"Incident Response\"},{\"_key\":\"05d3787884f2\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"74a75520-566a-4331-a9d7-bf1996e3ce2d\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"use-cases/predictable-costs\",\"summary\":null,\"title\":\"Predictable Costs\"},\"target\":\"_self\",\"text\":\"Predictable Costs\"},{\"_key\":\"d56b2265ff47\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"ffd53dbd-e402-4439-b8f2-ef84b0a12e92\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"use-cases/devops-releases\",\"summary\":null,\"title\":\"DevOps \u0026 Releases\"},\"target\":\"_self\",\"text\":\"DevOps \u0026 Releases\"},{\"_key\":\"687be93e73cd\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"075a1a4e-92e4-4f79-8467-c26c60d13c9f\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"platform/frontend-observability\",\"summary\":null,\"title\":\"Frontend Observability\"},\"target\":\"_self\",\"text\":\"Frontend Development\"},{\"_key\":\"fd9b0d71772c\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"09c23c9b-deb8-45be-a756-c0809bd1e91c\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"use-cases/meet-customer-experience-slas\",\"summary\":null,\"title\":\"Customer SLAs\"},\"target\":\"_self\",\"text\":\"Meet Customer SLAs\"},{\"_key\":\"64e59d6ab8aa\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"internalLink\":{\"_id\":\"d43692a4-4059-437e-bf22-46583f24dcc4\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"use-cases/cloud-migrations\",\"summary\":null,\"title\":\"Cloud Migrations\"},\"target\":\"_self\",\"text\":\"Cloud Migrations\"}],\"submenuTitle\":{\"link\":{\"_type\":\"link\",\"internalLink\":null,\"target\":\"_self\"},\"string\":\"Use Cases\"}},{\"_key\":\"3f181a3651da\",\"_type\":\"submenu\",\"submenuLinks\":[{\"_key\":\"ece052132a81\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"ai-startups-industry\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"industries/ai-startups\",\"summary\":null,\"title\":\"AI Startups\"},\"target\":\"_self\",\"text\":\"AI Startups\"},{\"_key\":\"8e6dab1d6286\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"e2c44aff-8668-4e3a-8120-b62aa3eb40dc\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"industries/financial-services\",\"summary\":null,\"title\":\"Financial Services\"},\"target\":\"_self\",\"text\":\"Financial Services\"},{\"_key\":\"440f49eafb36\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"b2922d61-2d28-4d9e-8368-05b6fb77d703\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"industries/retail\",\"summary\":null,\"title\":\"Retail \u0026 Ecommerce\"},\"target\":\"_self\",\"text\":\"Retail \u0026 Ecommerce\"},{\"_key\":\"9cb0aa2dcebe\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"software-technology-industry\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"industries/software-technology\",\"summary\":null,\"title\":\"Software \u0026 Technology\"},\"target\":\"_self\",\"text\":\"Software \u0026 Technology\"}],\"submenuTitle\":{\"link\":{\"_type\":\"link\",\"internalLink\":null,\"target\":\"_self\"},\"string\":\"Industries\"}},{\"_key\":\"fa238aa2fe57\",\"_type\":\"submenu\",\"submenuLinks\":[{\"_key\":\"91d95a07e165\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"be12278f-29bc-456e-9b70-0293181287f2\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"why-honeycomb/customers\",\"summary\":null,\"title\":\"Customers\"},\"target\":\"_self\",\"text\":\"Customer Stories\"},{\"_key\":\"05a8b16c4187\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"d133a33b-dfa5-44cc-9c55-55ba076367fe\",\"_type\":\"page\",\"download\":null,\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Choosing the right observability platform\",\"asset\":{\"_ref\":\"image-eb6da1c61d2c068135476c019107f6266ce8651d-1844x1088-png\",\"_type\":\"reference\"}}},\"resourceType\":null,\"slug\":\"why-honeycomb/comparisons\",\"summary\":null,\"title\":\"Comparisons\"},\"target\":\"_self\",\"text\":\"Comparisons\"},{\"_key\":\"eda3f9bc2fd1\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"29443270-097f-4364-88ff-c3cd79ea74f2\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"why-honeycomb/enterprise\",\"summary\":null,\"title\":\"Enterprise\"},\"target\":\"_self\",\"text\":\"For Enterprise\"},{\"_key\":\"711d9271d964\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"internalLink\":{\"_id\":\"7c8667f3-5e0d-4fb3-ace2-86560e355930\",\"_type\":\"page\",\"download\":null,\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"advanced\":{\"highPriority\":false},\"alt\":\"Honeycomb Services\",\"asset\":{\"_ref\":\"image-7322ef9523352f9ca9bef3e2f37cce914b519c49-2880x1590-png\",\"_type\":\"reference\"}}},\"resourceType\":null,\"slug\":\"why-honeycomb/services\",\"summary\":null,\"title\":\"Honeycomb Services\"},\"target\":\"_self\",\"text\":\"Honeycomb Services\"}],\"submenuTitle\":{\"link\":{\"_type\":\"link\",\"internalLink\":{\"_id\":\"d52bd9a3-ba69-4820-9781-69ceb0477d0b\",\"_type\":\"page\",\"download\":null,\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Why Honeycomb? We were built for this.\",\"asset\":{\"_ref\":\"image-aed26058103b0dab7df8f82907350fcbb72a6b60-2880x1590-png\",\"_type\":\"reference\"}}},\"resourceType\":null,\"slug\":\"why-honeycomb\",\"summary\":null,\"title\":\"Why Honeycomb?\"},\"target\":\"_self\",\"text\":\"Why Honeycomb?\"}}}]},{\"_key\":\"f89507b788f8\",\"_type\":\"section\",\"featured\":{\"featuredDescription\":\"Start your journey with the definitive guide to observability. Download our complimentary ebook.\",\"featuredLink\":{\"_type\":\"link\",\"internalLink\":{\"_id\":\"da07f58b-9f3f-4e77-9ebc-140a67c2dc94\",\"_type\":\"page\",\"download\":null,\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Observability Engineering O'Reilly Book\",\"asset\":{\"_ref\":\"image-823053e26c243df14b4e682ba2e91d260e06f401-2880x1590-png\",\"_type\":\"reference\"}}},\"resourceType\":null,\"slug\":\"observability-engineering-oreilly-book\",\"summary\":null,\"title\":\"Observability Engineering O'Reilly Book\"},\"target\":\"_self\",\"text\":\"Get your copy\"},\"featuredTitle\":\"Observability Engineering\"},\"sectionTitle\":\"Learn \",\"submenues\":[{\"_key\":\"cb2c7ca3a812\",\"_type\":\"submenu\",\"submenuLinks\":[{\"_key\":\"0579b3261d13\",\"_type\":\"link\",\"externalLink\":\"https://docs.honeycomb.io/\",\"internalLink\":null,\"target\":\"_blank\",\"text\":\"Docs\"},{\"_key\":\"ed11462fee29\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"internalLink\":{\"_id\":\"da07f58b-9f3f-4e77-9ebc-140a67c2dc94\",\"_type\":\"page\",\"download\":null,\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Observability Engineering O'Reilly Book\",\"asset\":{\"_ref\":\"image-823053e26c243df14b4e682ba2e91d260e06f401-2880x1590-png\",\"_type\":\"reference\"}}},\"resourceType\":null,\"slug\":\"observability-engineering-oreilly-book\",\"summary\":null,\"title\":\"Observability Engineering O'Reilly Book\"},\"target\":\"_self\",\"text\":\"Observability Engineering\"},{\"_key\":\"acf97f14bc60\",\"_type\":\"link\",\"externalLink\":\"https://docs.honeycomb.io/get-started\",\"internalLink\":null,\"target\":\"_blank\",\"text\":\"Quickstart\"},{\"_key\":\"a54f159c78a0\",\"_type\":\"link\",\"externalLink\":\"https://docs.honeycomb.io/send-data/\",\"internalLink\":null,\"target\":\"_blank\",\"text\":\"Sending data\"},{\"_key\":\"053ed6ac8255\",\"_type\":\"link\",\"externalLink\":\"https://play.honeycomb.io/sandbox/tours\",\"internalLink\":null,\"target\":\"_blank\",\"text\":\"Sandbox\"}],\"submenuTitle\":{\"link\":{\"_type\":\"link\",\"internalLink\":null,\"target\":\"_self\"},\"string\":\"Engineers\"}},{\"_key\":\"30b7f786460e\",\"_type\":\"submenu\",\"submenuLinks\":[{\"_key\":\"104a20760fd8\",\"_type\":\"link\",\"anchorLink\":\"/blog\",\"internalLink\":null,\"target\":\"_self\",\"text\":\"Blog\"},{\"_key\":\"6d821088a12e\",\"_type\":\"link\",\"anchorLink\":\"/resources/getting-started\",\"internalLink\":null,\"target\":\"_self\",\"text\":\"Getting Started\"},{\"_key\":\"e4d103599e59\",\"_type\":\"link\",\"anchorLink\":\"/resources/guides\",\"internalLink\":null,\"target\":\"_self\",\"text\":\"Technical Guides\"},{\"_key\":\"84b6f5e31734\",\"_type\":\"link\",\"anchorLink\":\"/resources/case-studies\",\"internalLink\":null,\"target\":\"_self\",\"text\":\"Case Studies\"},{\"_key\":\"a7b9915d2b3b\",\"_type\":\"link\",\"anchorLink\":\"/resources/webinars\",\"internalLink\":null,\"target\":\"_self\",\"text\":\"Webinars\"},{\"_key\":\"a3e557190042\",\"_type\":\"link\",\"anchorLink\":\"/resources/whitepapers\",\"internalLink\":null,\"target\":\"_self\",\"text\":\"Whitepapers\"},{\"_key\":\"f6862a0a3b48\",\"_type\":\"link\",\"anchorLink\":\"/resources/product-videos\",\"internalLink\":null,\"target\":\"_self\",\"text\":\"Product Videos\"}],\"submenuTitle\":{\"link\":{\"_type\":\"link\",\"anchorLink\":\"/resources\",\"internalLink\":null,\"target\":\"_self\",\"text\":\"Resource Center\"}}},{\"_key\":\"d0f9a93d85af\",\"_type\":\"submenu\",\"submenuLinks\":[{\"_key\":\"8a2f7421464f\",\"_type\":\"link\",\"anchorLink\":\"/events\",\"internalLink\":null,\"target\":\"_self\",\"text\":\"Events\"},{\"_key\":\"eb8b17f096e8\",\"_type\":\"link\",\"internalLink\":{\"_id\":\"cc965279-3211-46ce-8f2c-bf64b4555a52\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"office-hours\",\"summary\":null,\"title\":\"Observability Office Hours\"},\"target\":\"_self\",\"text\":\"Office Hours\"},{\"_key\":\"bb0360e4b1ad\",\"_type\":\"link\",\"externalLink\":\"https://join.slack.com/t/honeycombpollinators/shared_invite/zt-3zl4f8i68-1PhyiwIIqZ0mCXtJjJcSsg\",\"internalLink\":null,\"target\":\"_blank\",\"text\":\"Pollinators Slack\"}],\"submenuTitle\":{\"link\":{\"_type\":\"link\",\"internalLink\":null,\"target\":\"_self\"},\"string\":\"Community\"}},{\"_key\":\"93162a1c4ad9\",\"_type\":\"submenu\",\"submenuLinks\":[{\"_key\":\"b410785737ee\",\"_type\":\"link\",\"externalLink\":\"https://academy.honeycomb.io/app/catalog\",\"internalLink\":null,\"target\":\"_blank\",\"text\":\"Course Catalog\"},{\"_key\":\"eba7082cbcd2\",\"_type\":\"link\",\"externalLink\":\"https://academy.honeycomb.io/app/learning_paths\",\"internalLink\":null,\"target\":\"_blank\",\"text\":\"Learning Paths\"}],\"submenuTitle\":{\"link\":{\"_type\":\"link\",\"externalLink\":\"https://academy.honeycomb.io/\",\"internalLink\":null,\"target\":\"_blank\",\"text\":\"Honeycomb Academy\"}}}]},{\"_key\":\"dfc1d152e74d\",\"_type\":\"section\",\"featured\":{\"featuredDescription\":\"Bring observability to every software engineer.\",\"featuredLink\":{\"_type\":\"link\",\"internalLink\":{\"_id\":\"89eca311-0c6a-4570-95bd-b4f659e6aee1\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"about\",\"summary\":null,\"title\":\"About Us\"},\"target\":\"_self\",\"text\":\"About Us\"},\"featuredTitle\":\"Our mission\"},\"sectionTitle\":\"Company\",\"submenues\":[{\"_key\":\"ffc41c9baeda\",\"_type\":\"submenu\",\"submenuDescription\":\"Learn about our company, mission and values.\",\"submenuLinks\":null,\"submenuTitle\":{\"link\":{\"_type\":\"link\",\"internalLink\":{\"_id\":\"89eca311-0c6a-4570-95bd-b4f659e6aee1\",\"_type\":\"page\",\"download\":null,\"mainImage\":null,\"resourceType\":null,\"slug\":\"about\",\"summary\":null,\"title\":\"About Us\"},\"target\":\"_self\",\"text\":\"About Us\"}}},{\"_key\":\"f42e12d30ae5\",\"_type\":\"submenu\",\"submenuDescription\":\"Come for the impact, stay for the culture.\\n\",\"submenuLinks\":null,\"submenuTitle\":{\"link\":{\"_type\":\"link\",\"anchorLink\":\"/careers\",\"internalLink\":null,\"target\":\"_self\",\"text\":\"Careers\"}}},{\"_key\":\"4c3608a4ece0\",\"_type\":\"submenu\",\"submenuDescription\":\"See Honeycomb's latest press releases, media, and more\",\"submenuLinks\":null,\"submenuTitle\":{\"link\":{\"_type\":\"link\",\"internalLink\":{\"_id\":\"bf3a8b58-5814-4183-92f9-76e631372fb2\",\"_type\":\"page\",\"download\":null,\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"advanced\":{\"highPriority\":false}}},\"resourceType\":null,\"slug\":\"news\",\"summary\":null,\"title\":\"News\"},\"target\":\"_self\",\"text\":\"News\"}}},{\"_key\":\"47b17347e546\",\"_type\":\"submenu\",\"submenuDescription\":\"Learn more about becoming a Honeycomb partner.\",\"submenuLinks\":null,\"submenuTitle\":{\"link\":{\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"internalLink\":{\"_id\":\"de254d71-5d58-4cda-930a-20a976ea4353\",\"_type\":\"page\",\"download\":null,\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"advanced\":{\"highPriority\":false}}},\"resourceType\":null,\"slug\":\"partners\",\"summary\":null,\"title\":\"Become a Honeycomb Partner\"},\"target\":\"_self\",\"text\":\"Partners\"}}}]},{\"_key\":\"b519e18d3109\",\"_type\":\"link\",\"anchorLink\":\"/pricing\",\"featured\":null,\"internalLink\":null,\"submenues\":null,\"target\":\"_self\",\"text\":\"Pricing\"}]}]}],\"$L20\",\"$L21\",\"$L22\",false]\n"])</script><script>self.__next_f.push([1,"24:I[19717,[\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"/_next/static/chunks/019vi3l~x0zoc.js\",\"/_next/static/chunks/0ku~nn_l8-fol.js\",\"/_next/static/chunks/039u5_5hlemld.js\",\"/_next/static/chunks/189hrhe.fk4af.js\",\"/_next/static/chunks/0oz-qxk30w~qw.js\",\"/_next/static/chunks/0vx_phl8cla2s.js\",\"/_next/static/chunks/0xywjwd04osrr.js\",\"/_next/static/chunks/0t1~yeqvn891r.js\",\"/_next/static/chunks/0ks4m351.jbv2.js\",\"/_next/static/chunks/01gy5f4286e6a.js\",\"/_next/static/chunks/09mg9tc2w3ag6.js\",\"/_next/static/chunks/0~-xo~ilf3e0r.js\"],\"\"]\n2f:I[317118,[\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"/_next/static/chunks/019vi3l~x0zoc.js\"],\"IconMark\"]\n20:[\"$\",\"$L3\",null,{\"parallelRouterKey\":\"children\",\"error\":\"$undefined\",\"errorStyles\":\"$undefined\",\"errorScripts\":\"$undefined\",\"template\":[\"$\",\"$L5\",null,{}],\"templateStyles\":\"$undefined\",\"templateScripts\":\"$undefined\",\"notFound\":[\"$L23\",[]],\"forbidden\":\"$undefined\",\"unauthorized\":\"$undefined\"}]\n"])</script><script>self.__next_f.push([1,"21:[\"$\",\"footer\",null,{\"className\":\"original-footer font-roboto text-hc-slate mx-auto max-w-[1152px] px-4\",\"children\":[\"$\",\"div\",null,{\"className\":\"flex w-full flex-col items-center gap-[40px] py-[80px] lg:flex-row lg:items-stretch lg:gap-[132px]\",\"children\":[[\"$\",\"div\",null,{\"className\":\"order-2 flex-1 lg:order-1\",\"children\":[[\"$\",\"div\",null,{\"className\":\"hidden flex-1 flex-row justify-between pb-[74px] lg:flex\",\"children\":[[\"$\",\"div\",\"9b31234550a8\",{\"className\":\"flex flex-col gap-3\",\"children\":[[\"$\",\"span\",null,{\"className\":\"text-base leading-[150%] font-semibold\",\"children\":\"Observability Platform\"}],[\"$\",\"ul\",null,{\"children\":[[\"$\",\"li\",\"3709d74ab43c\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/pricing\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"3709d74ab43c\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Pricing\",\"$undefined\"]}]}],[\"$\",\"li\",\"c73c8241288b\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/platform\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"c73c8241288b\",\"_type\":\"link\",\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Platform Overview\",\"$undefined\"]}]}],[\"$\",\"li\",\"7270c5c87c85\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/platform/frontend-observability\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"7270c5c87c85\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Frontend Observability\",\"$undefined\"]}]}],[\"$\",\"li\",\"db25504b1c78\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/platform/log-analytics\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"db25504b1c78\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Log Analytics\",\"$undefined\"]}]}],[\"$\",\"li\",\"ea87e5e00146\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/platform/distributed-tracing\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"ea87e5e00146\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Distributed Tracing\",\"$undefined\"]}]}],[\"$\",\"li\",\"045ae34eb65d\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/platform/metrics\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"045ae34eb65d\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Metrics\",\"$undefined\"]}]}],[\"$\",\"li\",\"3d1692a51e34\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/platform/telemetry-pipeline\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"3d1692a51e34\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Telemetry Pipeline\",\"$undefined\"]}]}],[\"$\",\"li\",\"4196f597a92d\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/platform/private-cloud\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"4196f597a92d\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Private Cloud\",\"$undefined\"]}]}],[\"$\",\"li\",\"b22d2cde4a3d\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/platform/slos\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"b22d2cde4a3d\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"SLOs\",\"$undefined\"]}]}],[\"$\",\"li\",\"0f5a9a5f7aa7\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/platform/service-map\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"0f5a9a5f7aa7\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Service Map\",\"$undefined\"]}]}],[\"$\",\"li\",\"6db0fbacbbc4\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/platform/bubbleup\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"6db0fbacbbc4\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"BubbleUp\",\"$undefined\"]}]}],[\"$\",\"li\",\"d672da05edda\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/platform/opentelemetry\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"d672da05edda\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"OpenTelemetry\",\"$undefined\"]}]}],[\"$\",\"li\",\"80b1b84cfd32\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/platform/integrations\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"80b1b84cfd32\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"App Integrations\",\"$undefined\"]}]}]]}]]}],\"$L25\",\"$L26\",\"$L27\"]}],\"$L28\"]}],\"$L29\"]}]}]\n"])</script><script>self.__next_f.push([1,"22:[\"$\",\"footer\",null,{\"className\":\"font-roboto text-hc-slate small-footer container hidden flex-col items-center justify-between gap-10 py-10 lg:flex-row lg:gap-5 xl:gap-0\",\"children\":[[\"$\",\"ul\",null,{\"className\":\"flex flex-1 flex-col justify-between gap-5 text-center lg:flex-2/3 lg:flex-row lg:gap-0 lg:text-left\",\"children\":[[\"$\",\"li\",null,{\"children\":[\"$\",\"$L24\",null,{\"href\":\"https://honeycomb.io\",\"className\":\"text-hc-cobalt leading-[20px] tracking-[0.02em] underline\",\"children\":\"Honeycomb.io\"}]}],[[\"$\",\"li\",\"4042940388e7\",{\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/terms\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"4042940388e7\",\"_type\":\"link\",\"className\":\"text-hc-cobalt leading-[20px] tracking-[0.02em] text-nowrap underline\",\"children\":[\"Terms of Service\",\"$undefined\"]}]}],[\"$\",\"li\",\"df3d0de1abf9\",{\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/acceptable-use-policy\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"df3d0de1abf9\",\"_type\":\"link\",\"className\":\"text-hc-cobalt leading-[20px] tracking-[0.02em] text-nowrap underline\",\"children\":[\"Acceptable Use Policy\",\"$undefined\"]}]}],[\"$\",\"li\",\"de1418f17f9f\",{\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/privacy\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"de1418f17f9f\",\"_type\":\"link\",\"className\":\"text-hc-cobalt leading-[20px] tracking-[0.02em] text-nowrap underline\",\"children\":[\"Privacy Notice\",\"$undefined\"]}]}]],[\"$\",\"li\",null,{\"children\":[\"$\",\"$L24\",null,{\"href\":\"#\",\"className\":\"cky-banner-element text-hc-cobalt leading-[20px] tracking-[0.02em] text-nowrap underline\",\"children\":\"Your Privacy Choices\"}]}]]}],[\"$\",\"span\",null,{\"className\":\"text-end leading-[20px] tracking-[0.02em] lg:max-w-fit xl:max-w-none xl:flex-1/3\",\"children\":[\"© \",2026,\" \",\"Hound Technology, Inc.\"]}]]}]\n"])</script><script>self.__next_f.push([1,"2a:T9dd,"])</script><script>self.__next_f.push([1,"{\"@context\":\"https://schema.org\",\"@graph\":[{\"@type\":[\"WebPage\",\"CollectionPage\"],\"@id\":\"https://www.honeycomb.io/blog\",\"url\":\"https://www.honeycomb.io/blog\",\"name\":\"Observability, Distributed Tracing, and More - Honeycomb Blog\",\"isPartOf\":{\"@id\":\"https://www.honeycomb.io/#website\"},\"datePublished\":\"2018-12-31T15:45:13+00:00\",\"dateModified\":\"2026-09-11T03:20:08+00:00\",\"description\":\"Learn about observability vs. monitoring, OpenTelemetry, and more on the Honeycomb blog.\",\"breadcrumb\":{\"@id\":\"https://www.honeycomb.io/blog#breadcrumb\"},\"inLanguage\":\"en-US\",\"primaryImageOfPage\":{\"@id\":\"https://www.honeycomb.io/blog#primaryimage\"},\"image\":{\"@id\":\"https://www.honeycomb.io/blog#primaryimage\"},\"thumbnailUrl\":\"https://cdn.sanity.io/images/927dxq0h/production/ff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png\"},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https://www.honeycomb.io/blog#primaryimage\",\"url\":\"https://cdn.sanity.io/images/927dxq0h/production/ff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png\",\"contentUrl\":\"https://cdn.sanity.io/images/927dxq0h/production/ff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png\",\"width\":3840,\"height\":2160,\"caption\":\"Observability, Distributed Tracing, and More - Honeycomb Blog\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https://www.honeycomb.io/blog#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https://www.honeycomb.io/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Blog\",\"item\":\"https://www.honeycomb.io/blog\"}]},{\"@type\":\"WebSite\",\"@id\":\"https://www.honeycomb.io/#website\",\"url\":\"https://www.honeycomb.io/\",\"name\":\"Honeycomb\",\"description\":\"Event Driven Debugging\",\"publisher\":{\"@id\":\"https://www.honeycomb.io/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https://www.honeycomb.io/search?searchTerm={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https://www.honeycomb.io/#organization\",\"name\":\"Honeycomb\",\"url\":\"https://www.honeycomb.io/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https://www.honeycomb.io/#/schema/logo/image/\",\"url\":\"https://www.honeycomb.io/api/assets/honeycomb-logo.svg\",\"contentUrl\":\"https://www.honeycomb.io/api/assets/honeycomb-logo.svg\",\"width\":164,\"height\":48,\"caption\":\"Honeycomb\"},\"image\":{\"@id\":\"https://www.honeycomb.io/#/schema/logo/image/\"},\"sameAs\":[\"https://x.com/honeycombio\"]}]}"])</script><script>self.__next_f.push([1,"15:[[\"$\",\"script\",null,{\"type\":\"application/ld+json\",\"dangerouslySetInnerHTML\":{\"__html\":\"$2a\"}}],[\"$\",\"main\",null,{\"className\":\"my-5\",\"children\":[[\"$\",\"div\",null,{\"className\":\"container justify-items-center px-6 pt-5 pb-9 min-[428px]:px-0 md:justify-items-start md:px-12 md:pb-8 lg:px-12 xl:px-0\",\"children\":[\"$\",\"nav\",null,{\"ref\":\"$undefined\",\"aria-label\":\"breadcrumb\",\"children\":[\"$\",\"ol\",null,{\"ref\":\"$undefined\",\"className\":\"text-hc-slate flex flex-wrap items-center gap-1.5 text-xs break-words sm:gap-2.5\",\"children\":[[\"$\",\"$1\",\"0\",{\"children\":[[\"$\",\"li\",null,{\"ref\":\"$undefined\",\"className\":\"inline-flex items-center gap-1.5\",\"children\":[\"$\",\"a\",null,{\"ref\":\"$undefined\",\"className\":\"font-roboto font-medium transition-colors hover:underline\",\"href\":\"/resources\",\"children\":\"Resources\"}]}],[\"$\",\"li\",null,{\"role\":\"presentation\",\"aria-hidden\":\"true\",\"className\":\"[\u0026\u003esvg]:h-3.5 [\u0026\u003esvg]:w-3.5\",\"children\":[\"$\",\"svg\",null,{\"ref\":\"$undefined\",\"xmlns\":\"http://www.w3.org/2000/svg\",\"width\":24,\"height\":24,\"viewBox\":\"0 0 24 24\",\"fill\":\"none\",\"stroke\":\"currentColor\",\"strokeWidth\":2,\"strokeLinecap\":\"round\",\"strokeLinejoin\":\"round\",\"className\":\"lucide lucide-chevron-right\",\"children\":[\"$L2b\",\"$undefined\"]}]}]]}],\"$L2c\"]}]}]}],\"$L2d\",\"$L2e\"]}]]\n18:null\n1d:[[\"$\",\"title\",\"0\",{\"children\":\"Honeycomb Blog\"}],[\"$\",\"meta\",\"1\",{\"name\":\"description\",\"content\":\"honeycomb.io is an observability platform designed to help engineering teams find and solve complex issues in their cloud applications\"}],[\"$\",\"link\",\"2\",{\"rel\":\"canonical\",\"href\":\"https://www.honeycomb.io/blog\"}],[\"$\",\"link\",\"3\",{\"rel\":\"icon\",\"href\":\"/favicon.ico?favicon.07o~09ebmt8eg.ico\",\"sizes\":\"48x48\",\"type\":\"image/x-icon\"}],[\"$\",\"link\",\"4\",{\"rel\":\"icon\",\"href\":\"/favicon-16x16.png\",\"sizes\":\"16x16\",\"type\":\"image/png\"}],[\"$\",\"link\",\"5\",{\"rel\":\"icon\",\"href\":\"/favicon-32x32.png\",\"sizes\":\"32x32\",\"type\":\"image/png\"}],[\"$\",\"$L2f\",\"6\",{}]]\n"])</script><script>self.__next_f.push([1,"30:I[115353,[\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"/_next/static/chunks/019vi3l~x0zoc.js\",\"/_next/static/chunks/0ku~nn_l8-fol.js\",\"/_next/static/chunks/039u5_5hlemld.js\",\"/_next/static/chunks/189hrhe.fk4af.js\",\"/_next/static/chunks/0oz-qxk30w~qw.js\",\"/_next/static/chunks/0vx_phl8cla2s.js\",\"/_next/static/chunks/0xywjwd04osrr.js\",\"/_next/static/chunks/0t1~yeqvn891r.js\",\"/_next/static/chunks/0ks4m351.jbv2.js\",\"/_next/static/chunks/01gy5f4286e6a.js\",\"/_next/static/chunks/09mg9tc2w3ag6.js\",\"/_next/static/chunks/0~-xo~ilf3e0r.js\"],\"default\"]\n31:I[995163,[\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"/_next/static/chunks/019vi3l~x0zoc.js\",\"/_next/static/chunks/0ku~nn_l8-fol.js\",\"/_next/static/chunks/039u5_5hlemld.js\",\"/_next/static/chunks/189hrhe.fk4af.js\",\"/_next/static/chunks/0oz-qxk30w~qw.js\",\"/_next/static/chunks/0vx_phl8cla2s.js\",\"/_next/static/chunks/0xywjwd04osrr.js\",\"/_next/static/chunks/0t1~yeqvn891r.js\",\"/_next/static/chunks/0ks4m351.jbv2.js\",\"/_next/static/chunks/01gy5f4286e6a.js\",\"/_next/static/chunks/09mg9tc2w3ag6.js\",\"/_next/static/chunks/0~-xo~ilf3e0r.js\"],\"Image\"]\n33:I[604349,[\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"/_next/static/chunks/019vi3l~x0zoc.js\",\"/_next/static/chunks/0ku~nn_l8-fol.js\",\"/_next/static/chunks/039u5_5hlemld.js\",\"/_next/static/chunks/189hrhe.fk4af.js\",\"/_next/static/chunks/0oz-qxk30w~qw.js\",\"/_next/static/chunks/0vx_phl8cla2s.js\",\"/_next/static/chunks/0xywjwd04osrr.js\",\"/_next/static/chunks/0t1~yeqvn891r.js\",\"/_next/static/chunks/0ks4m351.jbv2.js\",\"/_next/static/chunks/01gy5f4286e6a.js\",\"/_next/static/chunks/09mg9tc2w3ag6.js\",\"/_next/static/chunks/0~-xo~ilf3e0r.js\"],\"BlogPostList\"]\n"])</script><script>self.__next_f.push([1,"25:[\"$\",\"div\",\"a6c0cb4a869f\",{\"className\":\"flex flex-col gap-3\",\"children\":[[\"$\",\"span\",null,{\"className\":\"text-base leading-[150%] font-semibold\",\"children\":\"Solutions\"}],[\"$\",\"ul\",null,{\"children\":[[\"$\",\"li\",\"8f77d4ed6602\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/why-honeycomb\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"8f77d4ed6602\",\"_type\":\"link\",\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Why Honeycomb\",\"$undefined\"]}]}],[\"$\",\"li\",\"7fb03607561c\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/why-honeycomb/enterprise\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"7fb03607561c\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Enterprise\",\"$undefined\"]}]}],[\"$\",\"li\",\"d0d6163b27ff\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/technologies/ai-agents\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"d0d6163b27ff\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"AI Agents\",\"$undefined\"]}]}],[\"$\",\"li\",\"2b90f65f46e6\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/technologies/aws\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"2b90f65f46e6\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Amazon Web Services\",\"$undefined\"]}]}],[\"$\",\"li\",\"c3dff0996d2b\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/technologies/microsoft-azure\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"c3dff0996d2b\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Microsoft Azure\",\"$undefined\"]}]}],[\"$\",\"li\",\"d0caa1e4eb66\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/technologies/kubernetes\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"d0caa1e4eb66\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Kubernetes\",\"$undefined\"]}]}],[\"$\",\"li\",\"9ceaefb31039\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/technologies/google-cloud\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"9ceaefb31039\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Google Cloud\",\"$undefined\"]}]}]]}]]}]\n"])</script><script>self.__next_f.push([1,"26:[\"$\",\"div\",\"617021cf9ee2\",{\"className\":\"flex flex-col gap-3\",\"children\":[[\"$\",\"span\",null,{\"className\":\"text-base leading-[150%] font-semibold\",\"children\":\"Company\"}],[\"$\",\"ul\",null,{\"children\":[[\"$\",\"li\",\"26df551d2e36\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/about\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"26df551d2e36\",\"_type\":\"link\",\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"About Us\",\"$undefined\"]}]}],[\"$\",\"li\",\"cd5a23b41429\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/about/team\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"cd5a23b41429\",\"_type\":\"link\",\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Team\",\"$undefined\"]}]}],[\"$\",\"li\",\"9e8d0ae5c80c\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/careers\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"9e8d0ae5c80c\",\"_type\":\"link\",\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Careers\",\"$undefined\"]}]}],[\"$\",\"li\",\"21e1fb267d5e\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/news\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"21e1fb267d5e\",\"_type\":\"link\",\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"News\",\"$undefined\"]}]}],[\"$\",\"li\",\"bb5ab8caffa9\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/events\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"bb5ab8caffa9\",\"_type\":\"link\",\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Events\",\"$undefined\"]}]}],[\"$\",\"li\",\"f8a10f88008f\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/why-honeycomb/customers\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"f8a10f88008f\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Customers\",\"$undefined\"]}]}],[\"$\",\"li\",\"bf0deb38bf75\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/partners\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"bf0deb38bf75\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Partners\",\"$undefined\"]}]}],[\"$\",\"li\",\"15f6dabb07e6\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"https://docs.honeycomb.io/security-compliance\",\"target\":\"_blank\",\"rel\":\"noopener noreferrer\",\"onClick\":\"$undefined\",\"_key\":\"15f6dabb07e6\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Security\",\"$undefined\"]}]}],[\"$\",\"li\",\"85057eb711e5\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/support\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"85057eb711e5\",\"_type\":\"link\",\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Support\",\"$undefined\"]}]}],[\"$\",\"li\",\"e94d32b2d070\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"https://status.honeycomb.io/\",\"target\":\"_blank\",\"rel\":\"noopener noreferrer\",\"onClick\":\"$undefined\",\"_key\":\"e94d32b2d070\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Status\",\"$undefined\"]}]}],[\"$\",\"li\",\"0ea03725759b\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"https://changelog.honeycomb.io/\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"0ea03725759b\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Changelog\",\"$undefined\"]}]}]]}]]}]\n"])</script><script>self.__next_f.push([1,"27:[\"$\",\"div\",\"84f2e7d94ff8\",{\"className\":\"flex flex-col gap-3\",\"children\":[[\"$\",\"span\",null,{\"className\":\"text-base leading-[150%] font-semibold\",\"children\":\"Resources\"}],[\"$\",\"ul\",null,{\"children\":[[\"$\",\"li\",\"671f18da9b3f\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/blog\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"671f18da9b3f\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Blog\",\"$undefined\"]}]}],[\"$\",\"li\",\"92ccb060bb8f\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"https://docs.honeycomb.io\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"92ccb060bb8f\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Documentation\",\"$undefined\"]}]}],[\"$\",\"li\",\"db87d691804a\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/resources/getting-started\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"db87d691804a\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Getting Started\",\"$undefined\"]}]}],[\"$\",\"li\",\"ba793c2d2aec\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/resources/case-studies\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"ba793c2d2aec\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Case Studies\",\"$undefined\"]}]}],[\"$\",\"li\",\"b6324b7fa3ad\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/why-honeycomb/comparisons\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"b6324b7fa3ad\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Comparisons\",\"$undefined\"]}]}],[\"$\",\"li\",\"8dacd4366e92\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/resources/webinars\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"8dacd4366e92\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"Webinars\",\"$undefined\"]}]}],[\"$\",\"li\",\"2e34173dd022\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/blog/what-is-observability-key-components-best-practices\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"2e34173dd022\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"What Is Observability?\",\"$undefined\"]}]}],[\"$\",\"li\",\"52309d8a3d42\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/resources/getting-started/what-is-ai-observability\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"52309d8a3d42\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"What Is AI Observability?\",\"$undefined\"]}]}],[\"$\",\"li\",\"a1a79caf1ea6\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/resources/getting-started/what-is-llm-observability\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"a1a79caf1ea6\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"What Is LLM Observability?\",\"$undefined\"]}]}],[\"$\",\"li\",\"9cf8c6d40ac4\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/resources/getting-started/application-performance-monitoring-vs-observability\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"9cf8c6d40ac4\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"APM vs Observability\",\"$undefined\"]}]}],[\"$\",\"li\",\"b20174d4157b\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/resources/getting-started/getting-started-with-opentelemetry\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"b20174d4157b\",\"_type\":\"link\",\"enableDownloadFunctionality\":false,\"className\":\"text-sm leading-[20px] tracking-[0.02em]\",\"children\":[\"OpenTelemetry Guide\",\"$undefined\"]}]}]]}]]}]\n"])</script><script>self.__next_f.push([1,"28:[\"$\",\"div\",null,{\"className\":\"flex flex-col items-baseline gap-2 text-xs leading-[150%] tracking-[0] lg:flex-row lg:gap-3\",\"children\":[[\"$\",\"span\",null,{\"children\":[\"© \",2026,\" \",\"Hound Technology, Inc.\"]}],[\"$\",\"ul\",null,{\"className\":\"flex flex-row gap-3\",\"children\":[[[\"$\",\"li\",\"4042940388e7\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/terms\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"4042940388e7\",\"_type\":\"link\",\"className\":\"text-hc-cobalt text-xs leading-[20px] tracking-[0.02em] underline\",\"children\":[\"Terms of Service\",\"$undefined\"]}]}],[\"$\",\"li\",\"df3d0de1abf9\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/acceptable-use-policy\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"df3d0de1abf9\",\"_type\":\"link\",\"className\":\"text-hc-cobalt text-xs leading-[20px] tracking-[0.02em] underline\",\"children\":[\"Acceptable Use Policy\",\"$undefined\"]}]}],[\"$\",\"li\",\"de1418f17f9f\",{\"className\":\"pb-1\",\"children\":[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/privacy\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"de1418f17f9f\",\"_type\":\"link\",\"className\":\"text-hc-cobalt text-xs leading-[20px] tracking-[0.02em] underline\",\"children\":[\"Privacy Notice\",\"$undefined\"]}]}]],[\"$\",\"li\",null,{\"className\":\"pb-1\",\"children\":[\"$\",\"a\",null,{\"href\":\"#\",\"className\":\"text-hc-cobalt cky-banner-element text-xs leading-[20px] tracking-[0.02em] underline\",\"children\":\"Your Privacy Choices\"}]}]]}]]}]\n"])</script><script>self.__next_f.push([1,"29:[\"$\",\"div\",null,{\"className\":\"order-1 flex w-full flex-grow flex-col items-center justify-between self-stretch lg:order-2 lg:max-w-[295px]\",\"children\":[[\"$\",\"div\",null,{\"id\":\"footer-newsletter\",\"className\":\"flex-1 lg:px-4\",\"children\":[[\"$\",\"p\",null,{\"className\":\"font-roboto pb-[15px] text-center text-lg leading-[22px] font-bold tracking-[0.02em]\",\"children\":\"Sign up for updates from Honeycomb\"}],[\"$\",\"$L30\",null,{}]]}],[\"$\",\"div\",null,{\"className\":\"mt-auto pt-4\",\"children\":[\"$\",\"div\",null,{\"className\":\"mt-4 flex gap-4\",\"children\":[[\"$\",\"a\",\"c9875f6cb729\",{\"href\":\"https://bsky.app/profile/honeycomb.io\",\"target\":\"_blank\",\"rel\":\"noopener noreferrer\",\"aria-label\":\"Bluesky\",\"className\":\"transition-opacity hover:opacity-80\",\"children\":[\"$\",\"div\",null,{\"className\":\"border-hc-slate flex size-9 items-center justify-center rounded-full border-[2px]\",\"children\":[\"$\",\"$L31\",null,{\"src\":\"https://cdn.sanity.io/images/927dxq0h/production/b791a32106224d6a8c17908d9e10a1098ecd033e-600x530.svg\",\"alt\":\"Bluesky\",\"width\":600,\"height\":530,\"className\":\"h-3.5 w-3.5 object-contain\"}]}]}],[\"$\",\"a\",\"b33a8c9306c9\",{\"href\":\"https://www.linkedin.com/company/honeycomb.io\",\"target\":\"_blank\",\"rel\":\"noopener noreferrer\",\"aria-label\":\"linkedin\",\"className\":\"transition-opacity hover:opacity-80\",\"children\":[\"$\",\"div\",null,{\"className\":\"border-hc-slate flex size-9 items-center justify-center rounded-full border-[2px]\",\"children\":[\"$\",\"$L31\",null,{\"src\":\"https://cdn.sanity.io/images/927dxq0h/production/2129b6ff6ad7d0a679bcde4a6d1f3498d2c5c2c3-36x36.svg\",\"alt\":\"Linkedin\",\"width\":36,\"height\":36,\"className\":\"h-3.5 w-3.5 object-contain\"}]}]}],[\"$\",\"a\",\"abce4ce93e4f\",{\"href\":\"https://www.youtube.com/channel/UCty8KGQ3oAP0MQQmLIv7k0Q\",\"target\":\"_blank\",\"rel\":\"noopener noreferrer\",\"aria-label\":\"youtube\",\"className\":\"transition-opacity hover:opacity-80\",\"children\":[\"$\",\"div\",null,{\"className\":\"border-hc-slate flex size-9 items-center justify-center rounded-full border-[2px]\",\"children\":[\"$\",\"$L31\",null,{\"src\":\"https://cdn.sanity.io/images/927dxq0h/production/6949a9f5fcdca86c2505079300c317729031c030-256x256.svg\",\"alt\":\"YouTube\",\"width\":256,\"height\":256,\"className\":\"h-3.5 w-3.5 object-contain\"}]}]}],[\"$\",\"a\",\"1707e02c4aba\",{\"href\":\"https://www.honeycomb.io/rss/blog.xml\",\"target\":\"_blank\",\"rel\":\"noopener noreferrer\",\"aria-label\":\"RSS\",\"className\":\"transition-opacity hover:opacity-80\",\"children\":[\"$\",\"div\",null,{\"className\":\"border-hc-slate flex size-9 items-center justify-center rounded-full border-[2px]\",\"children\":[\"$\",\"$L31\",null,{\"src\":\"https://cdn.sanity.io/images/927dxq0h/production/c0e681e6a520b9ddc9b0beb072859fd9b6e7e20e-800x800.svg\",\"alt\":\"RSS\",\"width\":800,\"height\":800,\"className\":\"h-3.5 w-3.5 object-contain\"}]}]}]]}]}]]}]\n"])</script><script>self.__next_f.push([1,"2b:[\"$\",\"path\",\"mthhwq\",{\"d\":\"m9 18 6-6-6-6\"}]\n2c:[\"$\",\"$1\",\"1\",{\"children\":[[\"$\",\"li\",null,{\"ref\":\"$undefined\",\"className\":\"inline-flex items-center gap-1.5\",\"children\":[\"$\",\"a\",null,{\"ref\":\"$undefined\",\"className\":\"font-roboto font-medium transition-colors hover:underline\",\"href\":\"/blog\",\"children\":\"Blog\"}]}],false]}]\n"])</script><script>self.__next_f.push([1,"2d:[\"$\",\"div\",null,{\"className\":\"container mb-8 flex flex-col items-center gap-6 px-6 min-[428px]:px-0 md:px-12 lg:flex-row lg:items-stretch xl:px-0\",\"children\":[[\"$\",\"div\",null,{\"className\":\"flex grow flex-col gap-5\",\"children\":[[\"$\",\"div\",null,{\"className\":\"flex flex-col items-center gap-[10px] md:items-baseline md:px-6\",\"children\":[[[\"$\",\"$L24\",\"Blog\",{\"href\":\"blog\",\"children\":[\"$\",\"div\",null,{\"className\":\"font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate\",\"children\":\"Blog\"}]}]],[\"$\",\"h1\",null,{\"className\":\"text-h1 text-hc-slate text-balance\",\"children\":\"Honeycomb Blog\"}]]}],[\"$\",\"div\",null,{\"className\":\"relative flex w-full grow flex-col overflow-hidden rounded-[20px] antialiased md:min-h-[436px] bg-hc-gray-50\",\"children\":[[\"$\",\"$L24\",null,{\"href\":\"/blog/ai-norms-values-part-3-things-we-hold-true\",\"title\":\"AI Norms \u0026 Values, Part 3 of 3: Things We Hold True\",\"children\":[\"$\",\"div\",null,{\"className\":\"relative max-w-full\",\"children\":[\"$\",\"$L31\",null,{\"priority\":true,\"fetchPriority\":\"high\",\"loading\":\"eager\",\"sizes\":\"(max-width: 1024px) 100vw, 50vw\",\"src\":\"https://cdn.sanity.io/images/927dxq0h/production/ff1c82783367c2a69702c80f1248dc907313059e-3840x2160.png\",\"alt\":\"AI Norms \u0026 Values, Part 3 of 3: Things We Hold True\",\"width\":3840,\"height\":2160,\"className\":\"w-full max-w-none rounded-t-[20px] object-cover max-h-[402px]\"}]}]}],[\"$\",\"div\",null,{\"className\":\"flex flex-col p-5 gap-10 max-xl:flex-1 md:h-[304px] xl:justify-between\",\"children\":[[\"$\",\"div\",null,{\"className\":\"flex flex-col gap-4\",\"children\":[[\"$\",\"div\",null,{\"className\":\"flex items-center gap-3\",\"children\":[[\"$\",\"span\",null,{\"className\":\"text-hc-slate/70 font-roboto text-xs/relaxed font-medium\",\"children\":[\"$\",\"span\",null,{\"children\":\"September 9, 2026\"}]}],[\"$\",\"span\",null,{\"className\":\"font-extralight opacity-30 block\",\"children\":\" | \"}],[\"$\",\"div\",null,{\"className\":\"flex items-center gap-[6px]\",\"children\":[[\"$\",\"$L31\",null,{\"src\":\"https://cdn.sanity.io/images/927dxq0h/production/6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png?w=80\u0026h=80\",\"width\":80,\"height\":80,\"alt\":\"Charity Majors\",\"className\":\"bg-hc-gray-50 size-6 rounded-full\"}],[\"$\",\"p\",null,{\"className\":\"text-hc-slate text-sm\",\"children\":[\"$\",\"$L24\",null,{\"href\":\"/author/charity\",\"className\":\"text-hc-cobalt underline hover:no-underline\",\"children\":\"Charity Majors\"}]}]]}]]}],[\"$\",\"$L24\",null,{\"href\":\"/blog/ai-norms-values-part-3-things-we-hold-true\",\"className\":\"flex flex-col gap-[10px]\",\"children\":[[\"$\",\"h3\",null,{\"className\":\"font-poppins line-clamp-2 text-2xl/tight font-medium md:text-[36px] md:leading-11\",\"children\":\"AI Norms \u0026 Values, Part 3 of 3: Things We Hold True\"}],[\"$\",\"p\",null,{\"className\":\"line-clamp-5 text-sm/normal md:line-clamp-3 md:text-base\",\"children\":\"The final part of Honeycomb's AI Norms \u0026 Values series: the principles the company holds true about AI as a tool, ownership of work, and rising standards; how it actually uses AI day to day; usage patterns for respecting each other's time; and where it stands on AI's ethical externalities like energy use, IP, bias, and wages.\"}]]}]]}],[\"$\",\"div\",null,{\"className\":\"flex flex-wrap gap-3\",\"children\":[[\"$\",\"$L24\",\"AI \u0026 LLMs,AI \u0026 LLMs\",{\"href\":\"/blog/category/ai-llms\",\"children\":[\"$\",\"div\",null,{\"className\":\"font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate\",\"children\":\"AI \u0026 LLMs\"}]}],[\"$\",\"$L24\",\"Culture,Culture\",{\"href\":\"/blog/category/culture\",\"children\":[\"$\",\"div\",null,{\"className\":\"font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate\",\"children\":\"Culture\"}]}]]}]]}]]}]]}],\"$L32\"]}]\n"])</script><script>self.__next_f.push([1,"34:T51c0,"])</script><script>self.__next_f.push([1,"Welcome to the third and final part of our series on AI norms and values. Parts of this doc were extracted and published separately on substack; as a whole, they describe the principles we hold pertaining to technology and AI, and the ethical commitments we make to each other and our customers.\n\nWe set out to write about AI, and ended up writing about ourselves. These documents are not meant to be aspirational ones; they are derived from how we do our work every day in honeycomb.\n\nThis concludes the series, but not the discussion. Dr. Cat Hicks, author of The Psychology of Software Teams (out last month!), has contributed greatly to the industry's research and reasoning around how to build an excellent, high-performing, and deeply humane environment. Dr. Hicks and I will be continuing the conversation on our respective blogs over the next few weeks. We will also do a new episode of Leading With Observability and an open invite webinar where you can bring us your gnarliest questions about how to be a human in the AI era.\n\nThis is a weird time to be in computing. So much has changed, so fast. As a technologist, it's hard not to be dazzled by the possibilities, the speed, the range. As a human being, it's hard not to be tired.\n\nOn one hand, AI is just technology. On the other hand, this technology is different. Instead of the brute force of automation, AI presents an uncanny valley, a smooth facsimile of cooperation and cheer. I think this accounts for the creeping suspicion that we are not being treated like real people. But AI did not invent being rude, disrespectful, or careless with other people's time. For every problem amplified by AI, there are solutions AI can accelerate.\n\nAI is not the point. The point is us.\n\nTools are just tools. An email can bring people together or tear them apart. AI can be used to avoid other people or to build and enrich communities. The difference consists of intent, understanding, consent, and good fit, not technology.\n\nWe are a company founded on values and first principles, and the stubborn conviction that technology can be so much better than people are used to. We're still doing that… just with AI.\n\nThings we hold true\n\nAI is a tool\n\nAI is a powerful tool, but it is just a tool. We do not serve our tools. Our tools serve us.\n\nYou own your work\n\nI am not a “human in the loop,” I am the owner of the loop. It's my fucking loop. I am responsible for the quality of my work and the integrity of my working process, and so are you. “Claude did it” or “Claude said” is not an excuse.\n\nThe bar is going up\n\nEvery technological transition resets the baseline for performance—not by mandate, but by what becomes possible. This is true for companies, products, teams, tools, and people. What was excellent five years ago is table stakes today.\n\nWe welcome this. The nature of technology is that it always catches up. Which is why the nature of technologists is, we stay ahead.\n\nThe outcome is what matters\n\nA higher bar means better outcomes. Often this is about moving faster, but not always, and never exclusively. What outcome are we aiming to achieve? What would ‘better’ look like? What would ‘great’ look like? What is possible today that wasn't possible last year?\n\nFor outcomes to matter, we must embrace measuring ourselves. Everything is an experiment, but an experiment that doesn't get tracked is wasting everyone's time.\n\nHow we use AI\n\nA shortcut or a deep dive\n\nYou can use AI to help you do something fast and half-assed, or you can use AI to help you think harder, build with more rigor, communicate with more depth.\n\nThere is a time and a place for both, but the two are not interchangeable. Know the difference.\n\nAI for the role, AI for the self\n\nYou may use AI at work in ways that are prescribed by the company to do your job, and we owe you enablement and support for those.\n\nYou may also use AI of your own volition for calendar support or editing, as a tutor, rubber ducky, etc. This is much more personal and subjective, and no one is required to do it, but opting out of using AI does not exempt us from the higher bar.\n\nMore AI is not always better\n\nAI is not the right tool for every use case, and more AI is not always better. If AI is causing friction and frustration in a given setting, talk with your team about how to reduce or eliminate that frustration. Make the tools serve you.\n\nMaster the tools before ruling them out\n\nHowever, be careful to make this decision from a place of fluency, not ignorance, and revisit your decision occasionally. It's easy to blame the tools for the frustration of learning.\n\nUsage patterns\n\nAI should make our signal-to-noise ratio better, not worse. To do this, we need three things: self-awareness, respect for each other's time, and open dialogue.\n\nAddress the envelope\n\nAny time you send someone an artifact, tell them what it is, why you're sending it, and what you hope to receive from them, and any other useful context you can think of.\n\nThis is the “envelope” of your message. Addressing the envelope does a couple vital jobs:\n\nIt cultivates self-awareness. When you drop a large artifact on someone and walk away with no comment, it's easy to breeze past the fact that you may have just dumped a ton of work on someone. This surfaces as frustration with AI because AI has newly made this easier, but AI is not at fault. You own your work. When you describe your request in detail, it forces you to think through what you are asking them to do and what you really need from them.\n\nIt opens a conversation. When someone drops a link on you, it can feel like a demand, but it's not. We don't assign work at Honeycomb, we ask nicely, and if someone has concerns or objections, we talk about them. This should always be a conversation. “This is what I have, this is what I need. Are you the right person? Is this the right time? What questions do you have?” Ask. If someone sends you an artifact or a request and you feel a pit in your stomach, pay attention to it. What is it you fear?\n\nRespect other people's time and attention\n\nNever send someone an AI-generated doc unless you have first read it yourself, every word. If it's not worth your time and attention, how can you possibly say it is worth someone else's? This may be a low bar, but it's an important one.\n\nTo respect other people's time and attention, make the smallest necessary ask. You wouldn't ask someone to read a whole book when you need them to read page 152. Specificity is kindness, boundaries are respect.\n\nFour types of communication\n\nThis four-point scale can be used to plot whether the value of any communication is primarily personal or functional. On the left, the value is in that it comes from a specific person who thought it or felt it. On the right, the value comes primarily from the ideas or artifact itself.\n\nPersonal to the left, functional to the right. Like this:\n\n1: Personal opinions\n\nThe value of this communication is that a specific person thought it or felt it, or that it exists in the context of a relationship. You aren’t upset when a stranger doesn’t wish you happy birthday, but you might be upset if your partner doesn’t. When an expert in your field compliments your work, it means a lot because you respect them.\n\nUsing AI in this context tends to destroy trust instead of building it, unless AI has explicitly been welcomed in to the relationship. (“Wow, my manager even used AI to tell me happy birthday? What an asshole.”)\n\n2: Professional opinions\n\nMost professional communication goes here. Some of its value comes from you being the person who thought it or felt it, but not all—the quality, relevance, skill and fit of the message also matter.\n\nIf you gave advice, how good was it?\n\nIf you wrote a review, was it clear, useful and fair, and was the content not a surprise?\n\nIf you shared your opinion, how expert, well-crafted and timely was it?\n\nIt’s fine to use AI and other tools to arrange, structure or enhance these thoughts, but they should remain recognizably yours. If someone wants your opinion, or asks you to give a talk, they want your opinion, in your voice. When your voice is lost in the response, it may register as a breach of trust.\n\n3: Prose artifacts\n\nOn the other hand, there are artifacts. An artifact’s value does not derive from being something a particular person thought or felt, it comes from the ideas themselves. Artifacts include docs like PRDs, architecture diagrams and decisions, strategy docs, meeting notes, and much more. Sometimes code fits in this category too.\n\nArtifacts get reviewed by reading, and validated by tools like comments and discussion threads. An artifact usually has an owner, but our goal is to collaboratively make the ideas better, regardless of ownership or authorship.\n\n4: Software artifacts\n\nFormal, structured information like software can be verified automatedly in ways that written and spoken languages cannot. Wherever we can defer to the machines for testing, we probably should; validating logic at scale is hardly where humanity shines.\n\nHowever, merging source code without reading it is a badge of honor that must be earned. Today, most software at Honeycomb continues to be validated using a blend of techniques from 3 and 4.\n\nAsk for what you want\n\nWhile it may not always be entirely clear whether a given piece of feedback is more subjective or objective, it is usually extremely clear to people what they want. When they want someone’s personal, subjective opinion vs when they are reaching for “the best idea.”\n\nIf you know what you want: ask for it. If you aren’t sure what someone wants you to give them: ask.\n\nHow to handle mismatched expectations\n\nAn enormous amount of frustration is being generated right now by mismatched expectations and uncertainty. It is tempting to blame AI and start micromanaging and issuing rules over who can use AI in what ways, in which contexts.\n\nBut we hire adults. That is not our way. AI is just a tool, and our tools serve us.\n\nThe “reasonable effort” example\n\nIt would be incredibly rude for me to spend five minutes generating a piece of code and then drop it in someone’s lap, expecting them to spend two or three hours reviewing it.\n\nBut what if I spent five minutes generating a piece of code, and sent it to someone saying, “Hi, I just spent five minutes on this, and I was wondering if you were available to spend no more than five min giving me a gut check on it. Am I headed in the right direction?”\n\nThat seems fine, right?\n\nThe opinion example\n\nOr what if I ask someone for feedback on my written plan, and they respond by generating a variation of my plan with Claude, and sending back an entirely new artifact. This would be frustrating if I wanted their opinion, because now I have a whole new plan to digest and I still am not clear on what they think. What should I do?\n\nWell, you could engage with the content in a number of ways. You could ask to see their prompt, or re-state your request with more specificity, or you could waste a lot of time trying to tease out what they changed on purpose and what came along for the ride.\n\nBut this is a pretty basic case of missed signals. The better strategy is probably not to engage with the content at all, and deal with the mismatched expectations instead. Politely tell them what you actually need, and ask if they can give it.\n\nThe performance review example\n\nOne of the trickiest things to navigate is when you get peer feedback or a performance review that smells AI-generated, and you aren’t sure how to value it. Does it mean anything? Which parts came from them, and which were filled in by the AI? Did they even read it before they gave it to you? Will they get mad if you ask?\n\nThis can be deeply corrosive to trust, so it’s critical that we make space for these conversations. This cannot be a taboo topic. Managers, bring this up with your reports. Talk about your process. Make it safe to ask questions and venture feedback.\n\nWe actively encourage managers to use AI to build systems that help them be better managers—recording how they show up in meetings, coaching them on hard conversations, tracking their team members’ achievements.\n\nThere are countless valuable ways to use these tools. But they do not, cannot, must not supplant or replace the manager’s judgment. There is no world in which a manager can push a button and generate a performance review, skim it and hand it to their report. That is unacceptable. If your job can be automated away so easily, what do we need you for?\n\nWriting is thinking on paper, as William Zinsser said. While there are many ways that using AI can save us time and energy, the way we train the LLMs between our ears is by doing things, trying things, and yes, writing things. That takes work. Make sure you are doing the work you need to do to develop the good judgment we rely on you to have. Never shortchange your direct report or yourself by outsourcing that work to the machines.\n\nGive feedback in your voice\n\nAnd do your best, managers, to give feedback in your voice. People are developing a sixth sense for AI-generated text, and many people just stop reading. (Guilty.) It can feel like a real betrayal when you expect personal communication and sense you aren’t getting it.\n\nBut—and this is also important—it does not have to feel like a betrayal. It does not have to be a betrayal. The key is context, understanding, and trust. A manager who uses English as a second language might remind their reports that they use Claude as a courtesy gloss. A manager with strong AI-first systems could talk to her reports about her process and see if they buy into an experiment with auto-generated reviews.\n\nTeams legitimately vary in their tolerance and enthusiasm for this, but there are options. With people and communication and ingenuity, there always are.\n\nExecutive functioning is more important than ever\n\nSo much of this comes down to expectations and being explicit: Here is what I have, here is what I need. Are you available for that?\n\nI have had and heard about so many of these exchanges by now. I have felt the same seething frustration at having my time wasted. But when I track down the person on the other side, it’s invariably one of two things: either they weren’t aware how much time consuming, frustrating work they were generating for me, or they were causing the frustration in an attempt to be helpful.\n\nThe number of times they were trying to push work off their plate onto mine, or force me to spend hours cleaning up after their mess is an absolute zero.\n\nWe do not work with assholes, y’all. But we also do not work with mindreaders. We are used to taking so much for granted, and now we can’t.\n\nThe provenance of a document is always relevant\n\nAsking about how a doc was written or generated is hard when there’s a power dynamic, so managers have an extra dollop of responsibility. But no one is off the hook. No one gets in trouble for asking questions about whether something was AI-generated or human-made—it’s an important and relevant piece of context. And everyone should cheerfully disclose when asked.\n\nWhich brings us to one final note of caution.\n\nIf you feel uncomfortable about how you made the artifact, and you don’t want the recipient to know how you made it…\n\nThat is an important signal. I suggest you honor it.\n\nEthical issues we have a stance on\n\nThere are two specific mistakes we are trying to avoid in writing this section.\n\nWe don't want to write something glossy and aspirational about how much we “Care About Ethics™” with no evidence to back it up, but we also don't want to make commitments we can't keep. Instead, we will affirm some of the principles that have gotten us this far, and describe how they have guided our decisions in the past.\n\nExternalities and harms done by AI\n\nThere are a number of troubling externalities associated with AI:\n\nEnergy usage/carbon footprint\n\nIP theft\n\nPrivacy\n\nBias\n\nJob cuts, wage cuts, and disinvestment in the next generation\n\nWe are a for-profit company, and our first priority is to build a successful, sustainable business. When we succeed at business, we earn the right to think longer term and make bigger investments.\n\nOur vendor review process includes an ethics review. We preferentially give our money to vendors that share our values or are the lesser of two evils. We will continue to do so.\n\nOn energy and resource usage\n\nWe frankly have no idea what to do about this, as a consumer (not producer) of foundational AI models. Which is unfortunate, since it is probably the most alarming externality. We will re-examine in six months.\n\nOn intellectual property\n\nThis is a thorny one. It appears that model providers have knowingly violated copyright law for years with no brakes and no consequences, outcompeting (and dooming) competitors who followed the law. Was it illegal? Sure seemed that way. But the only honest answer is we don't know, and we won't know, until we learn how the Supreme Court will interpret the law.\n\nBut was it right? Absolutely not. It was settled law at the time, and they systematically broke it. To retroactively bless this behavior sets a concerning precedent for businesses like ours who believe in fair competition and following the law.\n\nEthics, morality, and the law have always been different things. As model users, we are aligned with the letter and spirit of the laws. But we benefit from the unsavory acquisition of training data, and we know it, which incurs a moral debt.\n\nAt a minimum, we should be diligent in citing references, assigning credit, and compensating contributors whose work we use in commercial activity, above and beyond what is legally required of us. All of which we have a track record of doing, and will continue to do.\n\nOn bias and privacy\n\n“You own your work” means that any bias introduced by AI is your problem. Be mindful of where bias tends to creep in, and guard against it. Verify results where possible. Welcome feedback warmly, correct, and move on.\n\nIt is not clear how we can contribute to privacy efforts.\n\nOn wages and disinvestment\n\nWe have never been a company that believes in squeezing the most work out of people for the least money. We compensate as well as we are able, and we take fair pay very seriously.\n\nWe have always felt a responsibility to invest in the people who work here, just as they invest in us. This includes hiring and training entry level workers when we are able to do so.\n\nMentoring and learning are at the heart of our job ladders in R\u0026D, and the SDR pipeline serves a similar purpose on the GTM side. We have supported a number of employees in retraining for different roles. Personal development budgets are widely used. We audit our salary bands for bias and equity, and practice transparency around pay bands in job postings.\n\nWe have learned the hard way that it does not serve anyone for us to hire junior employees when we aren't ready to support them, but when we can support them, we have and we will.\n\nOn activism vs working agreements\n\nThese ethical stances may seem relatively modest, and they are. These are working agreements for doing business, not ethical aspirations or activist goals.\n\nThere is a place for activism. There is a place for outright advocacy. At a time like this, we would all be well served to consider our ethical stances and how to act on them. Business may not be the ideal vehicle for activism, but activism is vital and necessary. People who take action in support of their beliefs (generally within the confines of the law) will not be retaliated against at Honeycomb.\n\nWe are here to build a business. There is virtue in this, even if it is not explicitly ideological.\n\nClosing statement\n\nThe workplace is one of the last remaining places where people of widely varying backgrounds and beliefs all come together to achieve something greater than themselves. We think this is precious. We think this is worth protecting.\n\nWe believe that treating people well is not at odds with the profit motive. We believe that people who are happy, healthy, well supported, and creatively engaged can do better work.\n\nWe believe that rigorous use of AI helps a company like ours accelerate development, delight customers, and go head to head with competitors with vastly more resources. We believe that using AI is not a replacement for skill and craft, but an amplification.\n\nWe believe that customers who are valued, respected, and listened to are happier, more loyal customers. Happy customers are more invested in giving us the feedback we need to build a better product. We believe in building mutually beneficial relationships and positive feedback loops that leave both sides better off.\n\nWe do these things, not as a sacrifice or a distraction from our core mission, but in service of it."])</script><script>self.__next_f.push([1,"35:T51c0,"])</script><script>self.__next_f.push([1,"Welcome to the third and final part of our series on AI norms and values. Parts of this doc were extracted and published separately on substack; as a whole, they describe the principles we hold pertaining to technology and AI, and the ethical commitments we make to each other and our customers.\n\nWe set out to write about AI, and ended up writing about ourselves. These documents are not meant to be aspirational ones; they are derived from how we do our work every day in honeycomb.\n\nThis concludes the series, but not the discussion. Dr. Cat Hicks, author of The Psychology of Software Teams (out last month!), has contributed greatly to the industry's research and reasoning around how to build an excellent, high-performing, and deeply humane environment. Dr. Hicks and I will be continuing the conversation on our respective blogs over the next few weeks. We will also do a new episode of Leading With Observability and an open invite webinar where you can bring us your gnarliest questions about how to be a human in the AI era.\n\nThis is a weird time to be in computing. So much has changed, so fast. As a technologist, it's hard not to be dazzled by the possibilities, the speed, the range. As a human being, it's hard not to be tired.\n\nOn one hand, AI is just technology. On the other hand, this technology is different. Instead of the brute force of automation, AI presents an uncanny valley, a smooth facsimile of cooperation and cheer. I think this accounts for the creeping suspicion that we are not being treated like real people. But AI did not invent being rude, disrespectful, or careless with other people's time. For every problem amplified by AI, there are solutions AI can accelerate.\n\nAI is not the point. The point is us.\n\nTools are just tools. An email can bring people together or tear them apart. AI can be used to avoid other people or to build and enrich communities. The difference consists of intent, understanding, consent, and good fit, not technology.\n\nWe are a company founded on values and first principles, and the stubborn conviction that technology can be so much better than people are used to. We're still doing that… just with AI.\n\nThings we hold true\n\nAI is a tool\n\nAI is a powerful tool, but it is just a tool. We do not serve our tools. Our tools serve us.\n\nYou own your work\n\nI am not a “human in the loop,” I am the owner of the loop. It's my fucking loop. I am responsible for the quality of my work and the integrity of my working process, and so are you. “Claude did it” or “Claude said” is not an excuse.\n\nThe bar is going up\n\nEvery technological transition resets the baseline for performance—not by mandate, but by what becomes possible. This is true for companies, products, teams, tools, and people. What was excellent five years ago is table stakes today.\n\nWe welcome this. The nature of technology is that it always catches up. Which is why the nature of technologists is, we stay ahead.\n\nThe outcome is what matters\n\nA higher bar means better outcomes. Often this is about moving faster, but not always, and never exclusively. What outcome are we aiming to achieve? What would ‘better’ look like? What would ‘great’ look like? What is possible today that wasn't possible last year?\n\nFor outcomes to matter, we must embrace measuring ourselves. Everything is an experiment, but an experiment that doesn't get tracked is wasting everyone's time.\n\nHow we use AI\n\nA shortcut or a deep dive\n\nYou can use AI to help you do something fast and half-assed, or you can use AI to help you think harder, build with more rigor, communicate with more depth.\n\nThere is a time and a place for both, but the two are not interchangeable. Know the difference.\n\nAI for the role, AI for the self\n\nYou may use AI at work in ways that are prescribed by the company to do your job, and we owe you enablement and support for those.\n\nYou may also use AI of your own volition for calendar support or editing, as a tutor, rubber ducky, etc. This is much more personal and subjective, and no one is required to do it, but opting out of using AI does not exempt us from the higher bar.\n\nMore AI is not always better\n\nAI is not the right tool for every use case, and more AI is not always better. If AI is causing friction and frustration in a given setting, talk with your team about how to reduce or eliminate that frustration. Make the tools serve you.\n\nMaster the tools before ruling them out\n\nHowever, be careful to make this decision from a place of fluency, not ignorance, and revisit your decision occasionally. It's easy to blame the tools for the frustration of learning.\n\nUsage patterns\n\nAI should make our signal-to-noise ratio better, not worse. To do this, we need three things: self-awareness, respect for each other's time, and open dialogue.\n\nAddress the envelope\n\nAny time you send someone an artifact, tell them what it is, why you're sending it, and what you hope to receive from them, and any other useful context you can think of.\n\nThis is the “envelope” of your message. Addressing the envelope does a couple vital jobs:\n\nIt cultivates self-awareness. When you drop a large artifact on someone and walk away with no comment, it's easy to breeze past the fact that you may have just dumped a ton of work on someone. This surfaces as frustration with AI because AI has newly made this easier, but AI is not at fault. You own your work. When you describe your request in detail, it forces you to think through what you are asking them to do and what you really need from them.\n\nIt opens a conversation. When someone drops a link on you, it can feel like a demand, but it's not. We don't assign work at Honeycomb, we ask nicely, and if someone has concerns or objections, we talk about them. This should always be a conversation. “This is what I have, this is what I need. Are you the right person? Is this the right time? What questions do you have?” Ask. If someone sends you an artifact or a request and you feel a pit in your stomach, pay attention to it. What is it you fear?\n\nRespect other people's time and attention\n\nNever send someone an AI-generated doc unless you have first read it yourself, every word. If it's not worth your time and attention, how can you possibly say it is worth someone else's? This may be a low bar, but it's an important one.\n\nTo respect other people's time and attention, make the smallest necessary ask. You wouldn't ask someone to read a whole book when you need them to read page 152. Specificity is kindness, boundaries are respect.\n\nFour types of communication\n\nThis four-point scale can be used to plot whether the value of any communication is primarily personal or functional. On the left, the value is in that it comes from a specific person who thought it or felt it. On the right, the value comes primarily from the ideas or artifact itself.\n\nPersonal to the left, functional to the right. Like this:\n\n1: Personal opinions\n\nThe value of this communication is that a specific person thought it or felt it, or that it exists in the context of a relationship. You aren’t upset when a stranger doesn’t wish you happy birthday, but you might be upset if your partner doesn’t. When an expert in your field compliments your work, it means a lot because you respect them.\n\nUsing AI in this context tends to destroy trust instead of building it, unless AI has explicitly been welcomed in to the relationship. (“Wow, my manager even used AI to tell me happy birthday? What an asshole.”)\n\n2: Professional opinions\n\nMost professional communication goes here. Some of its value comes from you being the person who thought it or felt it, but not all—the quality, relevance, skill and fit of the message also matter.\n\nIf you gave advice, how good was it?\n\nIf you wrote a review, was it clear, useful and fair, and was the content not a surprise?\n\nIf you shared your opinion, how expert, well-crafted and timely was it?\n\nIt’s fine to use AI and other tools to arrange, structure or enhance these thoughts, but they should remain recognizably yours. If someone wants your opinion, or asks you to give a talk, they want your opinion, in your voice. When your voice is lost in the response, it may register as a breach of trust.\n\n3: Prose artifacts\n\nOn the other hand, there are artifacts. An artifact’s value does not derive from being something a particular person thought or felt, it comes from the ideas themselves. Artifacts include docs like PRDs, architecture diagrams and decisions, strategy docs, meeting notes, and much more. Sometimes code fits in this category too.\n\nArtifacts get reviewed by reading, and validated by tools like comments and discussion threads. An artifact usually has an owner, but our goal is to collaboratively make the ideas better, regardless of ownership or authorship.\n\n4: Software artifacts\n\nFormal, structured information like software can be verified automatedly in ways that written and spoken languages cannot. Wherever we can defer to the machines for testing, we probably should; validating logic at scale is hardly where humanity shines.\n\nHowever, merging source code without reading it is a badge of honor that must be earned. Today, most software at Honeycomb continues to be validated using a blend of techniques from 3 and 4.\n\nAsk for what you want\n\nWhile it may not always be entirely clear whether a given piece of feedback is more subjective or objective, it is usually extremely clear to people what they want. When they want someone’s personal, subjective opinion vs when they are reaching for “the best idea.”\n\nIf you know what you want: ask for it. If you aren’t sure what someone wants you to give them: ask.\n\nHow to handle mismatched expectations\n\nAn enormous amount of frustration is being generated right now by mismatched expectations and uncertainty. It is tempting to blame AI and start micromanaging and issuing rules over who can use AI in what ways, in which contexts.\n\nBut we hire adults. That is not our way. AI is just a tool, and our tools serve us.\n\nThe “reasonable effort” example\n\nIt would be incredibly rude for me to spend five minutes generating a piece of code and then drop it in someone’s lap, expecting them to spend two or three hours reviewing it.\n\nBut what if I spent five minutes generating a piece of code, and sent it to someone saying, “Hi, I just spent five minutes on this, and I was wondering if you were available to spend no more than five min giving me a gut check on it. Am I headed in the right direction?”\n\nThat seems fine, right?\n\nThe opinion example\n\nOr what if I ask someone for feedback on my written plan, and they respond by generating a variation of my plan with Claude, and sending back an entirely new artifact. This would be frustrating if I wanted their opinion, because now I have a whole new plan to digest and I still am not clear on what they think. What should I do?\n\nWell, you could engage with the content in a number of ways. You could ask to see their prompt, or re-state your request with more specificity, or you could waste a lot of time trying to tease out what they changed on purpose and what came along for the ride.\n\nBut this is a pretty basic case of missed signals. The better strategy is probably not to engage with the content at all, and deal with the mismatched expectations instead. Politely tell them what you actually need, and ask if they can give it.\n\nThe performance review example\n\nOne of the trickiest things to navigate is when you get peer feedback or a performance review that smells AI-generated, and you aren’t sure how to value it. Does it mean anything? Which parts came from them, and which were filled in by the AI? Did they even read it before they gave it to you? Will they get mad if you ask?\n\nThis can be deeply corrosive to trust, so it’s critical that we make space for these conversations. This cannot be a taboo topic. Managers, bring this up with your reports. Talk about your process. Make it safe to ask questions and venture feedback.\n\nWe actively encourage managers to use AI to build systems that help them be better managers—recording how they show up in meetings, coaching them on hard conversations, tracking their team members’ achievements.\n\nThere are countless valuable ways to use these tools. But they do not, cannot, must not supplant or replace the manager’s judgment. There is no world in which a manager can push a button and generate a performance review, skim it and hand it to their report. That is unacceptable. If your job can be automated away so easily, what do we need you for?\n\nWriting is thinking on paper, as William Zinsser said. While there are many ways that using AI can save us time and energy, the way we train the LLMs between our ears is by doing things, trying things, and yes, writing things. That takes work. Make sure you are doing the work you need to do to develop the good judgment we rely on you to have. Never shortchange your direct report or yourself by outsourcing that work to the machines.\n\nGive feedback in your voice\n\nAnd do your best, managers, to give feedback in your voice. People are developing a sixth sense for AI-generated text, and many people just stop reading. (Guilty.) It can feel like a real betrayal when you expect personal communication and sense you aren’t getting it.\n\nBut—and this is also important—it does not have to feel like a betrayal. It does not have to be a betrayal. The key is context, understanding, and trust. A manager who uses English as a second language might remind their reports that they use Claude as a courtesy gloss. A manager with strong AI-first systems could talk to her reports about her process and see if they buy into an experiment with auto-generated reviews.\n\nTeams legitimately vary in their tolerance and enthusiasm for this, but there are options. With people and communication and ingenuity, there always are.\n\nExecutive functioning is more important than ever\n\nSo much of this comes down to expectations and being explicit: Here is what I have, here is what I need. Are you available for that?\n\nI have had and heard about so many of these exchanges by now. I have felt the same seething frustration at having my time wasted. But when I track down the person on the other side, it’s invariably one of two things: either they weren’t aware how much time consuming, frustrating work they were generating for me, or they were causing the frustration in an attempt to be helpful.\n\nThe number of times they were trying to push work off their plate onto mine, or force me to spend hours cleaning up after their mess is an absolute zero.\n\nWe do not work with assholes, y’all. But we also do not work with mindreaders. We are used to taking so much for granted, and now we can’t.\n\nThe provenance of a document is always relevant\n\nAsking about how a doc was written or generated is hard when there’s a power dynamic, so managers have an extra dollop of responsibility. But no one is off the hook. No one gets in trouble for asking questions about whether something was AI-generated or human-made—it’s an important and relevant piece of context. And everyone should cheerfully disclose when asked.\n\nWhich brings us to one final note of caution.\n\nIf you feel uncomfortable about how you made the artifact, and you don’t want the recipient to know how you made it…\n\nThat is an important signal. I suggest you honor it.\n\nEthical issues we have a stance on\n\nThere are two specific mistakes we are trying to avoid in writing this section.\n\nWe don't want to write something glossy and aspirational about how much we “Care About Ethics™” with no evidence to back it up, but we also don't want to make commitments we can't keep. Instead, we will affirm some of the principles that have gotten us this far, and describe how they have guided our decisions in the past.\n\nExternalities and harms done by AI\n\nThere are a number of troubling externalities associated with AI:\n\nEnergy usage/carbon footprint\n\nIP theft\n\nPrivacy\n\nBias\n\nJob cuts, wage cuts, and disinvestment in the next generation\n\nWe are a for-profit company, and our first priority is to build a successful, sustainable business. When we succeed at business, we earn the right to think longer term and make bigger investments.\n\nOur vendor review process includes an ethics review. We preferentially give our money to vendors that share our values or are the lesser of two evils. We will continue to do so.\n\nOn energy and resource usage\n\nWe frankly have no idea what to do about this, as a consumer (not producer) of foundational AI models. Which is unfortunate, since it is probably the most alarming externality. We will re-examine in six months.\n\nOn intellectual property\n\nThis is a thorny one. It appears that model providers have knowingly violated copyright law for years with no brakes and no consequences, outcompeting (and dooming) competitors who followed the law. Was it illegal? Sure seemed that way. But the only honest answer is we don't know, and we won't know, until we learn how the Supreme Court will interpret the law.\n\nBut was it right? Absolutely not. It was settled law at the time, and they systematically broke it. To retroactively bless this behavior sets a concerning precedent for businesses like ours who believe in fair competition and following the law.\n\nEthics, morality, and the law have always been different things. As model users, we are aligned with the letter and spirit of the laws. But we benefit from the unsavory acquisition of training data, and we know it, which incurs a moral debt.\n\nAt a minimum, we should be diligent in citing references, assigning credit, and compensating contributors whose work we use in commercial activity, above and beyond what is legally required of us. All of which we have a track record of doing, and will continue to do.\n\nOn bias and privacy\n\n“You own your work” means that any bias introduced by AI is your problem. Be mindful of where bias tends to creep in, and guard against it. Verify results where possible. Welcome feedback warmly, correct, and move on.\n\nIt is not clear how we can contribute to privacy efforts.\n\nOn wages and disinvestment\n\nWe have never been a company that believes in squeezing the most work out of people for the least money. We compensate as well as we are able, and we take fair pay very seriously.\n\nWe have always felt a responsibility to invest in the people who work here, just as they invest in us. This includes hiring and training entry level workers when we are able to do so.\n\nMentoring and learning are at the heart of our job ladders in R\u0026D, and the SDR pipeline serves a similar purpose on the GTM side. We have supported a number of employees in retraining for different roles. Personal development budgets are widely used. We audit our salary bands for bias and equity, and practice transparency around pay bands in job postings.\n\nWe have learned the hard way that it does not serve anyone for us to hire junior employees when we aren't ready to support them, but when we can support them, we have and we will.\n\nOn activism vs working agreements\n\nThese ethical stances may seem relatively modest, and they are. These are working agreements for doing business, not ethical aspirations or activist goals.\n\nThere is a place for activism. There is a place for outright advocacy. At a time like this, we would all be well served to consider our ethical stances and how to act on them. Business may not be the ideal vehicle for activism, but activism is vital and necessary. People who take action in support of their beliefs (generally within the confines of the law) will not be retaliated against at Honeycomb.\n\nWe are here to build a business. There is virtue in this, even if it is not explicitly ideological.\n\nClosing statement\n\nThe workplace is one of the last remaining places where people of widely varying backgrounds and beliefs all come together to achieve something greater than themselves. We think this is precious. We think this is worth protecting.\n\nWe believe that treating people well is not at odds with the profit motive. We believe that people who are happy, healthy, well supported, and creatively engaged can do better work.\n\nWe believe that rigorous use of AI helps a company like ours accelerate development, delight customers, and go head to head with competitors with vastly more resources. We believe that using AI is not a replacement for skill and craft, but an amplification.\n\nWe believe that customers who are valued, respected, and listened to are happier, more loyal customers. Happy customers are more invested in giving us the feedback we need to build a better product. We believe in building mutually beneficial relationships and positive feedback loops that leave both sides better off.\n\nWe do these things, not as a sacrifice or a distraction from our core mission, but in service of it."])</script><script>self.__next_f.push([1,"36:T260f,"])</script><script>self.__next_f.push([1,"As agentic AI workflows gain traction within organizations, those organizations are asking how to account for their behavior while keeping costs manageable. Some are sticking with the old three pillars of observability approach: take a measurement to create a metric, record output to a log, and track serial progress with a trace. Each of these is useful, but treating them as distinct formats from the start means paying for them distinctly too. Separate storage doesn't come cheap. Add the extra software that makes up an AI agent along with the added unpredictability of non-deterministic systems and costs can balloon.\n\nAs an alternative to the idea of observability pillars, other organizations are using wide events. Wide events are a single format that can handle all three types of data because they're all one format. These organizations are consolidating their views to a \"single pane of data,\" as we like to say, and are saving money without sacrificing the context they need to account for their agents.\n\nIn this post, I'll build upon a prior paean to wide events. First, I'll describe the source of ballooning costs and why it's a result of centering distinct pillars of observability. Then, I'll explain how wide events prove more useful and cost effective in general, and for AI agents specifically.\n\nAI is just software\n\nHere's the honest truth: AI is software. Unpredictable, but software nonetheless. That means engineers can use telemetry data to identify problems that lead to poor customer experiences. Given that unpredictability, engineers need lots of context now more than ever if they hope to stand a chance of finding those problems. That requirement need not be a problem on its own. But if these systems need three types of data to present an adequate picture, which is analogous to needing three distinct languages to get an adequate description of something, then each type of data is going to see its costs grow. That's not even considering the headache of the additional overhead of trying to reconcile them, which isn't possible because the distinction is required by hypothesis.\n\nWhat is this additional context, and why might each type of data see its cost grow? AI agents add a whole new set of components to keep track of besides the dimensions of software people may be used to like user ID, http response code, enabled feature flags, etc. An agent and its non-deterministic behavior may be due to which model was used, which skills were invoked, whether a particular tool call worked and what failovers the model 'thought' to try, the initiating prompt, and more.\n\nNow, imagine tracking the number of each operation in distinct time series (including lots of one-offs for singular inputs like prompts) in a metrics system, a readout of each component every time it runs in their own log files, plus a trace for every turn in a conversation. That's a lot of data, only some of which conceptually overlaps like the recording of a unique prompt as the lone datapoint in a dedicated time series, the actual prompt text in a log, and the initiation point of an agent's trace. And then there's the additional work to actually correlate them all...\n\nThe first instinct in a situation like this may be to cut things like retention time. If data isn't stored for as long, creating a bunch of data may not be so bad. This assumes that storing the data is a significant cost, which it typically isn't. Instead, ingest and the compute necessary to run queries (in an acceptably fast manner) tend to be the dominant drivers of cost. Since AI agents are non-deterministic and therefore outputs are statistical, organizations are going to want long-term data so they can suss out behavioral patterns that only emerge with large numbers. It may seem like the only solution is to suffer through limited context... Fortunately, it doesn't have to be that way!\n\nEnter wide events\n\nThe wide event model makes it possible to have all of that with just one data file. Let's review what a wide event is. In her blog post on observability 2.0, Charity describes wide events in the following way:\n\nData gets stored in arbitrarily-wide structured log events (often called \"canonical logs,\" or what AWS internally refers to as \"service logs\"), often with trace and span IDs appended.\n\nYou can visualize the events over time as a trace, slice and dice your data to zoom in to individual events, or zoom out to a birds-eye view.\n\nYou can interact with your data by GROUP BY, break down, etc.\n\nAggregation is done at read time and preserves raw events for ad hoc querying. Hopefully, you derive your SLO data from the same data you query! Think of it as BI for systems/app/business data, all in one place. You can derive metrics, or logs, or traces, but it's all the same data.\n\nBreaking this down, an event is a file where the information stored within it is structured in some standardized pattern (Honeycomb uses a flat structure, no nesting allowed, and patterns the data as Key:Value pairs). That file is called an \"event\" because the instrumentation's operation of creating the information to go into the file is itself an event. In fact, it's the event that makes the information possible. The \"wide\" part comes from counting the number of aspects or properties of the system recorded in the file. If it's a big number, it's wide, and if it's a smaller number, it's narrow. The point, though, is that the only limit to how wide the event can be is the practical limit of the system ingesting the file.\n\nIf this sounds like a description of a log file, you're correct! This format is damn useful because of its versatility. Charity listed several different ways to use the files and the information they record, including as metrics, logs, and traces. Since engineers can use the wide event model in so many ways, that also means that the organizations they work for only pay to store the data they need once. When organizations stop making arbitrary distinctions and assuming conflicts, like logs vs metrics, they can get down to the business of saving money and engineering effort.\n\nSavings costs where agents are concerned\n\nLet's say I run an e-commerce website and have a contextual chat system. That system knows what product page my prospective customer is looking at, and it includes a skill which has the agent synthesize submitted reviews of that product. The chat can act as a proxy, and my prospective customer can ask that proxy about the product as if they were asking someone they knew who'd already bought it.\n\nIn the three pillars model, this would require several metrics time series recording information like the number of turns in the conversation, the number of times the skill was invoked, the length of time it took to synthesize the reviews, how long each response took, the p95 of all response times on this page over the last week, how many other tool calls were necessary, etc. The output of any and probably most (if not all) operations will get their own log file. Finally, each conversation may be its own trace but that could be quite unwieldy; it might be wise to split it up so each turn in the conversation gets its own trace.\n\nNow, compare the wide event model. Each operation still generates a file, but because they're wide events, those files can include information that allows recording metrics directly like the operations' duration and for calculating aggregation like p95 on the fly. With something like the \"parent\" concept, they can also store information for composing them into traces. And when an agentic conversation featuring an agent and sub-agents requires a view of multiple traces, they can even build up into an Agent Timeline. All of that power comes from a single data format that organizations only need to pay to store once.\n\nVersatility and simplicity\n\nThe versatility of wide events comes from their simplicity. It's that same simplicity that makes them not only more cost effective than the pillar model, but also more predictable. Undoubtedly, the three pillars model, especially when metrics are first among equals, can be cheaper in some cases due to preaggregation. However, it's the inherent uncertainty of whether your case is one of those \"some cases\" that's the problem.\n\nIf you need lots of context, like with AI agents, then it may not be feasible to preaggregate enough data to make the cost-savings worthwhile. Wide events don't require you to trade off between context and preaggregation, and that's why their simplicity enables cost predictability.\n\nIf you want to make your AI observability costs more predictable, start with examining what each of your pillars of observability are collecting and where there's duplication between datastores—and if it's a lot, start looking into shifting to the wide event model. As you make that shift, here's what you'll want to be thinking about:\n\nIdentify which information must remain available at request level and which can safely be aggregated or derived.\n\nConsider how cardinality, retention, workload growth, etc. affect the ability to forecast spend.\n\nWhere useful, connect token and model activity to telemetry volume so teams can understand how AI workload growth affects observability spend.\n\nThe point is to give yourself a means for predictable growth while preserving the information your team needs to make sure your AI agents are accountable to you.\n\nFinally, consider using Honeycomb as your observability tool of choice for those wide events. Honeycomb was designed from the beginning to use wide events and helps many customers understand their (AI) application behavior without forcing a tradeoff between their required context and cost.\n\nSee for yourself in a self-serve demo environment."])</script><script>self.__next_f.push([1,"37:T260f,"])</script><script>self.__next_f.push([1,"As agentic AI workflows gain traction within organizations, those organizations are asking how to account for their behavior while keeping costs manageable. Some are sticking with the old three pillars of observability approach: take a measurement to create a metric, record output to a log, and track serial progress with a trace. Each of these is useful, but treating them as distinct formats from the start means paying for them distinctly too. Separate storage doesn't come cheap. Add the extra software that makes up an AI agent along with the added unpredictability of non-deterministic systems and costs can balloon.\n\nAs an alternative to the idea of observability pillars, other organizations are using wide events. Wide events are a single format that can handle all three types of data because they're all one format. These organizations are consolidating their views to a \"single pane of data,\" as we like to say, and are saving money without sacrificing the context they need to account for their agents.\n\nIn this post, I'll build upon a prior paean to wide events. First, I'll describe the source of ballooning costs and why it's a result of centering distinct pillars of observability. Then, I'll explain how wide events prove more useful and cost effective in general, and for AI agents specifically.\n\nAI is just software\n\nHere's the honest truth: AI is software. Unpredictable, but software nonetheless. That means engineers can use telemetry data to identify problems that lead to poor customer experiences. Given that unpredictability, engineers need lots of context now more than ever if they hope to stand a chance of finding those problems. That requirement need not be a problem on its own. But if these systems need three types of data to present an adequate picture, which is analogous to needing three distinct languages to get an adequate description of something, then each type of data is going to see its costs grow. That's not even considering the headache of the additional overhead of trying to reconcile them, which isn't possible because the distinction is required by hypothesis.\n\nWhat is this additional context, and why might each type of data see its cost grow? AI agents add a whole new set of components to keep track of besides the dimensions of software people may be used to like user ID, http response code, enabled feature flags, etc. An agent and its non-deterministic behavior may be due to which model was used, which skills were invoked, whether a particular tool call worked and what failovers the model 'thought' to try, the initiating prompt, and more.\n\nNow, imagine tracking the number of each operation in distinct time series (including lots of one-offs for singular inputs like prompts) in a metrics system, a readout of each component every time it runs in their own log files, plus a trace for every turn in a conversation. That's a lot of data, only some of which conceptually overlaps like the recording of a unique prompt as the lone datapoint in a dedicated time series, the actual prompt text in a log, and the initiation point of an agent's trace. And then there's the additional work to actually correlate them all...\n\nThe first instinct in a situation like this may be to cut things like retention time. If data isn't stored for as long, creating a bunch of data may not be so bad. This assumes that storing the data is a significant cost, which it typically isn't. Instead, ingest and the compute necessary to run queries (in an acceptably fast manner) tend to be the dominant drivers of cost. Since AI agents are non-deterministic and therefore outputs are statistical, organizations are going to want long-term data so they can suss out behavioral patterns that only emerge with large numbers. It may seem like the only solution is to suffer through limited context... Fortunately, it doesn't have to be that way!\n\nEnter wide events\n\nThe wide event model makes it possible to have all of that with just one data file. Let's review what a wide event is. In her blog post on observability 2.0, Charity describes wide events in the following way:\n\nData gets stored in arbitrarily-wide structured log events (often called \"canonical logs,\" or what AWS internally refers to as \"service logs\"), often with trace and span IDs appended.\n\nYou can visualize the events over time as a trace, slice and dice your data to zoom in to individual events, or zoom out to a birds-eye view.\n\nYou can interact with your data by GROUP BY, break down, etc.\n\nAggregation is done at read time and preserves raw events for ad hoc querying. Hopefully, you derive your SLO data from the same data you query! Think of it as BI for systems/app/business data, all in one place. You can derive metrics, or logs, or traces, but it's all the same data.\n\nBreaking this down, an event is a file where the information stored within it is structured in some standardized pattern (Honeycomb uses a flat structure, no nesting allowed, and patterns the data as Key:Value pairs). That file is called an \"event\" because the instrumentation's operation of creating the information to go into the file is itself an event. In fact, it's the event that makes the information possible. The \"wide\" part comes from counting the number of aspects or properties of the system recorded in the file. If it's a big number, it's wide, and if it's a smaller number, it's narrow. The point, though, is that the only limit to how wide the event can be is the practical limit of the system ingesting the file.\n\nIf this sounds like a description of a log file, you're correct! This format is damn useful because of its versatility. Charity listed several different ways to use the files and the information they record, including as metrics, logs, and traces. Since engineers can use the wide event model in so many ways, that also means that the organizations they work for only pay to store the data they need once. When organizations stop making arbitrary distinctions and assuming conflicts, like logs vs metrics, they can get down to the business of saving money and engineering effort.\n\nSavings costs where agents are concerned\n\nLet's say I run an e-commerce website and have a contextual chat system. That system knows what product page my prospective customer is looking at, and it includes a skill which has the agent synthesize submitted reviews of that product. The chat can act as a proxy, and my prospective customer can ask that proxy about the product as if they were asking someone they knew who'd already bought it.\n\nIn the three pillars model, this would require several metrics time series recording information like the number of turns in the conversation, the number of times the skill was invoked, the length of time it took to synthesize the reviews, how long each response took, the p95 of all response times on this page over the last week, how many other tool calls were necessary, etc. The output of any and probably most (if not all) operations will get their own log file. Finally, each conversation may be its own trace but that could be quite unwieldy; it might be wise to split it up so each turn in the conversation gets its own trace.\n\nNow, compare the wide event model. Each operation still generates a file, but because they're wide events, those files can include information that allows recording metrics directly like the operations' duration and for calculating aggregation like p95 on the fly. With something like the \"parent\" concept, they can also store information for composing them into traces. And when an agentic conversation featuring an agent and sub-agents requires a view of multiple traces, they can even build up into an Agent Timeline. All of that power comes from a single data format that organizations only need to pay to store once.\n\nVersatility and simplicity\n\nThe versatility of wide events comes from their simplicity. It's that same simplicity that makes them not only more cost effective than the pillar model, but also more predictable. Undoubtedly, the three pillars model, especially when metrics are first among equals, can be cheaper in some cases due to preaggregation. However, it's the inherent uncertainty of whether your case is one of those \"some cases\" that's the problem.\n\nIf you need lots of context, like with AI agents, then it may not be feasible to preaggregate enough data to make the cost-savings worthwhile. Wide events don't require you to trade off between context and preaggregation, and that's why their simplicity enables cost predictability.\n\nIf you want to make your AI observability costs more predictable, start with examining what each of your pillars of observability are collecting and where there's duplication between datastores—and if it's a lot, start looking into shifting to the wide event model. As you make that shift, here's what you'll want to be thinking about:\n\nIdentify which information must remain available at request level and which can safely be aggregated or derived.\n\nConsider how cardinality, retention, workload growth, etc. affect the ability to forecast spend.\n\nWhere useful, connect token and model activity to telemetry volume so teams can understand how AI workload growth affects observability spend.\n\nThe point is to give yourself a means for predictable growth while preserving the information your team needs to make sure your AI agents are accountable to you.\n\nFinally, consider using Honeycomb as your observability tool of choice for those wide events. Honeycomb was designed from the beginning to use wide events and helps many customers understand their (AI) application behavior without forcing a tradeoff between their required context and cost.\n\nSee for yourself in a self-serve demo environment."])</script><script>self.__next_f.push([1,"38:T27e6,"])</script><script>self.__next_f.push([1,"I'm investigating repeated errors in my e-commerce application, and I need to get enough context in a single Honeycomb query to piece the entire picture together. Each query returns events based on the event's WHERE clauses, but I want to know several things from outside of the event that recorded an error. Things like:\n\nthe URL involved\n\nthe exception details\n\nthe user's email address to contact them for support\n\nthe shipping costs\n\nthe amount of money the user spent\n\nThose attributes are all over the trace. That's going to make a single query tough, right?\n\nWrong!\n\nBut, once I start applying relational queries to this challenge, I can grab information all over the trace and make it visible to the team—and my manager, who wanted to be informed on business-impacting errors.\n\nSee relational queries in action in the below video.\n\n\n\nWhat is a relational query?\n\nHoneycomb relational queries let you add criteria and groupings not only to target specific trace spans, but to their parent, children, and any other trace-involved spans as well. This can be incredibly useful in groupings, filterings, and queries in boards, triggers, and SLOs. Relational queries are implemented by attributes prefixed by the following keywords: root, parent, child, any, any2, and any3.\n\nFor additional information on relational fields in queries, head over to the relational fields page.\n\nLet's start with the error spans in the checkout service\n\nMy manager asked me to focus on errors related to checkout, so I'll start there. The errors are the events we care about. I'll make my query dataset the checkout service, and add error = true to the WHERE conditions. I'll GROUP BY name to see what spans are tripping the error status, since all spans have a name property.\n\nThis shows several span names with errors originating from the checkout service in the past 24 hours:\n\nOverview is the \"show me the values\" view: any visualization or grouping in the query shows up in the table of values below the graph in the Overview tab.\n\nSo far, we've located a single event type in our query, one with an error = true condition:\n\nTo make an impact that helps both business and our IT team, I want to include the actual exception.message causing the error in the query results.\n\nWhere is the exception?\n\nThe exception details exist within the error event, recorded against the span. Here's a chunk of the trace view in Honeycomb. That right-most red circle (highlighted in blue) represents the erroring span's exception event:\n\nOur first challenge: the WHERE error = true condition finds the trace span, but the span event is its child.\n\nLet's get the actual error message\n\nI'll use the relational child prefix to add exception.message to the GROUP BY, and, just so I don't include errors that propagated upward but may not have messages of their own, I'll only include errors that contain an exception event:\n\nRight away, we've narrowed down the spans in the checkout service that contain errors with real exceptions.\n\nThis query now looks at two events: the primary span, and the span's child, an event with the exception details.\n\nGetting top-level information about the trace\n\nI want to see what endpoint people hit when they get this error.\n\nTo do that, I'll add another relational query keyword, root, using, root.http.url to the GROUP BY to see the values, and I'll narrow the query to return errors where the root spans that actually contain a root.http.url using the WHERE clause.\n\nI'm starting to get more useful data; I see the endpoint used for each call. In the past 14 days, we've had a few failures around the payment process:\n\nAdding root to the GROUP BY fetches additional trace span attributes from the span that began this trace, which Honeycomb refers to as the root span, even though the primary search fetches spans with error = true.\n\nI don't just have to limit myself to the http.url in root, I can add other attributes as well.\n\nMore details from the root span\n\nI wonder what the http status code is for these errors. I'll add it to the GROUP BY:\n\nEach of our failures cause http 500 errors:\n\nOh, and the management team wants to focus on operations that leave money on the table. Next, we'll focus on the checkout purchase details.\n\nPulling the user id from another span\n\nThe manager wanted the user's information, so we can quickly contact them and resolve their problems with the site. Elsewhere in the trace, we record an app.user.id attribute. We can find it quickly, regardless of which span it lives in, using Honeycomb's any relational prefix.\n\nLet's try it. We should be able to add any.app.user.id to the GROUP BY, right?\n\nOk, it looks good. Unfortunately, when I run the query, the any.app.user.id clause gets removed, and a tip appears:\n\nRemoved 'any.app.user.id' from the Group By clause. Add a corresponding any filter to the Where clause to group by any fields.\n\nApparently we can't just use any in the WHERE clause. So, what do we do?\n\nTip: Identify a span in the WHERE clause to use its values in the GROUP BY clause\n\nYou certainly can use the any clause in the GROUP BY, but only if you add the same attribute to a WHERE clause… To fix this here, I'll just add an exists clause to the conditions:\n\nNow, we get the recorded app.user.id that exists somewhere in the trace:\n\nHere are some results:\n\nI also received a warning:\n\nResults match on the first `any` span found per trace and may exclude additional matching spans.\n\nBecause Honeycomb has to pick a single qualifying span for the any expression, it will not retrieve more than one here, so it picked the first one it found. In this case, it's fine; if you try this and found it picked the wrong span, qualify it further with other attributes on the any.\n\nAdding other any attributes\n\nLet's try adding another attribute using any. How about app.shipping.amount? It's in another span, surely any should work, right?\n\nNope! Now my query is broken, and it found no spans.\n\nWhat happened?\n\nWe didn't find one span with both attributes!\n\nFor any to retrieve a span, the attributes in referenced must all match the WHERE criteria against the any.\n\nIn my query above, I asked for spans that contained both app.user.id and app.shipping.amount, and no single span containing both of those attributes exists in our data.\n\nMatching on additional spans: more anys\n\nTo match on additional spans, Honeycomb provides two additional attributes: any2 and any3. This lets us widen the results to include up to three spans anywhere in the trace with different, even mutually exclusive conditions.\n\nI'll use any2 to against app.shipping.amount from that other trace span, adding it to the WHERE as an existence check, and then grouping by it:\n\nThis brings us the additional attribute:\n\nNow I'm looking at more of the trace:\n\nI'm querying up to five spans in the same trace: the primary span with an error, the child exception event, the first span in the same trace containing root.http.url, and the first span in the same trace that has an app.shipping.amount.\n\nHow many spans can you reference this way?\n\nBut we still don't have a financial amount for these failed payments! As it turns out, another span has that attribute, app.payment.amount, so can we pull yet another span's attributes into our query?\n\nYes, we can. Honeycomb actually provides three anys: any, any2, and any3. I'll use any3 to pull in the actual payment amount from the span that starts the payment charging process.\n\nThis gives me data across six different spans!\n\nThis is straining the ability to display so much data in the Overview tab, but the data can be found and displayed from one query:\n\nI can add this query to my board in table form, and get immediate at-a-glance views of the problems coming from my checkout service.\n\nThe none prefix\n\nUse the none prefix to make sure a WHERE clause item doesn't exist anywhere in the traces of the spans you select. For example, to ignore any traces for a specific product, use:\n\nnone.app.product.id = 0PUK6V6EV0\n\nRe-running your query, the results won't include traces with errors for that product.\n\nNow, the errors are only reported when one specific product isn't part of the trace with the error.\n\nAn odd request, but it can be done!\n\nCheck exactly where the error happened\n\nFinally, we can restrict our errors to the ones that exist at the API surface layer with the parent keyword.\n\nThis makes sure the span directly above the erroring span is in the api-gateway service. A partial extract now only shows trace spans from the API gateway.\n\nAdd trace.trace_id to the GROUP BY to make it easy for anyone to view a trace right from the query results. Our query reach has extended!\n\nNow, we're referencing seven different spans, including the span with the error. Plus, we're excluding any traces involving one specific product with the none expression.\n\nAdditional techniques\n\nHere are a few more ideas you can leverage.\n\nAdding attributes to additional spans\n\nif you could put all of these attributes on every span from your code, great! Honeycomb doesn't charge for additional attributes for this reason. Then you can use them in a visualization like HEATMAP or SUM.\n\nHave your agent write the query\n\nYour agent is smart enough to get information across different spans, and will use some of these techniques. If you want to have the agent do something specific, like referencing parent, root, and additional spans, you can use relational query operation language in your request.\n\nUse the query in your favorite agent or another environment\n\nIf you've connected your agent to the Honeycomb MCP, you can grab the query URL from Honeycomb, share it in Slack or email, or tell the Honeycomb MCP (or Canvas) to run the query based on it.\n\nWrap-up\n\nWe started off with a challenge: grabbing information across a set of events in a single trace to use in a Honeycomb Board.\n\nUsing relational query operators, we were able to connect our results across services from the entire business. We are now able to view attributes from more than just a single service in the Honeycomb Overview tab (and in Board tables), and we can narrow down error details, reported from a specific service, at particular times, from trace spans. Magic!"])</script><script>self.__next_f.push([1,"39:T27e6,"])</script><script>self.__next_f.push([1,"I'm investigating repeated errors in my e-commerce application, and I need to get enough context in a single Honeycomb query to piece the entire picture together. Each query returns events based on the event's WHERE clauses, but I want to know several things from outside of the event that recorded an error. Things like:\n\nthe URL involved\n\nthe exception details\n\nthe user's email address to contact them for support\n\nthe shipping costs\n\nthe amount of money the user spent\n\nThose attributes are all over the trace. That's going to make a single query tough, right?\n\nWrong!\n\nBut, once I start applying relational queries to this challenge, I can grab information all over the trace and make it visible to the team—and my manager, who wanted to be informed on business-impacting errors.\n\nSee relational queries in action in the below video.\n\n\n\nWhat is a relational query?\n\nHoneycomb relational queries let you add criteria and groupings not only to target specific trace spans, but to their parent, children, and any other trace-involved spans as well. This can be incredibly useful in groupings, filterings, and queries in boards, triggers, and SLOs. Relational queries are implemented by attributes prefixed by the following keywords: root, parent, child, any, any2, and any3.\n\nFor additional information on relational fields in queries, head over to the relational fields page.\n\nLet's start with the error spans in the checkout service\n\nMy manager asked me to focus on errors related to checkout, so I'll start there. The errors are the events we care about. I'll make my query dataset the checkout service, and add error = true to the WHERE conditions. I'll GROUP BY name to see what spans are tripping the error status, since all spans have a name property.\n\nThis shows several span names with errors originating from the checkout service in the past 24 hours:\n\nOverview is the \"show me the values\" view: any visualization or grouping in the query shows up in the table of values below the graph in the Overview tab.\n\nSo far, we've located a single event type in our query, one with an error = true condition:\n\nTo make an impact that helps both business and our IT team, I want to include the actual exception.message causing the error in the query results.\n\nWhere is the exception?\n\nThe exception details exist within the error event, recorded against the span. Here's a chunk of the trace view in Honeycomb. That right-most red circle (highlighted in blue) represents the erroring span's exception event:\n\nOur first challenge: the WHERE error = true condition finds the trace span, but the span event is its child.\n\nLet's get the actual error message\n\nI'll use the relational child prefix to add exception.message to the GROUP BY, and, just so I don't include errors that propagated upward but may not have messages of their own, I'll only include errors that contain an exception event:\n\nRight away, we've narrowed down the spans in the checkout service that contain errors with real exceptions.\n\nThis query now looks at two events: the primary span, and the span's child, an event with the exception details.\n\nGetting top-level information about the trace\n\nI want to see what endpoint people hit when they get this error.\n\nTo do that, I'll add another relational query keyword, root, using, root.http.url to the GROUP BY to see the values, and I'll narrow the query to return errors where the root spans that actually contain a root.http.url using the WHERE clause.\n\nI'm starting to get more useful data; I see the endpoint used for each call. In the past 14 days, we've had a few failures around the payment process:\n\nAdding root to the GROUP BY fetches additional trace span attributes from the span that began this trace, which Honeycomb refers to as the root span, even though the primary search fetches spans with error = true.\n\nI don't just have to limit myself to the http.url in root, I can add other attributes as well.\n\nMore details from the root span\n\nI wonder what the http status code is for these errors. I'll add it to the GROUP BY:\n\nEach of our failures cause http 500 errors:\n\nOh, and the management team wants to focus on operations that leave money on the table. Next, we'll focus on the checkout purchase details.\n\nPulling the user id from another span\n\nThe manager wanted the user's information, so we can quickly contact them and resolve their problems with the site. Elsewhere in the trace, we record an app.user.id attribute. We can find it quickly, regardless of which span it lives in, using Honeycomb's any relational prefix.\n\nLet's try it. We should be able to add any.app.user.id to the GROUP BY, right?\n\nOk, it looks good. Unfortunately, when I run the query, the any.app.user.id clause gets removed, and a tip appears:\n\nRemoved 'any.app.user.id' from the Group By clause. Add a corresponding any filter to the Where clause to group by any fields.\n\nApparently we can't just use any in the WHERE clause. So, what do we do?\n\nTip: Identify a span in the WHERE clause to use its values in the GROUP BY clause\n\nYou certainly can use the any clause in the GROUP BY, but only if you add the same attribute to a WHERE clause… To fix this here, I'll just add an exists clause to the conditions:\n\nNow, we get the recorded app.user.id that exists somewhere in the trace:\n\nHere are some results:\n\nI also received a warning:\n\nResults match on the first `any` span found per trace and may exclude additional matching spans.\n\nBecause Honeycomb has to pick a single qualifying span for the any expression, it will not retrieve more than one here, so it picked the first one it found. In this case, it's fine; if you try this and found it picked the wrong span, qualify it further with other attributes on the any.\n\nAdding other any attributes\n\nLet's try adding another attribute using any. How about app.shipping.amount? It's in another span, surely any should work, right?\n\nNope! Now my query is broken, and it found no spans.\n\nWhat happened?\n\nWe didn't find one span with both attributes!\n\nFor any to retrieve a span, the attributes in referenced must all match the WHERE criteria against the any.\n\nIn my query above, I asked for spans that contained both app.user.id and app.shipping.amount, and no single span containing both of those attributes exists in our data.\n\nMatching on additional spans: more anys\n\nTo match on additional spans, Honeycomb provides two additional attributes: any2 and any3. This lets us widen the results to include up to three spans anywhere in the trace with different, even mutually exclusive conditions.\n\nI'll use any2 to against app.shipping.amount from that other trace span, adding it to the WHERE as an existence check, and then grouping by it:\n\nThis brings us the additional attribute:\n\nNow I'm looking at more of the trace:\n\nI'm querying up to five spans in the same trace: the primary span with an error, the child exception event, the first span in the same trace containing root.http.url, and the first span in the same trace that has an app.shipping.amount.\n\nHow many spans can you reference this way?\n\nBut we still don't have a financial amount for these failed payments! As it turns out, another span has that attribute, app.payment.amount, so can we pull yet another span's attributes into our query?\n\nYes, we can. Honeycomb actually provides three anys: any, any2, and any3. I'll use any3 to pull in the actual payment amount from the span that starts the payment charging process.\n\nThis gives me data across six different spans!\n\nThis is straining the ability to display so much data in the Overview tab, but the data can be found and displayed from one query:\n\nI can add this query to my board in table form, and get immediate at-a-glance views of the problems coming from my checkout service.\n\nThe none prefix\n\nUse the none prefix to make sure a WHERE clause item doesn't exist anywhere in the traces of the spans you select. For example, to ignore any traces for a specific product, use:\n\nnone.app.product.id = 0PUK6V6EV0\n\nRe-running your query, the results won't include traces with errors for that product.\n\nNow, the errors are only reported when one specific product isn't part of the trace with the error.\n\nAn odd request, but it can be done!\n\nCheck exactly where the error happened\n\nFinally, we can restrict our errors to the ones that exist at the API surface layer with the parent keyword.\n\nThis makes sure the span directly above the erroring span is in the api-gateway service. A partial extract now only shows trace spans from the API gateway.\n\nAdd trace.trace_id to the GROUP BY to make it easy for anyone to view a trace right from the query results. Our query reach has extended!\n\nNow, we're referencing seven different spans, including the span with the error. Plus, we're excluding any traces involving one specific product with the none expression.\n\nAdditional techniques\n\nHere are a few more ideas you can leverage.\n\nAdding attributes to additional spans\n\nif you could put all of these attributes on every span from your code, great! Honeycomb doesn't charge for additional attributes for this reason. Then you can use them in a visualization like HEATMAP or SUM.\n\nHave your agent write the query\n\nYour agent is smart enough to get information across different spans, and will use some of these techniques. If you want to have the agent do something specific, like referencing parent, root, and additional spans, you can use relational query operation language in your request.\n\nUse the query in your favorite agent or another environment\n\nIf you've connected your agent to the Honeycomb MCP, you can grab the query URL from Honeycomb, share it in Slack or email, or tell the Honeycomb MCP (or Canvas) to run the query based on it.\n\nWrap-up\n\nWe started off with a challenge: grabbing information across a set of events in a single trace to use in a Honeycomb Board.\n\nUsing relational query operators, we were able to connect our results across services from the entire business. We are now able to view attributes from more than just a single service in the Honeycomb Overview tab (and in Board tables), and we can narrow down error details, reported from a specific service, at particular times, from trace spans. Magic!"])</script><script>self.__next_f.push([1,"3a:T289f,"])</script><script>self.__next_f.push([1,"It's been one year since we issued an AI mandate inside Honeycomb, and we've been doing a lot of reflecting internally on how far we've come and how far we have yet to go.\n\nI recently shared a post from our SVP of sales, Manny Alves, on the way our GTM teams use AI and how we expect our teams to interact with customers and prospects. This week I'd like to share a (lightly edited) note from Emily Nakashima, SVP of Engineering. It lays out our reasons for going all in on AI and connects it back to our values and business prop. It sets forth a new north star for our engineering org to shoot for (which yes, creates as many new questions as it answers!). And it balances out this abstract, aspirational language with some practical advice for the concerns of the day (e.g. \"we have too many long slack threads\").\n\nWhile the specific FAQ may not be directly relevant to your engineering orgs, I included it here because I love how the combination reflects the kind of engineering leadership we have grown to expect at Honeycomb: ambitious, humane, and eternally grounded in the details.\n\n~charity\n\nAI Usage in Engineering, by Emily Nakashima\n\nIn August of 2025, Honeycomb's founders wrote a message to the company about our stance on AI adoption, asking each employee to attempt to 2x their productivity (really, impact) with AI.\n\nWhile this goal applied to all teams at Honeycomb, it's particularly interesting for engineering, given the industry-wide focus on AI-assisted coding and new entrants in the \"AI Ops\" and \"AI SRE\" product categories. What does it mean for us in engineering?\n\nWhy adopt AI?\n\n💡 \"To give all software engineers the observability they need to understand their software \u0026 delight their users.\" - Honeycomb mission\n\nReason 1: to help shape the future of our industry\n\nAI is here to stay in the industry, and it's changing how software engineers everywhere work. However, the precise new ways we'll uphold and live out our values in this technology era are yet to be determined. If we want to be the ones inventing them and shaping how teams run and maintain software at scale, we need to be continuously building our skills and capabilities with AI to better understand how and where we can and can't (or shouldn't) push the boundaries.\n\nReason 2: to retain our credibility with our customers as expert guides\n\nOur success as a business has heavily relied on our reputation as tastemakers and experts in software. It's not good enough for us to simply adopt AI tools and workflows after they are known to work and broadly adopted. We are not followers. We wrestle with software on the boundaries of what's possible, we explore hard problems, we reason from first principles, and when we find something that works we bring the industry along with us. It's who we are. It's why people listen.\n\nReason 3: we need every tool we can get to help our customers overcome the inertia of the status quo\n\nThe state of the art in the industry is just bad. But it's everywhere. Which means it takes a lot of energy to dislodge the status quo.\n\nEvery vendor claims to \"do observability.\" But doing it right means helping teams change the way they build and validate software, which goes much deeper than slapping a few more dashboards on top of archaic logs and metrics. Our job isn't to out-shout the hype cycles or go nose to nose with the status quo on features and checklists. It's to stay relentlessly focused on honing an opinionated approach, making it easier and easier for engineering teams to understand their software, their product, and their users.\n\nWhat's our north star?\n\n⭐ We aspire to be in the top 10% most AI-enabled, most productive engineering teams at companies of our size and stage.\n\nConcretely, in addition to the company-wide 2x mandate, we have the following near-term goals for EO 2026. These goals are an initial guess and are VERY subject to change as we learn more. We want them to point us in the right direction, not prescriptively tell us where to focus.\n\nBy the end of the year, our systems are safe enough that at least 25% of all PRs are AI-reviewed and auto-merged (with no human review required) while maintaining a change failure rate under 3% (we're close today)\n\nWe maintain our SLOs and don't increase incident response workload outside of sustainable bounds (📉 course correction already needed here)\n\nWe are actively re-shaping how software teams work, such that our jobs continue to be impactful, meaningful, and sustainable\n\nWe are sharing what we learn outside of Honeycomb (e.g., via blog posts, conference talks, social media, etc.)\n\nNote: while the above list of measurable goals focus on code authorship, our goal is to use AI across the software development lifecycle. As we find additional points in the lifecycle to measure, we'll add them to the list above.\n\nFAQ\n\nWhat kind of support can I expect for my AI usage?\n\nExpect the company to provide you with resources like product subscriptions, tokens, and shared best practices, but know that your own continuous experimentation and learning will also be required. If we waited until all aspects of AI-assisted coding and related educational resources were fully baked to invest in, we would miss the boat. This means we all have to participate actively in learning and experimentation together.\n\nAdditionally, we've asked the engineering enablement team to add some AI platform work to its roadmap. This team has a broader charter beyond AI, but we recognize that we need both distributed and centralized efforts to achieve our vision. If there is a particular way our AI-backed tooling could be more robust or AI usage could be easier, this team is probably the right one to share it with; engineering leadership will work with them to continue to add support for the AI platform portion of their work.\n\nHow do I know if my AI usage meets Honeycomb's expectations? How is this measured?\n\nAs with all conversations about, \"Am I meeting expectations for my role?\" or \"How am I performing?\" your first stop is your manager. While we may look at some metrics to understand adoption and usage, there's no specific set of quantitative metrics we expect each person to hit. Your manager can help you understand how you are performing relative to the expectations of your role. That said, sometimes a rough heuristic can help keep us all calibrated. Here is one: aim to have a shareable insight that impacts how you approach future work at least ~1x/mo. We are trying to push boundaries vs trying to play it safe.\n\nAre we headed toward a \"software factory\" approach?\n\nIt's an intriguing approach that's generating a lot of conversation in the industry, and while we want to explore it, we understand that a lot of the patterns and best practices aren't settled yet.\n\nWe expect that across engineering, we've exited the era of \"AI as glorified autocomplete\" and are all making use of agentic workflows, often using multiple agents concurrently. However, the exact patterns that we'll land on as the most impactful and effective over the long term are still up for debate. Our ask is that you help us figure out how we can all be effective at these new higher levels of abstraction, but we don't necessarily yet have prescriptive guidance about the exact patterns we see in the future. Engineering enablement is currently the owner of the next steps here, as part of their developer productivity charter.\n\nShould I be running a certain number of agents at once?\n\nThere are many contributing factors to how many agents anyone should be running, including technical limitations, and the fact that different people's brains work in different ways and dovetail with tools differently. Everyone should put in the time and experimentation to find out where their \"sweet spot\" is. Ultimately, the answer to this question is you should run the number of agents that allows you to deliver impact most effectively, and you should do the work of generating the data to answer that question for yourself.\n\nI see a 200-reply thread about AI usage patterns. Should I participate?\n\nThere is real, meaningful work to be done around creating and defining AI norms and usage patterns. These tools are driving novel human interactions, and getting them right involves conversation, iteration, and deep listening.\n\nThat said, none of us have the job of Professional Slack Responder™, and many of these threads quickly can become circular, sucking up a lot of time and emotional energy without creating forward progress. Nobody is required to participate in these discussions, but if you choose to join in, you are expected to:\n\nBe quick to assign action items and next steps, even if experimental, rather than rehashing a question you've already seen discussed.\n\nMove conversations from Slack to a meeting if you believe the conversation is valuable but it isn't coming to a conclusion.\n\nAsk yourself if you're genuinely moving the conversation forward, vs. venting or engaging just to avoid missing out.\n\nThe workflow challenges that spawn these threads are often very real, but a long Slack thread may not be part of the solution.\n\nBe a responsible steward of your coworkers' and your own time and energy.\n\nMake sure you're doing your first job first.\n\nThere are things about these tools that make my job less satisfying, more stressful, etc. How do I cope with that?\n\nEvery major wave of technological change impacts how we do our work and the satisfaction we may feel from our craft, often in a mix of positive and negative ways. This is very, very true for AI tools and particularly apparent for more autonomous agentic workflows.\n\nIt's not strange to feel a sense of loss or grief as we set down or reduce parts of our job that felt satisfying and prioritize other ways of working. Our ask isn't to pretend those feelings don't exist, but to engage with them head on. We encourage you to take time to experiment to find new ways of working that fit both you and the available tools, and share what's working (and what's not) with your teammates and Honeycomb at large.\n\nIs this just about writing code faster?\n\nNo. We believe there's leverage across the whole lifecycle.\n\nWe encourage you and your teams to spend time experimenting with these tools for use cases beyond code generation, and to make time to talk with each other about how best to collaborate as these tools change your workflows."])</script><script>self.__next_f.push([1,"3b:T289f,"])</script><script>self.__next_f.push([1,"It's been one year since we issued an AI mandate inside Honeycomb, and we've been doing a lot of reflecting internally on how far we've come and how far we have yet to go.\n\nI recently shared a post from our SVP of sales, Manny Alves, on the way our GTM teams use AI and how we expect our teams to interact with customers and prospects. This week I'd like to share a (lightly edited) note from Emily Nakashima, SVP of Engineering. It lays out our reasons for going all in on AI and connects it back to our values and business prop. It sets forth a new north star for our engineering org to shoot for (which yes, creates as many new questions as it answers!). And it balances out this abstract, aspirational language with some practical advice for the concerns of the day (e.g. \"we have too many long slack threads\").\n\nWhile the specific FAQ may not be directly relevant to your engineering orgs, I included it here because I love how the combination reflects the kind of engineering leadership we have grown to expect at Honeycomb: ambitious, humane, and eternally grounded in the details.\n\n~charity\n\nAI Usage in Engineering, by Emily Nakashima\n\nIn August of 2025, Honeycomb's founders wrote a message to the company about our stance on AI adoption, asking each employee to attempt to 2x their productivity (really, impact) with AI.\n\nWhile this goal applied to all teams at Honeycomb, it's particularly interesting for engineering, given the industry-wide focus on AI-assisted coding and new entrants in the \"AI Ops\" and \"AI SRE\" product categories. What does it mean for us in engineering?\n\nWhy adopt AI?\n\n💡 \"To give all software engineers the observability they need to understand their software \u0026 delight their users.\" - Honeycomb mission\n\nReason 1: to help shape the future of our industry\n\nAI is here to stay in the industry, and it's changing how software engineers everywhere work. However, the precise new ways we'll uphold and live out our values in this technology era are yet to be determined. If we want to be the ones inventing them and shaping how teams run and maintain software at scale, we need to be continuously building our skills and capabilities with AI to better understand how and where we can and can't (or shouldn't) push the boundaries.\n\nReason 2: to retain our credibility with our customers as expert guides\n\nOur success as a business has heavily relied on our reputation as tastemakers and experts in software. It's not good enough for us to simply adopt AI tools and workflows after they are known to work and broadly adopted. We are not followers. We wrestle with software on the boundaries of what's possible, we explore hard problems, we reason from first principles, and when we find something that works we bring the industry along with us. It's who we are. It's why people listen.\n\nReason 3: we need every tool we can get to help our customers overcome the inertia of the status quo\n\nThe state of the art in the industry is just bad. But it's everywhere. Which means it takes a lot of energy to dislodge the status quo.\n\nEvery vendor claims to \"do observability.\" But doing it right means helping teams change the way they build and validate software, which goes much deeper than slapping a few more dashboards on top of archaic logs and metrics. Our job isn't to out-shout the hype cycles or go nose to nose with the status quo on features and checklists. It's to stay relentlessly focused on honing an opinionated approach, making it easier and easier for engineering teams to understand their software, their product, and their users.\n\nWhat's our north star?\n\n⭐ We aspire to be in the top 10% most AI-enabled, most productive engineering teams at companies of our size and stage.\n\nConcretely, in addition to the company-wide 2x mandate, we have the following near-term goals for EO 2026. These goals are an initial guess and are VERY subject to change as we learn more. We want them to point us in the right direction, not prescriptively tell us where to focus.\n\nBy the end of the year, our systems are safe enough that at least 25% of all PRs are AI-reviewed and auto-merged (with no human review required) while maintaining a change failure rate under 3% (we're close today)\n\nWe maintain our SLOs and don't increase incident response workload outside of sustainable bounds (📉 course correction already needed here)\n\nWe are actively re-shaping how software teams work, such that our jobs continue to be impactful, meaningful, and sustainable\n\nWe are sharing what we learn outside of Honeycomb (e.g., via blog posts, conference talks, social media, etc.)\n\nNote: while the above list of measurable goals focus on code authorship, our goal is to use AI across the software development lifecycle. As we find additional points in the lifecycle to measure, we'll add them to the list above.\n\nFAQ\n\nWhat kind of support can I expect for my AI usage?\n\nExpect the company to provide you with resources like product subscriptions, tokens, and shared best practices, but know that your own continuous experimentation and learning will also be required. If we waited until all aspects of AI-assisted coding and related educational resources were fully baked to invest in, we would miss the boat. This means we all have to participate actively in learning and experimentation together.\n\nAdditionally, we've asked the engineering enablement team to add some AI platform work to its roadmap. This team has a broader charter beyond AI, but we recognize that we need both distributed and centralized efforts to achieve our vision. If there is a particular way our AI-backed tooling could be more robust or AI usage could be easier, this team is probably the right one to share it with; engineering leadership will work with them to continue to add support for the AI platform portion of their work.\n\nHow do I know if my AI usage meets Honeycomb's expectations? How is this measured?\n\nAs with all conversations about, \"Am I meeting expectations for my role?\" or \"How am I performing?\" your first stop is your manager. While we may look at some metrics to understand adoption and usage, there's no specific set of quantitative metrics we expect each person to hit. Your manager can help you understand how you are performing relative to the expectations of your role. That said, sometimes a rough heuristic can help keep us all calibrated. Here is one: aim to have a shareable insight that impacts how you approach future work at least ~1x/mo. We are trying to push boundaries vs trying to play it safe.\n\nAre we headed toward a \"software factory\" approach?\n\nIt's an intriguing approach that's generating a lot of conversation in the industry, and while we want to explore it, we understand that a lot of the patterns and best practices aren't settled yet.\n\nWe expect that across engineering, we've exited the era of \"AI as glorified autocomplete\" and are all making use of agentic workflows, often using multiple agents concurrently. However, the exact patterns that we'll land on as the most impactful and effective over the long term are still up for debate. Our ask is that you help us figure out how we can all be effective at these new higher levels of abstraction, but we don't necessarily yet have prescriptive guidance about the exact patterns we see in the future. Engineering enablement is currently the owner of the next steps here, as part of their developer productivity charter.\n\nShould I be running a certain number of agents at once?\n\nThere are many contributing factors to how many agents anyone should be running, including technical limitations, and the fact that different people's brains work in different ways and dovetail with tools differently. Everyone should put in the time and experimentation to find out where their \"sweet spot\" is. Ultimately, the answer to this question is you should run the number of agents that allows you to deliver impact most effectively, and you should do the work of generating the data to answer that question for yourself.\n\nI see a 200-reply thread about AI usage patterns. Should I participate?\n\nThere is real, meaningful work to be done around creating and defining AI norms and usage patterns. These tools are driving novel human interactions, and getting them right involves conversation, iteration, and deep listening.\n\nThat said, none of us have the job of Professional Slack Responder™, and many of these threads quickly can become circular, sucking up a lot of time and emotional energy without creating forward progress. Nobody is required to participate in these discussions, but if you choose to join in, you are expected to:\n\nBe quick to assign action items and next steps, even if experimental, rather than rehashing a question you've already seen discussed.\n\nMove conversations from Slack to a meeting if you believe the conversation is valuable but it isn't coming to a conclusion.\n\nAsk yourself if you're genuinely moving the conversation forward, vs. venting or engaging just to avoid missing out.\n\nThe workflow challenges that spawn these threads are often very real, but a long Slack thread may not be part of the solution.\n\nBe a responsible steward of your coworkers' and your own time and energy.\n\nMake sure you're doing your first job first.\n\nThere are things about these tools that make my job less satisfying, more stressful, etc. How do I cope with that?\n\nEvery major wave of technological change impacts how we do our work and the satisfaction we may feel from our craft, often in a mix of positive and negative ways. This is very, very true for AI tools and particularly apparent for more autonomous agentic workflows.\n\nIt's not strange to feel a sense of loss or grief as we set down or reduce parts of our job that felt satisfying and prioritize other ways of working. Our ask isn't to pretend those feelings don't exist, but to engage with them head on. We encourage you to take time to experiment to find new ways of working that fit both you and the available tools, and share what's working (and what's not) with your teammates and Honeycomb at large.\n\nIs this just about writing code faster?\n\nNo. We believe there's leverage across the whole lifecycle.\n\nWe encourage you and your teams to spend time experimenting with these tools for use cases beyond code generation, and to make time to talk with each other about how best to collaborate as these tools change your workflows."])</script><script>self.__next_f.push([1,"3c:T1c98,"])</script><script>self.__next_f.push([1,"Sampling is a core skill that everyone who runs an observability pipeline at scale will learn. There are lots of tradeoffs within the various decisions you'll make from reducing bandwidth, CPU, and memory, to reducing costs and making the observability backend's performance better for users.\n\nHistorically, there have only been three mechanisms, each with their own tradeoffs:\n\nHead sampling (configured in your applications)\n\nProbabilistic (random) sampling (configured in your pipeline)\n\nTail sampling (configured in a trace-aware routed Collector)\n\nHowever, there is a secret fourth option: adaptive tail sampling—which changes those tradeoffs.\n\nWe built Refinery (our open source tail sampling proxy) long before OpenTelemetry became the standard for telemetry. It's the most advanced sampling proxy that exists and helps our customers keep the important context without blowing their budgets, even during spikes. Refinery does this by applying sampling rules that change dynamically instead of the more rigid rules you see in the current Collector's tail sampler. It also does a ton of other things like clustering, scaling, routing, etc.\n\nThe downside for us has always been that these ideas aren't mainstream. Users are stuck with rigid static rules from the Collector's tail sampler, or its probabilistic sampler. That means that there's a general sense that tail sampling is bad, rigid, and therefore risky.\n\nAll of this led us to think about how we could help the industry realize the potential of adaptive tail sampling, which brought us to the new adaptive tail sampling component we're donating to the OpenTelemetry Collector.\n\nTL;DR: We're donating our adaptive tail sampler as a processor to OpenTelemetry! If you want to try it out before it reaches the official Collector distributions, you can use our Honeycomb Collector Distribution (see here).\n\nTail sampling vs adaptive tail sampling\n\nThere are many similarities between the existing tail sampling component and the adaptive sampling approach.\n\nBuffering\n\nBoth samplers \"buffer\" spans for a period of time to ensure that it gets as much of the trace context as possible, which allows the samplers to act on the full trace's context instead of the individual span. The adaptive tail sampler has an additional mechanism where the decision fires shortly after the root span has been received (decision_delay, two seconds by default), with a trace_timeout (30 seconds by default) as the safety net for traces that never get one. This can help with CPU and memory pressure, especially for short running requests.\n\nStatic rules\n\nBoth samplers offer static rule evaluation, like \"Keep every trace with an error,\" \"Keep traces whose root span took over 1 second,\" \"Drop all healthcheck endpoint requests.\"\n\nThis also extends to running probabilistic sampling with static rules, like \"Keep only 1 in 10 random requests for the homepage.\"\n\nTrace fingerprinting\n\nThis allows the sampler to be aware of what makes two traces similar, therefore allowing it to ensure that you have coverage of different journeys through your system. Additionally, trace fingerprinting allows you to ensure that requests that would normally be rarely sampled (like a tenant with small volume) are represented in your output. This is a key feature of adaptive sampling.\n\nAs an example, you could identify a trace by all of:\n\nThe set of service names that appear across the trace, and the set of response status codes that appear across the trace\n\nTenant id from the root span\n\nThe http route of the root span\n\nIf a user's request for Checkout took a different path through your system because they applied a discount code, it would be treated differently than one that didn't. In addition, every single tenant in your system would be represented in the sampled data too.\n\nAdaptive sample rates\n\nThis is the real magic of adaptive sampling, and is tied to trace fingerprinting.\n\nEach fingerprint's actual sample rate will vary, because you're applying a \"target\" you want to hit across all fingerprints—either a percentage of traffic or a throughput budget. This is where logarithmic analysis is done over the volumes of each to give us relative sample rates.\n\nThis graph shows that a few fingerprints have a lot more traffic than the others. This could be because they're for the homepage, or just that two big customers are generating more traffic than the others. If we applied a one in 10 sampling rate without fingerprinting, we'd likely miss a lot of the small traffic calls. Conversely, if we did a one in 10 sample rate for each fingerprint, we would potentially miss a lot of the nuance in the large customers.\n\nThe log() function helps by normalizing the volume of each fingerprint, allowing us to have a relative value. We can use it to distribute our one in 10 sample rate over the whole distribution and make sure that we get some data from each.\n\nFurther, there are two ways to express the goal you're adapting toward:\n\nA percentage (adaptive_percentage): For example, keep 10% of overall traffic. The sampler spreads that budget across fingerprints, sampling the busy ones harder and keeping more of the quiet ones.\n\nA throughput (adaptive_throughput): For example, keep around 1000 spans per second. The sampler works out the per-fingerprint rates that hold you to that budget, however traffic spikes.\n\nEither way, the rates recalculate on a regular interval (15s by default, and configurable) so they adapt as your traffic increases or decreases.\n\nThe real power here is cost control. With a throughput goal, even if you get a large spike in traffic, you're not going to be outputting a raw multiple of your platform's volume. And with either goal, if your homepage receives a DDoS attack, the telemetry of your checkout endpoint won't suffer.\n\nSample rate attribution\n\nSampling is now a first class concept in OpenTelemetry, using a tracestate value (ot=th) that carries the sampling threshold, so outputting this from the processor is incredibly useful to tell your backend what a trace represents.\n\nWhen we couple that with the adaptive sample rate, we empower the backend system to show extrapolated data from trace analytics with accuracy.\n\nTry it today with the Honeycomb Collector Distribution\n\nWe're donating the adaptive tail sampling processor to the OpenTelemetry Collector, and it's working its way toward alpha upstream. In the meantime, you can run it today with the Honeycomb Collector Distribution, a drop-in replacement for the Collector contrib image that already bundles the component.\n\nHere's a complete trace pipeline. It receives OTLP, applies two sampling rules, and exports to Honeycomb. The rules are:\n\nThe first keeps every trace where any span has an error status code.\n\nThe second aims to keep 10% of all combinations of service name and HTTP route, so low-traffic routes stay visible while hot routes get downsampled.\n\nTo run it on Kubernetes, use the OpenTelemetry Collector Helm chart and point the image at the Honeycomb distribution:\n\nSave that as values.yaml with the collector config from above under config. Then, add the chart repo and install:\n\nPrefer to try it locally first? Pull the image straight from the distro and pass the same config:\n\nDrop in your config and start playing with the sample rates.\n\nHappy sampling!"])</script><script>self.__next_f.push([1,"3d:T1c98,"])</script><script>self.__next_f.push([1,"Sampling is a core skill that everyone who runs an observability pipeline at scale will learn. There are lots of tradeoffs within the various decisions you'll make from reducing bandwidth, CPU, and memory, to reducing costs and making the observability backend's performance better for users.\n\nHistorically, there have only been three mechanisms, each with their own tradeoffs:\n\nHead sampling (configured in your applications)\n\nProbabilistic (random) sampling (configured in your pipeline)\n\nTail sampling (configured in a trace-aware routed Collector)\n\nHowever, there is a secret fourth option: adaptive tail sampling—which changes those tradeoffs.\n\nWe built Refinery (our open source tail sampling proxy) long before OpenTelemetry became the standard for telemetry. It's the most advanced sampling proxy that exists and helps our customers keep the important context without blowing their budgets, even during spikes. Refinery does this by applying sampling rules that change dynamically instead of the more rigid rules you see in the current Collector's tail sampler. It also does a ton of other things like clustering, scaling, routing, etc.\n\nThe downside for us has always been that these ideas aren't mainstream. Users are stuck with rigid static rules from the Collector's tail sampler, or its probabilistic sampler. That means that there's a general sense that tail sampling is bad, rigid, and therefore risky.\n\nAll of this led us to think about how we could help the industry realize the potential of adaptive tail sampling, which brought us to the new adaptive tail sampling component we're donating to the OpenTelemetry Collector.\n\nTL;DR: We're donating our adaptive tail sampler as a processor to OpenTelemetry! If you want to try it out before it reaches the official Collector distributions, you can use our Honeycomb Collector Distribution (see here).\n\nTail sampling vs adaptive tail sampling\n\nThere are many similarities between the existing tail sampling component and the adaptive sampling approach.\n\nBuffering\n\nBoth samplers \"buffer\" spans for a period of time to ensure that it gets as much of the trace context as possible, which allows the samplers to act on the full trace's context instead of the individual span. The adaptive tail sampler has an additional mechanism where the decision fires shortly after the root span has been received (decision_delay, two seconds by default), with a trace_timeout (30 seconds by default) as the safety net for traces that never get one. This can help with CPU and memory pressure, especially for short running requests.\n\nStatic rules\n\nBoth samplers offer static rule evaluation, like \"Keep every trace with an error,\" \"Keep traces whose root span took over 1 second,\" \"Drop all healthcheck endpoint requests.\"\n\nThis also extends to running probabilistic sampling with static rules, like \"Keep only 1 in 10 random requests for the homepage.\"\n\nTrace fingerprinting\n\nThis allows the sampler to be aware of what makes two traces similar, therefore allowing it to ensure that you have coverage of different journeys through your system. Additionally, trace fingerprinting allows you to ensure that requests that would normally be rarely sampled (like a tenant with small volume) are represented in your output. This is a key feature of adaptive sampling.\n\nAs an example, you could identify a trace by all of:\n\nThe set of service names that appear across the trace, and the set of response status codes that appear across the trace\n\nTenant id from the root span\n\nThe http route of the root span\n\nIf a user's request for Checkout took a different path through your system because they applied a discount code, it would be treated differently than one that didn't. In addition, every single tenant in your system would be represented in the sampled data too.\n\nAdaptive sample rates\n\nThis is the real magic of adaptive sampling, and is tied to trace fingerprinting.\n\nEach fingerprint's actual sample rate will vary, because you're applying a \"target\" you want to hit across all fingerprints—either a percentage of traffic or a throughput budget. This is where logarithmic analysis is done over the volumes of each to give us relative sample rates.\n\nThis graph shows that a few fingerprints have a lot more traffic than the others. This could be because they're for the homepage, or just that two big customers are generating more traffic than the others. If we applied a one in 10 sampling rate without fingerprinting, we'd likely miss a lot of the small traffic calls. Conversely, if we did a one in 10 sample rate for each fingerprint, we would potentially miss a lot of the nuance in the large customers.\n\nThe log() function helps by normalizing the volume of each fingerprint, allowing us to have a relative value. We can use it to distribute our one in 10 sample rate over the whole distribution and make sure that we get some data from each.\n\nFurther, there are two ways to express the goal you're adapting toward:\n\nA percentage (adaptive_percentage): For example, keep 10% of overall traffic. The sampler spreads that budget across fingerprints, sampling the busy ones harder and keeping more of the quiet ones.\n\nA throughput (adaptive_throughput): For example, keep around 1000 spans per second. The sampler works out the per-fingerprint rates that hold you to that budget, however traffic spikes.\n\nEither way, the rates recalculate on a regular interval (15s by default, and configurable) so they adapt as your traffic increases or decreases.\n\nThe real power here is cost control. With a throughput goal, even if you get a large spike in traffic, you're not going to be outputting a raw multiple of your platform's volume. And with either goal, if your homepage receives a DDoS attack, the telemetry of your checkout endpoint won't suffer.\n\nSample rate attribution\n\nSampling is now a first class concept in OpenTelemetry, using a tracestate value (ot=th) that carries the sampling threshold, so outputting this from the processor is incredibly useful to tell your backend what a trace represents.\n\nWhen we couple that with the adaptive sample rate, we empower the backend system to show extrapolated data from trace analytics with accuracy.\n\nTry it today with the Honeycomb Collector Distribution\n\nWe're donating the adaptive tail sampling processor to the OpenTelemetry Collector, and it's working its way toward alpha upstream. In the meantime, you can run it today with the Honeycomb Collector Distribution, a drop-in replacement for the Collector contrib image that already bundles the component.\n\nHere's a complete trace pipeline. It receives OTLP, applies two sampling rules, and exports to Honeycomb. The rules are:\n\nThe first keeps every trace where any span has an error status code.\n\nThe second aims to keep 10% of all combinations of service name and HTTP route, so low-traffic routes stay visible while hot routes get downsampled.\n\nTo run it on Kubernetes, use the OpenTelemetry Collector Helm chart and point the image at the Honeycomb distribution:\n\nSave that as values.yaml with the collector config from above under config. Then, add the chart repo and install:\n\nPrefer to try it locally first? Pull the image straight from the distro and pass the same config:\n\nDrop in your config and start playing with the sample rates.\n\nHappy sampling!"])</script><script>self.__next_f.push([1,"3e:T108d,"])</script><script>self.__next_f.push([1,"A few months ago, Darragh Curran, CTO at Fin (formerly Intercom) set a public goal to double engineering productivity and nearly tripled it instead. They did so by pulling a few levers: AI writing code at scale, building an AI-driven PR review system, leveraging observability as a trust mechanism, and with leadership becoming more hands-on through the transition. \n\nCharity wanted to pick Darragh's brain on the messy bits, not just the highlight reel, so she invited him to participate in our first episode of Leading With Observability, a digestible video series for us folks with the attention span of a goldfish—think 15-minute (ish) webinars.\n\nWatch the interview\n\nDon't have 16 minutes? Keep reading below for a short recap on the conversation.\n\nDo a thing. Learn. Do the next thing.\n\nFor those of you who missed it, Darragh contributed to a chapter in Observability Engineering (grab a free copy of the book today) on what observability looks like from a leadership perspective. In his section, A Letter From a CTO, he gives advice to engineering teams on how to attain excellence, and it ends with a rather simple loop: “Do a thing, learn something, do the next thing. That is a core function of a software team. Pair it with vision and product judgment, and you can build great products fast. That simple loop is how I think about our jobs. Understand a problem, solve it quickly, figure out did you actually solve it, rinse and repeat,” said Darragh. \n\n“Hopefully most companies are similar in some respect, like that core framework of ‘What do we care about and how do we improve it?’ What's maybe a little bit different is just how much that's been entrenched in our DNA and trying to, as much as possible, weed out all of the things that get in the way of ‘Try a thing, learn a thing,’” he continued.\n\n2x? No, closer to 3x.\n\nBack in April, Darragh made a public commitment to increase R\u0026D productivity by 2x. When Charity asked him what led him to making such a public statement, Darragh explained that it reinforced to the team that he was serious. He also wanted to provoke more dialogue in the industry and inspire others.\n\n“The world is different,” Darragh said. “The tools we have and how we approach our work is hopefully evolving to that new world. My rough mental model is continual doubling. We all know what happens when you keep doing that. We should be thinking of our ceiling as 100x what it is today, not 3 or 4x.”\n\nWhere observability fits\n\nFin went from humans reviewing every PR to a meaningful share shipping with no human reviewer. Their approach was to mine and harvest the best feedback from their best people on each dimension and to build a system that could reliably do that. To quote Kesha’s blog post, he says, “A human reviewer typically focuses on the actual code changes, the diff. Our agent goes deeper. It traces execution paths, following the implications of a change through the codebase. This is something humans rarely had time to do, even when they wanted to.” It's not just faster, it's safer—and any human can pull the cord at any time to trigger human review.\n\nAs Darragh explained, “You've got unbounded capacity. You're not human-scale limited. There's brilliant things that humans bring to the picture, but our mental model specifically for review was, ‘How can we bring the best parts of our best people to every review?’ [...] And what if you had all of those people on their best day with infinite patience looking at your code? Obviously you could never do that before. You'd get nothing done. But you can do it now.”\n\nDarragh continued, “Kesha and others have gone into a bunch of depth [on observability], but at a high level, measurement was so core to the approach. We had this intuition that if the review quality is below some threshold, people will tune out of it. So we had a high bar we needed to hit. We didn't wanna lose trust in the start. On every dimension then observability is important to help you spot the places you got it wrong and continue to tune the system right down to, ‘Hey, this is too slow or too expensive,’ or what happens when it goes wrong and all of a sudden people's workflow is interrupted.”"])</script><script>self.__next_f.push([1,"3f:T108d,"])</script><script>self.__next_f.push([1,"A few months ago, Darragh Curran, CTO at Fin (formerly Intercom) set a public goal to double engineering productivity and nearly tripled it instead. They did so by pulling a few levers: AI writing code at scale, building an AI-driven PR review system, leveraging observability as a trust mechanism, and with leadership becoming more hands-on through the transition. \n\nCharity wanted to pick Darragh's brain on the messy bits, not just the highlight reel, so she invited him to participate in our first episode of Leading With Observability, a digestible video series for us folks with the attention span of a goldfish—think 15-minute (ish) webinars.\n\nWatch the interview\n\nDon't have 16 minutes? Keep reading below for a short recap on the conversation.\n\nDo a thing. Learn. Do the next thing.\n\nFor those of you who missed it, Darragh contributed to a chapter in Observability Engineering (grab a free copy of the book today) on what observability looks like from a leadership perspective. In his section, A Letter From a CTO, he gives advice to engineering teams on how to attain excellence, and it ends with a rather simple loop: “Do a thing, learn something, do the next thing. That is a core function of a software team. Pair it with vision and product judgment, and you can build great products fast. That simple loop is how I think about our jobs. Understand a problem, solve it quickly, figure out did you actually solve it, rinse and repeat,” said Darragh. \n\n“Hopefully most companies are similar in some respect, like that core framework of ‘What do we care about and how do we improve it?’ What's maybe a little bit different is just how much that's been entrenched in our DNA and trying to, as much as possible, weed out all of the things that get in the way of ‘Try a thing, learn a thing,’” he continued.\n\n2x? No, closer to 3x.\n\nBack in April, Darragh made a public commitment to increase R\u0026D productivity by 2x. When Charity asked him what led him to making such a public statement, Darragh explained that it reinforced to the team that he was serious. He also wanted to provoke more dialogue in the industry and inspire others.\n\n“The world is different,” Darragh said. “The tools we have and how we approach our work is hopefully evolving to that new world. My rough mental model is continual doubling. We all know what happens when you keep doing that. We should be thinking of our ceiling as 100x what it is today, not 3 or 4x.”\n\nWhere observability fits\n\nFin went from humans reviewing every PR to a meaningful share shipping with no human reviewer. Their approach was to mine and harvest the best feedback from their best people on each dimension and to build a system that could reliably do that. To quote Kesha’s blog post, he says, “A human reviewer typically focuses on the actual code changes, the diff. Our agent goes deeper. It traces execution paths, following the implications of a change through the codebase. This is something humans rarely had time to do, even when they wanted to.” It's not just faster, it's safer—and any human can pull the cord at any time to trigger human review.\n\nAs Darragh explained, “You've got unbounded capacity. You're not human-scale limited. There's brilliant things that humans bring to the picture, but our mental model specifically for review was, ‘How can we bring the best parts of our best people to every review?’ [...] And what if you had all of those people on their best day with infinite patience looking at your code? Obviously you could never do that before. You'd get nothing done. But you can do it now.”\n\nDarragh continued, “Kesha and others have gone into a bunch of depth [on observability], but at a high level, measurement was so core to the approach. We had this intuition that if the review quality is below some threshold, people will tune out of it. So we had a high bar we needed to hit. We didn't wanna lose trust in the start. On every dimension then observability is important to help you spot the places you got it wrong and continue to tune the system right down to, ‘Hey, this is too slow or too expensive,’ or what happens when it goes wrong and all of a sudden people's workflow is interrupted.”"])</script><script>self.__next_f.push([1,"40:T3a4d,"])</script><script>self.__next_f.push([1,"There isn't one obvious Datadog replacement. The right choice starts with why you're considering a switch: You may want observability costs that are easier to forecast as telemetry grows, your engineers may spend too much time connecting separate signals, or you may want instrumentation that stays portable between backends.\n\nAI and agent workloads make each concern more significant. Agents add model calls, tools, retrieval, high-cardinality context, and unpredictable production behavior.\n\nThis guide compares seven Datadog alternatives against those needs. We cover production investigation, AI depth, telemetry economics, OpenTelemetry, deployment, and platform scope.\n\nKey takeaways\n\nTeams often explore Datadog alternatives for three related reasons: cost predictability, fragmented investigations, and instrumentation portability.\n\nHoneycomb is a strong Datadog replacement for teams prioritizing production observability, high-cardinality investigation, and OpenTelemetry adoption.\n\nAI raises the stakes because agents introduce more context, more unpredictable behavior, and more possible failure points across production.\n\nWhy teams look for Datadog alternatives as AI workloads grow\n\nAI doesn't create every reason to reconsider your observability platform. It makes existing tradeoffs harder to ignore.\n\nThree concerns belong near the top of the evaluation:\n\nTelemetry economics: Production systems generate more telemetry as services, users, and AI workflows grow. Your pricing model determines how much context you can afford to retain and investigate.\n\nInvestigation complexity: Debugging becomes harder when engineers must reconstruct a single production problem across separate signals, tools, or workflows.\n\nInstrumentation portability: OpenTelemetry gives teams more control over instrumentation. The practical question is which platform capabilities remain available without proprietary collection or schemas.\n\nAI adds another layer to each issue.\n\nOne request may involve agents, models, retrieval steps, tool calls, retries, and downstream services. Similar inputs can also produce different outputs, and that unpredictability creates more unknown-unknowns: production behaviors you couldn’t define in a dashboard or alert beforehand.\n\nEngineers may need to investigate by user, session, prompt version, model, tool, tenant, or outcome. Those fields often contain thousands of values.\n\nThe replacement should allow engineers to explore those dimensions when the question arises, and it should preserve enough context to explain what happened.\n\nOpenTelemetry can help keep instrumentation independent from the backend. Its Collector can export telemetry to multiple destinations.\n\nHoneycomb's OpenTelemetry-native platform supports an open instrumentation approach across application and AI telemetry.\n\nWhat to look for in a Datadog alternative for AI and agent observability\n\nA useful shortlist starts with the problems you want the replacement to solve. Feature counts rarely show how production investigations work. Use the below questions to compare platforms.\n\nCan you investigate unknown-unknowns across AI and application behavior?\n\nAn AI request rarely stays inside the model layer. It may touch APIs, databases, queues, vector stores, external services, and several agents. Your observability platform should let you investigate that behavior without knowing in advance which dimension will matter.\n\nConversation views explain how an agent behaved. Distributed tracing explains how that behavior moved through the production system. Production teams often need both.\n\nCan you retain useful context without making costs harder to control?\n\nRich telemetry only helps when teams can afford to keep and investigate it. AI workloads can add prompts, models, tools, users, sessions, evaluations, tokens, and other dimensions.\n\nCompare how each platform charges. Then, model the cost using your expected production volume.\n\nPay attention to incentives. A pricing model can influence whether engineers keep useful context or remove it to control spending.\n\nHow deep are the AI evaluation and quality workflows?\n\nSystem health tells you whether a request completed. It cannot tell you whether the answer was useful.\n\nFocused AI platforms may offer deeper evaluation and experimentation features.\n\nBroader production observability platforms may connect a poor result to problems outside the model layer.\n\nPrioritize the workflow creating the biggest investigation gap for your team.\n\nHow portable is your telemetry, and how much platform breadth do you need?\n\nOpenTelemetry, a vendor-neutral framework, can reduce instrumentation dependence. It does not make every backend interchangeable. Ask which capabilities work with standard OpenTelemetry data, then identify anything that still requires vendor-specific instrumentation or schemas.\n\nDecide how much platform breadth you actually need. A broad suite may span infrastructure, applications, security, and AI, while a focused platform may go deeper on fewer engineering workflows.\n\nThe important question is whether that scope matches the Datadog workloads you actually plan to replace.\n\nBest Datadog alternatives for AI and agent observability\n\nThese seven platforms cover three common paths: broad suites, connected production debugging, and focused AI engineering.\n\nThis list is not a ranking. Each platform fits a different mix of workloads, operating models, and investigation needs. Use these entries to compare strengths, tradeoffs, and fit before building your shortlist.\n\n1. Honeycomb\n\nBest for: Teams replacing Datadog with an OpenTelemetry-based observability platform built for exploratory investigation across application and AI telemetry.\n\nWhy it stands out: Honeycomb's event-based data model keeps rich production context queryable. Engineers can investigate high-cardinality fields without choosing every important dimension before something breaks. BubbleUp helps surface attributes that distinguish unusual behavior from normal requests.\n\nAI and agent investigation: Agent Timeline adds conversation-level context for multi-agent workflows. Engineers can inspect model calls, tools, handoffs, failures, tokens, and related application spans.\n\nOpen instrumentation: Honeycomb is built around OpenTelemetry. Teams can keep instrumentation portable while connecting AI spans with the wider production request path. Learn more about Honeycomb and OpenTelemetry.\n\nTelemetry economics: Honeycomb prices real-time telemetry around event volume. Current plans include unlimited custom fields, seats, and querying. This lets teams add investigation context without pricing each additional field separately. See Honeycomb pricing.\n\nProof in practice: Birdie replaced Datadog with Honeycomb and reported 50% observability budget savings. The team also consolidated seven tools and reduced root-cause identification to about five minutes. Read the Birdie case study.\n\nPrimary consideration: Honeycomb focuses on software production and engineering investigation. Evaluate broader security or IT operations requirements separately if they are part of your Datadog footprint.\n\n2. New Relic\n\nBest for: Teams wanting AI monitoring inside an established full-stack SaaS observability platform.\n\nWhy it stands out: New Relic connects AI monitoring with its application performance monitoring agents. It tracks model performance, cost, tokens, response details, and user feedback.\n\nKey strengths: Agent monitoring traces agent invocations, tool calls, handoffs, and related services. Its entity map and trace waterfall show where latency or errors entered the workflow.\n\nPrimary consideration: At the time of writing, New Relic labels agent monitoring as a preview feature. Confirm supported frameworks, release status, and production requirements during evaluation.\n\n3. Dynatrace\n\nBest for: Large enterprises connecting AI observability with application, infrastructure, automation, security, and governance work.\n\nWhy it stands out: Dynatrace AI observability includes overview, exploration, prompts, agent topology, and evaluation views. Teams can ingest data through OneAgent, OpenTelemetry, OpenInference, or OpenLLMetry.\n\nKey strengths: Dynatrace connects AI behavior with downstream effects on applications and infrastructure. It also supports LLM-as-a-judge evaluations and custom evaluators. At the time of writing, its Evaluation method library for managing custom evaluators is in preview.\n\nPrimary consideration: Confirm licensing, ingestion requirements, deployment choices, and rollout scope. The right path depends on existing Dynatrace use and enterprise controls. Test permissions and cross-team workflows early. This approach can suit centralized platform and governance teams.\n\n4. Grafana Cloud\n\nBest for: Teams already invested in Grafana, OpenTelemetry, and a composable observability stack.\n\nWhy it stands out: Grafana Cloud AI Observability covers LLMs, evaluations, vector databases, GPUs, and MCP. Its agent experience organizes generations into conversations and tracks agent versions.\n\nKey strengths: Teams can connect agent logs with OpenTelemetry trace and span identifiers. Grafana also supports continuous quality evaluation and cost tracking. This can connect model behavior with vector, GPU, and protocol dependencies.\n\nPrimary consideration: Confirm how AI Observability, Agent Observability, and existing Grafana components fit together. Decide which parts your team will manage. Test setup effort for every required data source.\n\n5. Arize Phoenix\n\nBest for: AI and machine learning teams focused on LLM tracing, evaluations, retrieval analysis, experiments, and model quality.\n\nWhy it stands out: Phoenix is an open-source AI observability platform built on OpenTelemetry. It captures LLM calls, tool execution, retrieval, generation, sessions, latency, and token use.\n\nKey strengths: Annotations measure quality, while sessions group related conversations. Phoenix also supports trace evaluations and retrieval-augmented generation analysis. Its open-source design supports custom deployment and data-control needs.\n\nPrimary consideration: Phoenix centers on AI application behavior. Plan how host, network, and general service telemetry will connect with your wider toolset. Test how teams will correlate Phoenix traces with non-AI incidents.\n\n6. Langfuse\n\nBest for: Teams seeking an open, self-hostable platform for LLM tracing, evaluations, prompt management, experiments, and cost analysis.\n\nWhy it stands out: Langfuse understands model parameters, prompts, completions, scores, tokens, and costs. It supports online evaluations, offline experiments, datasets, human review, and LLM-as-a-judge workflows.\n\nKey strengths: Prompt versions can link directly to traces and evaluation metrics. Experiments compare prompts, models, and code variants against shared datasets. Current trace ingestion supports OpenTelemetry, and teams can run Langfuse themselves.\n\nPrimary consideration: Langfuse targets AI engineering rather than general application performance monitoring. Most teams will pair it with broader service and infrastructure coverage. Define that handoff before the proof of concept.\n\n7. SigNoz\n\nBest for: Teams seeking an OpenTelemetry-native, open-source alternative to Datadog with full-stack and AI monitoring.\n\nWhy it stands out: SigNoz combines application performance monitoring, logs, metrics, traces, dashboards, alerts, and LLM monitoring. It supports cloud and self-hosted deployment.\n\nKey strengths: Current guides cover agent reasoning, tool calls, chain execution, and model responses, all of which use OpenTelemetry and OpenInference. Teams can correlate those traces with logs and services.\n\nPrimary consideration: Compare its evaluation and prompt workflows to those of focused AI tools. Self-hosting also adds operating and upgrade work.\n\nSigNoz may suit teams seeking open-source control without having to assemble separate telemetry backends.\n\nLearn more about the production questions behind AI and LLM observability.\n\nHow to shortlist and test a Datadog alternative\n\nStart with the reason you're considering a switch, then choose two or three platforms that address that problem directly.\n\nIf investigation is too fragmented: Include Honeycomb, New Relic, and Dynatrace. Compare how each moves from a symptom to its production cause.\n\nSuppose costs are the problem: Model Honeycomb and other candidates against your real telemetry. Include fields, queries, retention, seats, and expected growth.\n\nIf instrumentation portability matters: Compare OpenTelemetry support carefully. Honeycomb centers its instrumentation strategy on OpenTelemetry. Grafana Cloud and SigNoz also deserve consideration.\n\nIf AI evaluation depth is the priority: Include Phoenix or Langfuse. Add Honeycomb when those AI workflows must stay connected to the wider application.\n\nIf you need to replace broader Datadog workloads: Include Honeycomb for production engineering observability. Compare other platforms according to your infrastructure, security, and IT operations requirements.\n\nUse a single representative-agent workflow for the test. Include retrieval, tool calls, application services, and a known failure mode.\n\nMeasure how quickly each platform answers five questions:\n\nWhich request or conversation failed?\n\nWhich model, prompt, agent, or tool was involved?\n\nWhere did latency or cost increase?\n\nDid a downstream service cause the symptom?\n\nCan another engineer reproduce the investigation?\n\nAlso compare retention, data controls, query speed, operating work, and estimated production cost.\n\nDual-send OpenTelemetry data when practical. The Collector can export the same telemetry to multiple destinations.\n\nTest the production problem that made you consider leaving Datadog. A polished demo will tell you much less.\n\nRecord the same investigation with each platform. Compare the time to the first useful hypothesis and the time to the verified cause.\n\nInclude one privacy-sensitive path. Verify filtering, access controls, and prompt-content handling before production.\n\nSee how Honeycomb compares with Datadog\n\nIf you're considering leaving Datadog, make sure the replacement fixes the problem that prompted you to look for a replacement.\n\nMaybe observability spending has become difficult to forecast. Maybe investigations require too much movement between signals. Or perhaps you want instrumentation that stays portable.\n\nAI makes those pressures more important. More production context and less predictable behavior create more ways for something unexpected to happen.\n\nHoneycomb approaches that problem with an event-based data model, high-cardinality investigation, OpenTelemetry instrumentation, and event-volume pricing. Agent telemetry lives inside that same production investigation model.\n\nFor a closer look at the differences, explore our Honeycomb vs. Datadog comparison."])</script><script>self.__next_f.push([1,"41:T3a4d,"])</script><script>self.__next_f.push([1,"There isn't one obvious Datadog replacement. The right choice starts with why you're considering a switch: You may want observability costs that are easier to forecast as telemetry grows, your engineers may spend too much time connecting separate signals, or you may want instrumentation that stays portable between backends.\n\nAI and agent workloads make each concern more significant. Agents add model calls, tools, retrieval, high-cardinality context, and unpredictable production behavior.\n\nThis guide compares seven Datadog alternatives against those needs. We cover production investigation, AI depth, telemetry economics, OpenTelemetry, deployment, and platform scope.\n\nKey takeaways\n\nTeams often explore Datadog alternatives for three related reasons: cost predictability, fragmented investigations, and instrumentation portability.\n\nHoneycomb is a strong Datadog replacement for teams prioritizing production observability, high-cardinality investigation, and OpenTelemetry adoption.\n\nAI raises the stakes because agents introduce more context, more unpredictable behavior, and more possible failure points across production.\n\nWhy teams look for Datadog alternatives as AI workloads grow\n\nAI doesn't create every reason to reconsider your observability platform. It makes existing tradeoffs harder to ignore.\n\nThree concerns belong near the top of the evaluation:\n\nTelemetry economics: Production systems generate more telemetry as services, users, and AI workflows grow. Your pricing model determines how much context you can afford to retain and investigate.\n\nInvestigation complexity: Debugging becomes harder when engineers must reconstruct a single production problem across separate signals, tools, or workflows.\n\nInstrumentation portability: OpenTelemetry gives teams more control over instrumentation. The practical question is which platform capabilities remain available without proprietary collection or schemas.\n\nAI adds another layer to each issue.\n\nOne request may involve agents, models, retrieval steps, tool calls, retries, and downstream services. Similar inputs can also produce different outputs, and that unpredictability creates more unknown-unknowns: production behaviors you couldn’t define in a dashboard or alert beforehand.\n\nEngineers may need to investigate by user, session, prompt version, model, tool, tenant, or outcome. Those fields often contain thousands of values.\n\nThe replacement should allow engineers to explore those dimensions when the question arises, and it should preserve enough context to explain what happened.\n\nOpenTelemetry can help keep instrumentation independent from the backend. Its Collector can export telemetry to multiple destinations.\n\nHoneycomb's OpenTelemetry-native platform supports an open instrumentation approach across application and AI telemetry.\n\nWhat to look for in a Datadog alternative for AI and agent observability\n\nA useful shortlist starts with the problems you want the replacement to solve. Feature counts rarely show how production investigations work. Use the below questions to compare platforms.\n\nCan you investigate unknown-unknowns across AI and application behavior?\n\nAn AI request rarely stays inside the model layer. It may touch APIs, databases, queues, vector stores, external services, and several agents. Your observability platform should let you investigate that behavior without knowing in advance which dimension will matter.\n\nConversation views explain how an agent behaved. Distributed tracing explains how that behavior moved through the production system. Production teams often need both.\n\nCan you retain useful context without making costs harder to control?\n\nRich telemetry only helps when teams can afford to keep and investigate it. AI workloads can add prompts, models, tools, users, sessions, evaluations, tokens, and other dimensions.\n\nCompare how each platform charges. Then, model the cost using your expected production volume.\n\nPay attention to incentives. A pricing model can influence whether engineers keep useful context or remove it to control spending.\n\nHow deep are the AI evaluation and quality workflows?\n\nSystem health tells you whether a request completed. It cannot tell you whether the answer was useful.\n\nFocused AI platforms may offer deeper evaluation and experimentation features.\n\nBroader production observability platforms may connect a poor result to problems outside the model layer.\n\nPrioritize the workflow creating the biggest investigation gap for your team.\n\nHow portable is your telemetry, and how much platform breadth do you need?\n\nOpenTelemetry, a vendor-neutral framework, can reduce instrumentation dependence. It does not make every backend interchangeable. Ask which capabilities work with standard OpenTelemetry data, then identify anything that still requires vendor-specific instrumentation or schemas.\n\nDecide how much platform breadth you actually need. A broad suite may span infrastructure, applications, security, and AI, while a focused platform may go deeper on fewer engineering workflows.\n\nThe important question is whether that scope matches the Datadog workloads you actually plan to replace.\n\nBest Datadog alternatives for AI and agent observability\n\nThese seven platforms cover three common paths: broad suites, connected production debugging, and focused AI engineering.\n\nThis list is not a ranking. Each platform fits a different mix of workloads, operating models, and investigation needs. Use these entries to compare strengths, tradeoffs, and fit before building your shortlist.\n\n1. Honeycomb\n\nBest for: Teams replacing Datadog with an OpenTelemetry-based observability platform built for exploratory investigation across application and AI telemetry.\n\nWhy it stands out: Honeycomb's event-based data model keeps rich production context queryable. Engineers can investigate high-cardinality fields without choosing every important dimension before something breaks. BubbleUp helps surface attributes that distinguish unusual behavior from normal requests.\n\nAI and agent investigation: Agent Timeline adds conversation-level context for multi-agent workflows. Engineers can inspect model calls, tools, handoffs, failures, tokens, and related application spans.\n\nOpen instrumentation: Honeycomb is built around OpenTelemetry. Teams can keep instrumentation portable while connecting AI spans with the wider production request path. Learn more about Honeycomb and OpenTelemetry.\n\nTelemetry economics: Honeycomb prices real-time telemetry around event volume. Current plans include unlimited custom fields, seats, and querying. This lets teams add investigation context without pricing each additional field separately. See Honeycomb pricing.\n\nProof in practice: Birdie replaced Datadog with Honeycomb and reported 50% observability budget savings. The team also consolidated seven tools and reduced root-cause identification to about five minutes. Read the Birdie case study.\n\nPrimary consideration: Honeycomb focuses on software production and engineering investigation. Evaluate broader security or IT operations requirements separately if they are part of your Datadog footprint.\n\n2. New Relic\n\nBest for: Teams wanting AI monitoring inside an established full-stack SaaS observability platform.\n\nWhy it stands out: New Relic connects AI monitoring with its application performance monitoring agents. It tracks model performance, cost, tokens, response details, and user feedback.\n\nKey strengths: Agent monitoring traces agent invocations, tool calls, handoffs, and related services. Its entity map and trace waterfall show where latency or errors entered the workflow.\n\nPrimary consideration: At the time of writing, New Relic labels agent monitoring as a preview feature. Confirm supported frameworks, release status, and production requirements during evaluation.\n\n3. Dynatrace\n\nBest for: Large enterprises connecting AI observability with application, infrastructure, automation, security, and governance work.\n\nWhy it stands out: Dynatrace AI observability includes overview, exploration, prompts, agent topology, and evaluation views. Teams can ingest data through OneAgent, OpenTelemetry, OpenInference, or OpenLLMetry.\n\nKey strengths: Dynatrace connects AI behavior with downstream effects on applications and infrastructure. It also supports LLM-as-a-judge evaluations and custom evaluators. At the time of writing, its Evaluation method library for managing custom evaluators is in preview.\n\nPrimary consideration: Confirm licensing, ingestion requirements, deployment choices, and rollout scope. The right path depends on existing Dynatrace use and enterprise controls. Test permissions and cross-team workflows early. This approach can suit centralized platform and governance teams.\n\n4. Grafana Cloud\n\nBest for: Teams already invested in Grafana, OpenTelemetry, and a composable observability stack.\n\nWhy it stands out: Grafana Cloud AI Observability covers LLMs, evaluations, vector databases, GPUs, and MCP. Its agent experience organizes generations into conversations and tracks agent versions.\n\nKey strengths: Teams can connect agent logs with OpenTelemetry trace and span identifiers. Grafana also supports continuous quality evaluation and cost tracking. This can connect model behavior with vector, GPU, and protocol dependencies.\n\nPrimary consideration: Confirm how AI Observability, Agent Observability, and existing Grafana components fit together. Decide which parts your team will manage. Test setup effort for every required data source.\n\n5. Arize Phoenix\n\nBest for: AI and machine learning teams focused on LLM tracing, evaluations, retrieval analysis, experiments, and model quality.\n\nWhy it stands out: Phoenix is an open-source AI observability platform built on OpenTelemetry. It captures LLM calls, tool execution, retrieval, generation, sessions, latency, and token use.\n\nKey strengths: Annotations measure quality, while sessions group related conversations. Phoenix also supports trace evaluations and retrieval-augmented generation analysis. Its open-source design supports custom deployment and data-control needs.\n\nPrimary consideration: Phoenix centers on AI application behavior. Plan how host, network, and general service telemetry will connect with your wider toolset. Test how teams will correlate Phoenix traces with non-AI incidents.\n\n6. Langfuse\n\nBest for: Teams seeking an open, self-hostable platform for LLM tracing, evaluations, prompt management, experiments, and cost analysis.\n\nWhy it stands out: Langfuse understands model parameters, prompts, completions, scores, tokens, and costs. It supports online evaluations, offline experiments, datasets, human review, and LLM-as-a-judge workflows.\n\nKey strengths: Prompt versions can link directly to traces and evaluation metrics. Experiments compare prompts, models, and code variants against shared datasets. Current trace ingestion supports OpenTelemetry, and teams can run Langfuse themselves.\n\nPrimary consideration: Langfuse targets AI engineering rather than general application performance monitoring. Most teams will pair it with broader service and infrastructure coverage. Define that handoff before the proof of concept.\n\n7. SigNoz\n\nBest for: Teams seeking an OpenTelemetry-native, open-source alternative to Datadog with full-stack and AI monitoring.\n\nWhy it stands out: SigNoz combines application performance monitoring, logs, metrics, traces, dashboards, alerts, and LLM monitoring. It supports cloud and self-hosted deployment.\n\nKey strengths: Current guides cover agent reasoning, tool calls, chain execution, and model responses, all of which use OpenTelemetry and OpenInference. Teams can correlate those traces with logs and services.\n\nPrimary consideration: Compare its evaluation and prompt workflows to those of focused AI tools. Self-hosting also adds operating and upgrade work.\n\nSigNoz may suit teams seeking open-source control without having to assemble separate telemetry backends.\n\nLearn more about the production questions behind AI and LLM observability.\n\nHow to shortlist and test a Datadog alternative\n\nStart with the reason you're considering a switch, then choose two or three platforms that address that problem directly.\n\nIf investigation is too fragmented: Include Honeycomb, New Relic, and Dynatrace. Compare how each moves from a symptom to its production cause.\n\nSuppose costs are the problem: Model Honeycomb and other candidates against your real telemetry. Include fields, queries, retention, seats, and expected growth.\n\nIf instrumentation portability matters: Compare OpenTelemetry support carefully. Honeycomb centers its instrumentation strategy on OpenTelemetry. Grafana Cloud and SigNoz also deserve consideration.\n\nIf AI evaluation depth is the priority: Include Phoenix or Langfuse. Add Honeycomb when those AI workflows must stay connected to the wider application.\n\nIf you need to replace broader Datadog workloads: Include Honeycomb for production engineering observability. Compare other platforms according to your infrastructure, security, and IT operations requirements.\n\nUse a single representative-agent workflow for the test. Include retrieval, tool calls, application services, and a known failure mode.\n\nMeasure how quickly each platform answers five questions:\n\nWhich request or conversation failed?\n\nWhich model, prompt, agent, or tool was involved?\n\nWhere did latency or cost increase?\n\nDid a downstream service cause the symptom?\n\nCan another engineer reproduce the investigation?\n\nAlso compare retention, data controls, query speed, operating work, and estimated production cost.\n\nDual-send OpenTelemetry data when practical. The Collector can export the same telemetry to multiple destinations.\n\nTest the production problem that made you consider leaving Datadog. A polished demo will tell you much less.\n\nRecord the same investigation with each platform. Compare the time to the first useful hypothesis and the time to the verified cause.\n\nInclude one privacy-sensitive path. Verify filtering, access controls, and prompt-content handling before production.\n\nSee how Honeycomb compares with Datadog\n\nIf you're considering leaving Datadog, make sure the replacement fixes the problem that prompted you to look for a replacement.\n\nMaybe observability spending has become difficult to forecast. Maybe investigations require too much movement between signals. Or perhaps you want instrumentation that stays portable.\n\nAI makes those pressures more important. More production context and less predictable behavior create more ways for something unexpected to happen.\n\nHoneycomb approaches that problem with an event-based data model, high-cardinality investigation, OpenTelemetry instrumentation, and event-volume pricing. Agent telemetry lives inside that same production investigation model.\n\nFor a closer look at the differences, explore our Honeycomb vs. Datadog comparison."])</script><script>self.__next_f.push([1,"42:T1fcf,"])</script><script>self.__next_f.push([1,"It's been almost exactly one year since we issued our AI mandate here at Honeycomb, and we've been doing some reflection.\n\nWhen we issued our mandate, it's not like we hadn't been using AI. We were the first in the industry to bake a feature powered by AI into our product, way back in May of 2024. Many of us had been experimenting and using these tools in our spare time.\n\nBut we believe that software is the killer app for AI. We believe that the way we build and maintain software is in the middle of a generational upheaval. We believe this is existential for us, and for our users. We had to take AI out of our spare time and put it front and center. We had to fund the change and make time for all of us to level up.\n\nAnd level up we have.\n\nWhat a year of this actually produced\n\nYou are starting to see us release quite a lot of material about what we have learned and what has happened as a result. Just in the past month, this includes:\n\n30 to 70 PRs a Day: How We Managed Not to Wreck Our Systems, by Liz Fong-Jones\n\nAI Amplifies Your Existing Practices: Lessons from Our Shift to an AI-First Strategy, by Liz Fong-Jones\n\nEmbracing the Code Review Bottleneck, by Fred Hebert\n\nWhat Comes After Observability?, by Austin Parker\n\nSpend More Time Talking to Humans, by Doug Soo\n\nHow I Support Humans in the AI Era, by Ileanell Perez\n\n... with many more sociotechnical topics in the pipeline to come.\n\nAI is not special\n\nEvery one of those posts arrives at the same place from a different direction, and it's the thing we have returned to so many times that it stopped feeling like an insight and started feeling like a law of physics.\n\nAI is not special, it is just a tool. AI amplifies what is already there.\n\nTeams with strong learning culture and real ownership get faster and better. Teams that were already shipping slop now ship slop at a truly magnificent scale. Orgs with clear values apply them harder, and orgs without them find out. It doesn't fix you, and it doesn't ruin you. It turns the volume up on whatever you already were, which is a great deal less exciting than either the doomers or the boosters would like, and considerably more useful.\n\nWe sat down to write about AI and wrote about ourselves\n\nHoneycomb has always been a company founded on values, first principles, and the stubborn conviction that technology can be so much better than what people are used to.\n\nAfter many intense internal debates about the ethics of using AI, we decided to write down a set of AI norms and values for ourselves. And again and again we found ourselves circling back to the same discovery: this isn't about AI, it's about us. How are our values being stressed in the era of AI? How do our standards apply, how must our principles adapt?\n\nThree documents emerged from this process, and we'll share all of them with you over the next few days: one on how we use AI together at the company level, one for engineering that lays out our reasons for adopting AI along with north star goal and what support people can expect, and this one.\n\nThe one I'm publishing first is called “How Honeycomb Does Business,” written by Manny Alves, SVP of Sales and long time honeybee. It was written for our go-to-market (GTM) teams to sum up our approach to customers and business, but it applies to everyone. “We treat customers like people, not pipeline.” I could not love it more.\n\nValues are not supposed to be aspirational slogans on the wall. Values should codify how things actually work at your company, when people are working well together, which should be most of the time. This is what that looks like.\n\nHow Honeycomb Does Business\n\nHoneycomb has ambitious goals, and we want to win. We also care deeply about how we win.\n\nOur reputation as a thoughtful, technical, customer-focused company is one of our greatest assets. Every interaction with a prospect or customer either reinforces that reputation or takes something away from it.\n\nThis isn't about being less commercial. We should compete hard, negotiate well, create urgency, ask for commitments, and get paid fairly for the value we create. We want to build a business where Honeycomb wins because our customers win too.\n\nAI doesn't create a new standard for how we conduct business. It raises the stakes on standards we've always had. These tools make it easier to communicate, personalize, analyze, and produce at scale. They also make it easier to be careless, impersonal, overwhelming, or deceptive at scale. We want the former without becoming the latter.\n\nThese are the principles we expect our GTM (go-to-market) teams to operate by.\n\nWe create value before we extract value. We want Honeycomb to win because the customer is winning too. We should charge fairly for the value we create, but we don't optimize for extracting every possible dollar from a customer. A great commercial relationship should feel like a good deal on both sides.\n\nWe treat customers like people, not pipeline. We respect their time, understand what they're trying to accomplish, listen before prescribing, and communicate like humans. This starts with the very first interaction. Personalization isn't inserting someone's name and company into an AI-generated email. There should be a reason we're reaching out and something useful behind it.\n\nWe tell the truth, even when it makes the deal harder. We don't misrepresent what Honeycomb can do, hide meaningful limitations, manufacture false urgency, or tell customers what we think they want to hear. Sometimes the right answer is “we don't do that today,” “we're probably not the right solution,” or “I don't know, let me find out.” Trust matters more than any individual transaction.\n\nWe earn the right to ask. Selling requires asking people to do things: take a meeting, bring in an executive, spend time on a POC, commit to a timeline, sign a contract, introduce us to another team. We shouldn't be afraid to ask, but there should be value and reciprocity behind the ask. If we're asking a customer for their time, money, or political capital, we should understand what they're getting in return.\n\nWe compete hard without compromising who we are. Being customer-friendly doesn't mean being commercially passive. We should negotiate confidently, defend our value, challenge customers when appropriate, create urgency, hold people accountable to commitments, and ask for the business. We want to win, but we don't need to manipulate, mislead, or take advantage of customers to do it.\n\nWe respect the cost of other people's attention. AI has made producing things cheap, but it hasn't made consuming them cheap. Don't send a five-page document because it took five minutes to generate. Don't send 100 “personalized” emails simply because a tool makes it possible. Before sending something, ask: Is this useful? Have I read it? Would I want to receive it? We don't make our efficiency someone else's burden.\n\nAI doesn't lower our standards. We should use AI to research, prepare, analyze, summarize, learn, improve our writing, understand accounts, and remove repetitive work. But we're still responsible for the output. If your name is on it, you own it. Read what you send, check important facts, apply your judgment, and make sure it represents Honeycomb well.\n\nWe optimize for durable relationships, not the next dollar. We want customers who stay with Honeycomb because we continue to create value for them, not because we've made leaving painful. This doesn't mean leaving money on the table. It means building commercial relationships proportional to the value we're creating and allowing those relationships to grow as the value grows. We want both sides to feel like they got a good deal.\n\nFinally, we value good judgment over hard-and-fast rules. No document can prescribe every interaction, and we don't want one that tries. We hire adults. When you're unsure, come back to the principles: create value, tell the truth, respect people's time, compete hard, make reasonable asks, and think long term. Every interaction teaches our customers, prospects, and partners the kind of company Honeycomb aspires to be."])</script><script>self.__next_f.push([1,"43:T1fcf,"])</script><script>self.__next_f.push([1,"It's been almost exactly one year since we issued our AI mandate here at Honeycomb, and we've been doing some reflection.\n\nWhen we issued our mandate, it's not like we hadn't been using AI. We were the first in the industry to bake a feature powered by AI into our product, way back in May of 2024. Many of us had been experimenting and using these tools in our spare time.\n\nBut we believe that software is the killer app for AI. We believe that the way we build and maintain software is in the middle of a generational upheaval. We believe this is existential for us, and for our users. We had to take AI out of our spare time and put it front and center. We had to fund the change and make time for all of us to level up.\n\nAnd level up we have.\n\nWhat a year of this actually produced\n\nYou are starting to see us release quite a lot of material about what we have learned and what has happened as a result. Just in the past month, this includes:\n\n30 to 70 PRs a Day: How We Managed Not to Wreck Our Systems, by Liz Fong-Jones\n\nAI Amplifies Your Existing Practices: Lessons from Our Shift to an AI-First Strategy, by Liz Fong-Jones\n\nEmbracing the Code Review Bottleneck, by Fred Hebert\n\nWhat Comes After Observability?, by Austin Parker\n\nSpend More Time Talking to Humans, by Doug Soo\n\nHow I Support Humans in the AI Era, by Ileanell Perez\n\n... with many more sociotechnical topics in the pipeline to come.\n\nAI is not special\n\nEvery one of those posts arrives at the same place from a different direction, and it's the thing we have returned to so many times that it stopped feeling like an insight and started feeling like a law of physics.\n\nAI is not special, it is just a tool. AI amplifies what is already there.\n\nTeams with strong learning culture and real ownership get faster and better. Teams that were already shipping slop now ship slop at a truly magnificent scale. Orgs with clear values apply them harder, and orgs without them find out. It doesn't fix you, and it doesn't ruin you. It turns the volume up on whatever you already were, which is a great deal less exciting than either the doomers or the boosters would like, and considerably more useful.\n\nWe sat down to write about AI and wrote about ourselves\n\nHoneycomb has always been a company founded on values, first principles, and the stubborn conviction that technology can be so much better than what people are used to.\n\nAfter many intense internal debates about the ethics of using AI, we decided to write down a set of AI norms and values for ourselves. And again and again we found ourselves circling back to the same discovery: this isn't about AI, it's about us. How are our values being stressed in the era of AI? How do our standards apply, how must our principles adapt?\n\nThree documents emerged from this process, and we'll share all of them with you over the next few days: one on how we use AI together at the company level, one for engineering that lays out our reasons for adopting AI along with north star goal and what support people can expect, and this one.\n\nThe one I'm publishing first is called “How Honeycomb Does Business,” written by Manny Alves, SVP of Sales and long time honeybee. It was written for our go-to-market (GTM) teams to sum up our approach to customers and business, but it applies to everyone. “We treat customers like people, not pipeline.” I could not love it more.\n\nValues are not supposed to be aspirational slogans on the wall. Values should codify how things actually work at your company, when people are working well together, which should be most of the time. This is what that looks like.\n\nHow Honeycomb Does Business\n\nHoneycomb has ambitious goals, and we want to win. We also care deeply about how we win.\n\nOur reputation as a thoughtful, technical, customer-focused company is one of our greatest assets. Every interaction with a prospect or customer either reinforces that reputation or takes something away from it.\n\nThis isn't about being less commercial. We should compete hard, negotiate well, create urgency, ask for commitments, and get paid fairly for the value we create. We want to build a business where Honeycomb wins because our customers win too.\n\nAI doesn't create a new standard for how we conduct business. It raises the stakes on standards we've always had. These tools make it easier to communicate, personalize, analyze, and produce at scale. They also make it easier to be careless, impersonal, overwhelming, or deceptive at scale. We want the former without becoming the latter.\n\nThese are the principles we expect our GTM (go-to-market) teams to operate by.\n\nWe create value before we extract value. We want Honeycomb to win because the customer is winning too. We should charge fairly for the value we create, but we don't optimize for extracting every possible dollar from a customer. A great commercial relationship should feel like a good deal on both sides.\n\nWe treat customers like people, not pipeline. We respect their time, understand what they're trying to accomplish, listen before prescribing, and communicate like humans. This starts with the very first interaction. Personalization isn't inserting someone's name and company into an AI-generated email. There should be a reason we're reaching out and something useful behind it.\n\nWe tell the truth, even when it makes the deal harder. We don't misrepresent what Honeycomb can do, hide meaningful limitations, manufacture false urgency, or tell customers what we think they want to hear. Sometimes the right answer is “we don't do that today,” “we're probably not the right solution,” or “I don't know, let me find out.” Trust matters more than any individual transaction.\n\nWe earn the right to ask. Selling requires asking people to do things: take a meeting, bring in an executive, spend time on a POC, commit to a timeline, sign a contract, introduce us to another team. We shouldn't be afraid to ask, but there should be value and reciprocity behind the ask. If we're asking a customer for their time, money, or political capital, we should understand what they're getting in return.\n\nWe compete hard without compromising who we are. Being customer-friendly doesn't mean being commercially passive. We should negotiate confidently, defend our value, challenge customers when appropriate, create urgency, hold people accountable to commitments, and ask for the business. We want to win, but we don't need to manipulate, mislead, or take advantage of customers to do it.\n\nWe respect the cost of other people's attention. AI has made producing things cheap, but it hasn't made consuming them cheap. Don't send a five-page document because it took five minutes to generate. Don't send 100 “personalized” emails simply because a tool makes it possible. Before sending something, ask: Is this useful? Have I read it? Would I want to receive it? We don't make our efficiency someone else's burden.\n\nAI doesn't lower our standards. We should use AI to research, prepare, analyze, summarize, learn, improve our writing, understand accounts, and remove repetitive work. But we're still responsible for the output. If your name is on it, you own it. Read what you send, check important facts, apply your judgment, and make sure it represents Honeycomb well.\n\nWe optimize for durable relationships, not the next dollar. We want customers who stay with Honeycomb because we continue to create value for them, not because we've made leaving painful. This doesn't mean leaving money on the table. It means building commercial relationships proportional to the value we're creating and allowing those relationships to grow as the value grows. We want both sides to feel like they got a good deal.\n\nFinally, we value good judgment over hard-and-fast rules. No document can prescribe every interaction, and we don't want one that tries. We hire adults. When you're unsure, come back to the principles: create value, tell the truth, respect people's time, compete hard, make reasonable asks, and think long term. Every interaction teaches our customers, prospects, and partners the kind of company Honeycomb aspires to be."])</script><script>self.__next_f.push([1,"44:T1876,"])</script><script>self.__next_f.push([1,"When our company pushed everyone to start using AI tools, I thought about what it would mean for my team. As a remote company, we are already challenged by the lack of organic human connection. Every connection is planned and takes effort, and now, AI adds another layer. People now spend part of their day collaborating with a tool rather than with a person, which can take away from the time we spend learning from each other.\n\nI was recently asked what I was doing about it, and my answer came down to creating space. Space for connection, space for collaboration, and space for discussion.\n\nWhy space is the thing I protect\n\nMy first instinct was to create space rather than write a new policy. Engineers will always maximize for efficiency and productivity. If there is an open hour in the day, they will use it to push their work forward. That is a good instinct, but it also means the hour is never spent on anything else. Setting aside time for something other than coding feels like a cost, or even like guilt.\n\nCreating space takes that decision off their plate. When the hour is already on the calendar, and I am the one holding it, no one has to justify using it. My job is to build the space my team needs, in the shape they need it.\n\nSpace for connection\n\nOnce a month, we have a team lunch. Sometimes, we even play games. There is no agenda and no work talk required. It exists so we can connect as humans.\n\nThe feedback has been great, and I plan to keep it as long as I can. It is a small period of time with an immense return.\n\nWe are also intentional about celebrating the wins. After we finish a big project, we get together on Zoom and celebrate with an activity like building Legos, doing a virtual escape room, or painting with watercolors.\n\nSpace for collaboration\n\nEvery Friday, right after our team sync, we hold time for knowledge sharing. Even when the team is working on a project together, some work happens in silos. That is unavoidable. The clearest example is on-call or goalie rotations. The person on call spends the week solving problems the rest of the team never sees.\n\nSo, we do our own version of show and tell. Someone who worked outside of what the team was focused on walks everyone through what they did and how they solved it. People ask questions. The team learns from each other and connects while doing it.\n\nWe also make time for pairing sessions, and swarming sessions. If you are unfamiliar with the latter, it is essentially an exercise we can all do together, like whiteboarding.\n\nSpace for discussion\n\nThe space I am proudest of is our AI Innovation Time. I took one hour we already had on the calendar, our team donut, and turned it into AI Innovation Time. During the hour, everyone experiments with something AI-related, alone or together in an open Zoom. At the end, a Slackbot asks what they tried and what they learned, so we build a thread we can come back to.\n\nEveryone is figuring out AI at the same time, and this hour is where that figuring out happens out loud.\n\nIt works because of choice. I let my team decide how and when they wanted to adapt, instead of letting the tools or management decide for them. This is the same idea behind coaching. A coach asks open-ended questions and lets the person land on their own answer, because people follow through more on ideas that come from themselves than on ideas handed to them. Giving my team that choice created something a mandate never could: psychological safety and autonomy.\n\nThe people who were skeptical at the beginning came around on their own. They saw teammates using skills that saved them time and effort, so they tried those skills too. Once they saw the value, they started bringing their own ideas back to the group.\n\nI want to be clear about what this space actually looks like, because “creating space” can sound like I stepped back from it all. The hour stays protected on the calendar every week, and if it needs to move, I check with the team first rather than canceling it on my own. One of our first discussions in that hour was about our own AI norms, written by the team, for the team, before the company asked anyone to adopt them.\n\nThe team has real freedom in what they try and how they try it. Showing up, reflecting, and keeping the agreement current is not optional. Freedom lives inside a structure that doesn't move, and that structure is what makes freedom safe to use.\n\nOutside of our AI Innovation Time, we also hold space for flex discussion time. This slot is already in the calendar, and anyone in the team can claim the time to discuss a specific topic.\n\nHow “creating space” changed with time\n\nOnce the team had the space, they took it further than I expected. They started running their own experiments. No AI Fridays: a weekly reset from the tools. The Learning Opportunity skill from Dr. Cat Hicks addressed a worry a few people had about losing their technical skills over time. They shadow each other to see how someone else works through a task with AI, and they keep the skills they build in one shared place so no one starts from scratch. They also took on PR review, becoming a new bottleneck, and started experimenting there.\n\nThey try something for a while, keep what works, and drop what doesn't. Teammates now use our Friday show and tell to present experiments and share tools they are excited about for the rest of the team to try.\n\nWhat I'd tell another manager\n\nStart by creating the space. Give people room to explore without pressure or a rulebook waiting at the end. Then, stay close enough to monitor how it is going so it can keep evolving. Notice what is working and put more weight behind it. Let go of what isn't, without guilt. Keep the conversation open so people feel safe bringing up what is working, what is confusing, or what they are worried about. And when something works, celebrate it. That is how you know the space you built is being used and working.\n\nThis is true of almost everything I do as a manager, not just AI. I build the space where my team can develop, and I hold the structure that keeps it safe to use. My team is learning about AI with each other and from each other, and they are doing it alongside other humans. That is the part worth protecting."])</script><script>self.__next_f.push([1,"45:T1876,"])</script><script>self.__next_f.push([1,"When our company pushed everyone to start using AI tools, I thought about what it would mean for my team. As a remote company, we are already challenged by the lack of organic human connection. Every connection is planned and takes effort, and now, AI adds another layer. People now spend part of their day collaborating with a tool rather than with a person, which can take away from the time we spend learning from each other.\n\nI was recently asked what I was doing about it, and my answer came down to creating space. Space for connection, space for collaboration, and space for discussion.\n\nWhy space is the thing I protect\n\nMy first instinct was to create space rather than write a new policy. Engineers will always maximize for efficiency and productivity. If there is an open hour in the day, they will use it to push their work forward. That is a good instinct, but it also means the hour is never spent on anything else. Setting aside time for something other than coding feels like a cost, or even like guilt.\n\nCreating space takes that decision off their plate. When the hour is already on the calendar, and I am the one holding it, no one has to justify using it. My job is to build the space my team needs, in the shape they need it.\n\nSpace for connection\n\nOnce a month, we have a team lunch. Sometimes, we even play games. There is no agenda and no work talk required. It exists so we can connect as humans.\n\nThe feedback has been great, and I plan to keep it as long as I can. It is a small period of time with an immense return.\n\nWe are also intentional about celebrating the wins. After we finish a big project, we get together on Zoom and celebrate with an activity like building Legos, doing a virtual escape room, or painting with watercolors.\n\nSpace for collaboration\n\nEvery Friday, right after our team sync, we hold time for knowledge sharing. Even when the team is working on a project together, some work happens in silos. That is unavoidable. The clearest example is on-call or goalie rotations. The person on call spends the week solving problems the rest of the team never sees.\n\nSo, we do our own version of show and tell. Someone who worked outside of what the team was focused on walks everyone through what they did and how they solved it. People ask questions. The team learns from each other and connects while doing it.\n\nWe also make time for pairing sessions, and swarming sessions. If you are unfamiliar with the latter, it is essentially an exercise we can all do together, like whiteboarding.\n\nSpace for discussion\n\nThe space I am proudest of is our AI Innovation Time. I took one hour we already had on the calendar, our team donut, and turned it into AI Innovation Time. During the hour, everyone experiments with something AI-related, alone or together in an open Zoom. At the end, a Slackbot asks what they tried and what they learned, so we build a thread we can come back to.\n\nEveryone is figuring out AI at the same time, and this hour is where that figuring out happens out loud.\n\nIt works because of choice. I let my team decide how and when they wanted to adapt, instead of letting the tools or management decide for them. This is the same idea behind coaching. A coach asks open-ended questions and lets the person land on their own answer, because people follow through more on ideas that come from themselves than on ideas handed to them. Giving my team that choice created something a mandate never could: psychological safety and autonomy.\n\nThe people who were skeptical at the beginning came around on their own. They saw teammates using skills that saved them time and effort, so they tried those skills too. Once they saw the value, they started bringing their own ideas back to the group.\n\nI want to be clear about what this space actually looks like, because “creating space” can sound like I stepped back from it all. The hour stays protected on the calendar every week, and if it needs to move, I check with the team first rather than canceling it on my own. One of our first discussions in that hour was about our own AI norms, written by the team, for the team, before the company asked anyone to adopt them.\n\nThe team has real freedom in what they try and how they try it. Showing up, reflecting, and keeping the agreement current is not optional. Freedom lives inside a structure that doesn't move, and that structure is what makes freedom safe to use.\n\nOutside of our AI Innovation Time, we also hold space for flex discussion time. This slot is already in the calendar, and anyone in the team can claim the time to discuss a specific topic.\n\nHow “creating space” changed with time\n\nOnce the team had the space, they took it further than I expected. They started running their own experiments. No AI Fridays: a weekly reset from the tools. The Learning Opportunity skill from Dr. Cat Hicks addressed a worry a few people had about losing their technical skills over time. They shadow each other to see how someone else works through a task with AI, and they keep the skills they build in one shared place so no one starts from scratch. They also took on PR review, becoming a new bottleneck, and started experimenting there.\n\nThey try something for a while, keep what works, and drop what doesn't. Teammates now use our Friday show and tell to present experiments and share tools they are excited about for the rest of the team to try.\n\nWhat I'd tell another manager\n\nStart by creating the space. Give people room to explore without pressure or a rulebook waiting at the end. Then, stay close enough to monitor how it is going so it can keep evolving. Notice what is working and put more weight behind it. Let go of what isn't, without guilt. Keep the conversation open so people feel safe bringing up what is working, what is confusing, or what they are worried about. And when something works, celebrate it. That is how you know the space you built is being used and working.\n\nThis is true of almost everything I do as a manager, not just AI. I build the space where my team can develop, and I hold the structure that keeps it safe to use. My team is learning about AI with each other and from each other, and they are doing it alongside other humans. That is the part worth protecting."])</script><script>self.__next_f.push([1,"46:T386c,"])</script><script>self.__next_f.push([1,"AI model drift is when an AI system's performance and accuracy degrades over time because the data, user behavior, or business environment has changed since the model was trained or evaluated. Even if latency, uptime, and infrastructure metrics remain healthy, model quality can quietly decline, leading to less accurate predictions, inconsistent responses, and reduced user trust.\n\nProduction teams care about AI model drift because reliability isn't just about whether a model is available. It's about whether it's still delivering the outcomes users expect. As AI-powered features become more deeply integrated into products, even subtle changes in model behavior can affect customer satisfaction, engineering productivity, and business performance. This guide explains what AI model drift is, what signals matter, and how observability helps teams catch problems sooner.\n\nWhat is AI model drift?\n\nAI model drift is a gradual decline in a model's performance or accuracy as production data and real-world conditions diverge from the baseline used during training or evaluation. This gradual performance decline is also sometimes described as model decay. Unlike a software bug or service outage, model drift doesn't usually appear overnight. Instead, it develops over time as user behavior, business requirements, or underlying data evolves.\n\nA recommendation model, for example, might be trained on historical shopping behavior from the previous year. Months later, seasonal buying trends, new product launches, and changing customer preferences alter the kinds of products users search for and purchase. The model continues returning predictions without errors, but its recommendations become less relevant because the world it learned from no longer reflects reality.\n\nModern AI systems make this challenge even more complex. Foundation models, retrieval systems, prompts, embeddings, and external tool calls all evolve independently, creating multiple opportunities for performance to drift, even when the underlying model hasn't changed.\n\nWhat types of AI model drift should teams monitor?\n\nNot all model drift looks the same, and detecting it requires teams to understand where changes originate. Some changes begin in the data a model receives, while others stem from shifting user expectations, upstream systems, or the behavior of LLM-powered applications. Understanding these patterns helps engineering teams identify where to investigate first instead of treating every quality issue as a generic model problem.\n\nThese four categories cover many of the drift patterns teams encounter in production.\n\nRather than viewing these categories in isolation, production teams often encounter several forms of drift simultaneously. A schema change in a retrieval pipeline, for example, may alter the context presented to an LLM and reduce response quality.\n\nData drift changes the inputs a model sees\n\nData drift is when the inputs arriving in production no longer resemble the data used to train or validate a model. The model itself hasn't changed, but the world around it has.\n\nThis is one of the most common forms of AI model drift. An e-commerce platform may see new search behavior during the holiday season. A financial application might experience different spending patterns during periods of economic uncertainty. A customer support chatbot could receive questions about a newly launched product that never appeared in its original training data.\n\nBecause the model is operating outside the environment it learned from, prediction quality can gradually decline.\n\nEngineering teams typically detect data drift by monitoring changes in input distributions, feature statistics, request categories, or traffic composition.\n\nThese changes give teams an early indication that production traffic is moving away from its baseline.\n\nConcept drift changes what a correct answer means\n\nConcept drift is when the relationship between an input and the correct output changes.\n\nFor example, a fraud pattern that was reliable six months ago may no longer indicate fraud. An answer that previously satisfied users may become outdated because company policies, market conditions, or customer expectations have changed. Concept drift is often visible first through outcome signals such as declining engagement, negative feedback, reduced task completion, or increasing human escalations.\n\nUpstream changes can break model assumptions\n\nNot every model problem originates in the model. Schema changes, pipeline bugs, missing data, and deprecated sources can silently corrupt the information reaching it. The model then behaves differently because its inputs are incomplete or incorrectly formatted. In this case, retraining the model will not solve the problem. The fix belongs in the upstream data pipeline, transformation logic, retrieval process, or application integration.\n\nPrompt, embedding, and output drift change outputs over time\n\nLLM applications themselves introduce additional forms of drift.\n\nPrompt drift is when the prompts a system sends to a model change over time, whether through template updates, accumulated small edits, or a model update that changes how the same prompt is interpreted. A related pattern is input drift, where users gradually adopt new vocabulary, workflows, or interaction patterns for the same task.\n\nEmbedding drift is a shift in the distribution of embeddings over time, which can happen when the embedding model or indexing process changes, or simply because the content being embedded has changed. RAG systems can also experience corpus or retrieval drift as documents are added, removed, rewritten, or reindexed.\n\nOutput drift is a change in tone, relevance, accuracy, structure, or consistency of generated responses. It is often the most visible symptom of drift elsewhere in the system, such as a provider updating a hosted model, a prompt template edit, degraded retrieval quality, or changes in sampling settings like temperature.\n\nThese changes can reduce AI reliability without producing an obvious application failure.\n\nWhy AI model drift is challenging to detect in LLM and agentic systems\n\nTeams do not always describe the symptoms they see as “model drift.” They may first notice rising token usage, failed tool calls, weaker answers, more retries, prompt failures, or unpredictable agent behavior.\n\nThe right drift detection methods depend on the model, available labels, traffic volume, and business risk. For example, LLM model drift detection requires teams to monitor prompts, retrieval behavior, generated outputs, and downstream outcomes together. Here are some reasons why model drift can be difficult to detect in LLM and agentic systems.\n\nPrompt and embedding shifts create new failure patterns\n\nLLM systems operate on open-ended inputs that change constantly. New users bring different language patterns and expectations, while existing users discover new ways to interact with the product.\n\nIn RAG systems, the retrieval corpus also changes. Documents may be added, removed, rewritten, or indexed differently. The system may still respond, but changes to the corpus, embeddings, or retrieval behavior can lead to weaker context and less relevant answers.\n\nEffective LLM observability therefore requires more than monitoring the model endpoint. Teams also need to track how prompts, embeddings, retrieval results, and model versions influence the final response.\n\nOutput quality can drift before alerts fire\n\nTraditional alerts are designed to detect explicit failures, such as high latency, elevated error rates, or unavailable infrastructure. Model quality is different. The request may complete successfully while giving the user an inaccurate, inconsistent, or unhelpful answer. Teams need output-level signals such as:\n\nEvaluation scores\n\nUser feedback\n\nTask success\n\nEscalation rates\n\nRetry rates\n\nDownstream business results\n\nThese measurements show whether a statistical change is actually affecting users.\n\nAgents add tool-use and workflow drift\n\nAgents add another layer of complexity because they do more than generate text. They call tools, retrieve information, hand work to other agents, make decisions, and execute multi-step workflows.\n\nAs these workflows evolve, failures can emerge in places that traditional model monitoring never observes.\n\nA retrieval tool might begin returning lower-quality results after a document migration. An API integration could introduce longer response times that change an agent's decision-making behavior. A downstream service may start returning incomplete data, causing the agent to produce weaker recommendations.\n\nBecause any step can affect the result, teams need to trace the workflow from the initial prompt through retrieval, tool execution, downstream dependencies, and the final outcome. This makes it possible to identify where behavior changed instead of attributing every problem to the model.\n\nApproaches for detecting agent drift connect those steps so teams can evaluate the workflow as a whole.\n\nHow do teams detect AI model drift early?\n\nDetecting AI model drift isn't about finding a single metric that signals failure. It's about establishing a baseline, comparing production behavior against that baseline over time, and investigating meaningful changes before they affect users or business outcomes. The most effective monitoring strategies combine statistical analysis with production telemetry, quality evaluation, and business metrics to determine not only if something changed, but also whether the change actually matters.\n\nBaselines make drift measurable\n\nDrift only has meaning relative to a reference point. Without a baseline, it's impossible to determine whether a model is behaving as expected or gradually diverging from previous performance.\n\nTeams can use several types of baselines depending on the application. Common baselines include:\n\nTraining or validation datasets for traditional ML models.\n\nA known-good production window, such as the two weeks following a successful release.\n\nA rolling baseline that continuously compares current traffic against recent production behavior.\n\nA curated evaluation dataset used to measure output quality over time.\n\nA specific version of a prompt, model, retrieval index, embedding model, or feature pipeline.\n\nThere isn't a universal baseline that works for every AI system. The right baseline depends on traffic volume, release frequency, business risk, and how quickly normal behavior changes.\n\nTeams with rapidly evolving customer behavior may prefer rolling production windows, while highly regulated applications often compare against fixed evaluation datasets to maintain consistency across releases.\n\nThe important principle is consistency: meaningful drift detection starts with knowing what \"normal\" looks like for your application.\n\nStatistical signals show when something changed\n\nTeams can compare live and baseline distributions using methods such as the following:\n\nPopulation Stability Index\n\nKL divergence\n\nWasserstein distance\n\nEmbedding similarity or clustering changes\n\nFor LLM applications, teams can also monitor prompt categories, token counts, request lengths, retrieved document similarity, embedding distributions, and shifts in user intent.\n\nAnomaly detection can flag signals that move outside their expected range, while heuristics can encode application-specific warning signs. A team might flag an unusual change, a drop in retrieval similarity, or a sharp change in tool selection patterns.\n\nStatistical changes alone do not always mean the model is failing. They are a signal to investigate.\n\nQuality and business signals show whether it matters\n\nThe strongest model drift detection strategies pair statistical differences and anomalies with production outcomes, such as:\n\nLower evaluation or output quality scores\n\nMore negative user feedback\n\nMore human escalations or support requests\n\nLower task completion, conversion, or engagement\n\nHigher retry rates\n\nMore failed or unnecessary tool calls\n\nWhen a distribution shift coincides with worsening user or business outcomes, teams have stronger evidence that intervention is necessary.\n\nDrift detection should trigger investigation, not just alerts\n\nA practical monitoring process should:\n\nChoose a relevant baseline.\n\nSample representative production traffic.\n\nTrack input, output, and outcome signals.\n\nDefine heuristics and anomaly thresholds based on risk.\n\nAlert on changes that are likely to matter.\n\nInvestigate using traces, request context, and version history.\n\nRefresh baselines as behavior and business goals evolve.\n\nWhat role does observability play in model drift detection?\n\nDashboards can reveal that a metric changed. Observability helps teams understand why.\n\nWith AI observability, teams can connect prompts, model versions, retrieval paths, tool calls, user attributes, system behavior, and business outcomes within the same investigation.\n\nThat context is particularly important for non-deterministic systems. Two similar requests may take different execution paths, retrieve different documents, or receive different model responses. Tracing those paths helps engineers distinguish model decay from a prompt regression, retrieval problem, provider update, or downstream service failure.\n\nHoneycomb's AI agent monitoring brings LLM calls, tool invocations, agent handoffs, failures, and downstream system behavior into a unified chronological view. That makes it easier to reconstruct what happened instead of piecing together disconnected logs, traces, and dashboards.\n\nHow Honeycomb helps teams keep AI models reliable\n\nHoneycomb provides AI and LLM observability across model interactions, application behavior, and the downstream systems supporting them.\n\nBy instrumenting prompts, model calls, evaluations, retrieval operations, token usage, tool invocations, and downstream services, teams can investigate why AI behavior changed and determine whether the same behavior can be reproduced.\n\nFor agentic workflows, Agent Timeline organizes multiple traces and agents into one conversation-level view. Engineers can follow model calls, tools, handoffs, retries, and failures while retaining access to the underlying application and infrastructure traces.\n\nModel drift cannot always be prevented. With the right telemetry and investigation context, teams can recognize it earlier, understand its impact, and respond with the correct change."])</script><script>self.__next_f.push([1,"47:T386c,"])</script><script>self.__next_f.push([1,"AI model drift is when an AI system's performance and accuracy degrades over time because the data, user behavior, or business environment has changed since the model was trained or evaluated. Even if latency, uptime, and infrastructure metrics remain healthy, model quality can quietly decline, leading to less accurate predictions, inconsistent responses, and reduced user trust.\n\nProduction teams care about AI model drift because reliability isn't just about whether a model is available. It's about whether it's still delivering the outcomes users expect. As AI-powered features become more deeply integrated into products, even subtle changes in model behavior can affect customer satisfaction, engineering productivity, and business performance. This guide explains what AI model drift is, what signals matter, and how observability helps teams catch problems sooner.\n\nWhat is AI model drift?\n\nAI model drift is a gradual decline in a model's performance or accuracy as production data and real-world conditions diverge from the baseline used during training or evaluation. This gradual performance decline is also sometimes described as model decay. Unlike a software bug or service outage, model drift doesn't usually appear overnight. Instead, it develops over time as user behavior, business requirements, or underlying data evolves.\n\nA recommendation model, for example, might be trained on historical shopping behavior from the previous year. Months later, seasonal buying trends, new product launches, and changing customer preferences alter the kinds of products users search for and purchase. The model continues returning predictions without errors, but its recommendations become less relevant because the world it learned from no longer reflects reality.\n\nModern AI systems make this challenge even more complex. Foundation models, retrieval systems, prompts, embeddings, and external tool calls all evolve independently, creating multiple opportunities for performance to drift, even when the underlying model hasn't changed.\n\nWhat types of AI model drift should teams monitor?\n\nNot all model drift looks the same, and detecting it requires teams to understand where changes originate. Some changes begin in the data a model receives, while others stem from shifting user expectations, upstream systems, or the behavior of LLM-powered applications. Understanding these patterns helps engineering teams identify where to investigate first instead of treating every quality issue as a generic model problem.\n\nThese four categories cover many of the drift patterns teams encounter in production.\n\nRather than viewing these categories in isolation, production teams often encounter several forms of drift simultaneously. A schema change in a retrieval pipeline, for example, may alter the context presented to an LLM and reduce response quality.\n\nData drift changes the inputs a model sees\n\nData drift is when the inputs arriving in production no longer resemble the data used to train or validate a model. The model itself hasn't changed, but the world around it has.\n\nThis is one of the most common forms of AI model drift. An e-commerce platform may see new search behavior during the holiday season. A financial application might experience different spending patterns during periods of economic uncertainty. A customer support chatbot could receive questions about a newly launched product that never appeared in its original training data.\n\nBecause the model is operating outside the environment it learned from, prediction quality can gradually decline.\n\nEngineering teams typically detect data drift by monitoring changes in input distributions, feature statistics, request categories, or traffic composition.\n\nThese changes give teams an early indication that production traffic is moving away from its baseline.\n\nConcept drift changes what a correct answer means\n\nConcept drift is when the relationship between an input and the correct output changes.\n\nFor example, a fraud pattern that was reliable six months ago may no longer indicate fraud. An answer that previously satisfied users may become outdated because company policies, market conditions, or customer expectations have changed. Concept drift is often visible first through outcome signals such as declining engagement, negative feedback, reduced task completion, or increasing human escalations.\n\nUpstream changes can break model assumptions\n\nNot every model problem originates in the model. Schema changes, pipeline bugs, missing data, and deprecated sources can silently corrupt the information reaching it. The model then behaves differently because its inputs are incomplete or incorrectly formatted. In this case, retraining the model will not solve the problem. The fix belongs in the upstream data pipeline, transformation logic, retrieval process, or application integration.\n\nPrompt, embedding, and output drift change outputs over time\n\nLLM applications themselves introduce additional forms of drift.\n\nPrompt drift is when the prompts a system sends to a model change over time, whether through template updates, accumulated small edits, or a model update that changes how the same prompt is interpreted. A related pattern is input drift, where users gradually adopt new vocabulary, workflows, or interaction patterns for the same task.\n\nEmbedding drift is a shift in the distribution of embeddings over time, which can happen when the embedding model or indexing process changes, or simply because the content being embedded has changed. RAG systems can also experience corpus or retrieval drift as documents are added, removed, rewritten, or reindexed.\n\nOutput drift is a change in tone, relevance, accuracy, structure, or consistency of generated responses. It is often the most visible symptom of drift elsewhere in the system, such as a provider updating a hosted model, a prompt template edit, degraded retrieval quality, or changes in sampling settings like temperature.\n\nThese changes can reduce AI reliability without producing an obvious application failure.\n\nWhy AI model drift is challenging to detect in LLM and agentic systems\n\nTeams do not always describe the symptoms they see as “model drift.” They may first notice rising token usage, failed tool calls, weaker answers, more retries, prompt failures, or unpredictable agent behavior.\n\nThe right drift detection methods depend on the model, available labels, traffic volume, and business risk. For example, LLM model drift detection requires teams to monitor prompts, retrieval behavior, generated outputs, and downstream outcomes together. Here are some reasons why model drift can be difficult to detect in LLM and agentic systems.\n\nPrompt and embedding shifts create new failure patterns\n\nLLM systems operate on open-ended inputs that change constantly. New users bring different language patterns and expectations, while existing users discover new ways to interact with the product.\n\nIn RAG systems, the retrieval corpus also changes. Documents may be added, removed, rewritten, or indexed differently. The system may still respond, but changes to the corpus, embeddings, or retrieval behavior can lead to weaker context and less relevant answers.\n\nEffective LLM observability therefore requires more than monitoring the model endpoint. Teams also need to track how prompts, embeddings, retrieval results, and model versions influence the final response.\n\nOutput quality can drift before alerts fire\n\nTraditional alerts are designed to detect explicit failures, such as high latency, elevated error rates, or unavailable infrastructure. Model quality is different. The request may complete successfully while giving the user an inaccurate, inconsistent, or unhelpful answer. Teams need output-level signals such as:\n\nEvaluation scores\n\nUser feedback\n\nTask success\n\nEscalation rates\n\nRetry rates\n\nDownstream business results\n\nThese measurements show whether a statistical change is actually affecting users.\n\nAgents add tool-use and workflow drift\n\nAgents add another layer of complexity because they do more than generate text. They call tools, retrieve information, hand work to other agents, make decisions, and execute multi-step workflows.\n\nAs these workflows evolve, failures can emerge in places that traditional model monitoring never observes.\n\nA retrieval tool might begin returning lower-quality results after a document migration. An API integration could introduce longer response times that change an agent's decision-making behavior. A downstream service may start returning incomplete data, causing the agent to produce weaker recommendations.\n\nBecause any step can affect the result, teams need to trace the workflow from the initial prompt through retrieval, tool execution, downstream dependencies, and the final outcome. This makes it possible to identify where behavior changed instead of attributing every problem to the model.\n\nApproaches for detecting agent drift connect those steps so teams can evaluate the workflow as a whole.\n\nHow do teams detect AI model drift early?\n\nDetecting AI model drift isn't about finding a single metric that signals failure. It's about establishing a baseline, comparing production behavior against that baseline over time, and investigating meaningful changes before they affect users or business outcomes. The most effective monitoring strategies combine statistical analysis with production telemetry, quality evaluation, and business metrics to determine not only if something changed, but also whether the change actually matters.\n\nBaselines make drift measurable\n\nDrift only has meaning relative to a reference point. Without a baseline, it's impossible to determine whether a model is behaving as expected or gradually diverging from previous performance.\n\nTeams can use several types of baselines depending on the application. Common baselines include:\n\nTraining or validation datasets for traditional ML models.\n\nA known-good production window, such as the two weeks following a successful release.\n\nA rolling baseline that continuously compares current traffic against recent production behavior.\n\nA curated evaluation dataset used to measure output quality over time.\n\nA specific version of a prompt, model, retrieval index, embedding model, or feature pipeline.\n\nThere isn't a universal baseline that works for every AI system. The right baseline depends on traffic volume, release frequency, business risk, and how quickly normal behavior changes.\n\nTeams with rapidly evolving customer behavior may prefer rolling production windows, while highly regulated applications often compare against fixed evaluation datasets to maintain consistency across releases.\n\nThe important principle is consistency: meaningful drift detection starts with knowing what \"normal\" looks like for your application.\n\nStatistical signals show when something changed\n\nTeams can compare live and baseline distributions using methods such as the following:\n\nPopulation Stability Index\n\nKL divergence\n\nWasserstein distance\n\nEmbedding similarity or clustering changes\n\nFor LLM applications, teams can also monitor prompt categories, token counts, request lengths, retrieved document similarity, embedding distributions, and shifts in user intent.\n\nAnomaly detection can flag signals that move outside their expected range, while heuristics can encode application-specific warning signs. A team might flag an unusual change, a drop in retrieval similarity, or a sharp change in tool selection patterns.\n\nStatistical changes alone do not always mean the model is failing. They are a signal to investigate.\n\nQuality and business signals show whether it matters\n\nThe strongest model drift detection strategies pair statistical differences and anomalies with production outcomes, such as:\n\nLower evaluation or output quality scores\n\nMore negative user feedback\n\nMore human escalations or support requests\n\nLower task completion, conversion, or engagement\n\nHigher retry rates\n\nMore failed or unnecessary tool calls\n\nWhen a distribution shift coincides with worsening user or business outcomes, teams have stronger evidence that intervention is necessary.\n\nDrift detection should trigger investigation, not just alerts\n\nA practical monitoring process should:\n\nChoose a relevant baseline.\n\nSample representative production traffic.\n\nTrack input, output, and outcome signals.\n\nDefine heuristics and anomaly thresholds based on risk.\n\nAlert on changes that are likely to matter.\n\nInvestigate using traces, request context, and version history.\n\nRefresh baselines as behavior and business goals evolve.\n\nWhat role does observability play in model drift detection?\n\nDashboards can reveal that a metric changed. Observability helps teams understand why.\n\nWith AI observability, teams can connect prompts, model versions, retrieval paths, tool calls, user attributes, system behavior, and business outcomes within the same investigation.\n\nThat context is particularly important for non-deterministic systems. Two similar requests may take different execution paths, retrieve different documents, or receive different model responses. Tracing those paths helps engineers distinguish model decay from a prompt regression, retrieval problem, provider update, or downstream service failure.\n\nHoneycomb's AI agent monitoring brings LLM calls, tool invocations, agent handoffs, failures, and downstream system behavior into a unified chronological view. That makes it easier to reconstruct what happened instead of piecing together disconnected logs, traces, and dashboards.\n\nHow Honeycomb helps teams keep AI models reliable\n\nHoneycomb provides AI and LLM observability across model interactions, application behavior, and the downstream systems supporting them.\n\nBy instrumenting prompts, model calls, evaluations, retrieval operations, token usage, tool invocations, and downstream services, teams can investigate why AI behavior changed and determine whether the same behavior can be reproduced.\n\nFor agentic workflows, Agent Timeline organizes multiple traces and agents into one conversation-level view. Engineers can follow model calls, tools, handoffs, retries, and failures while retaining access to the underlying application and infrastructure traces.\n\nModel drift cannot always be prevented. With the right telemetry and investigation context, teams can recognize it earlier, understand its impact, and respond with the correct change."])</script><script>self.__next_f.push([1,"48:Td26,"])</script><script>self.__next_f.push([1,"BubbleUp has always been the fastest way to figure out what a group of outliers have in common. Draw a box around a band of slow traces, a cluster of errors, or any set of events you're interested in, and BubbleUp compares that selection to the baseline across every dimension you've sent us. It's how Honeycomb users find the \"unknown unknowns\" that dashboards can’t show you.\n\nWe recently shipped a big upgrade. BubbleUp now comes with AI-powered insights that summarize your selections’ most significant correlations, how they differ from the baseline, and how they are likely to be relevant. By surfacing these correlations immediately, AI BubbleUp can save hours of investigation time and make debugging insights available to team members who aren’t experts in your system’s telemetry.\n\nThe challenge with high-fidelity telemetry\n\nHoneycomb captures wide events with as many dimensions as you want to send, at any level of cardinality. That's what makes BubbleUp powerful, but it can also make the results dense and sometimes challenging for non-experts to interpret. A typical environment has well over a hundred dimensions on its core spans. Some have many more.\n\nTo help you make sense of the results, Honeycomb has always sorted those dimensions by how different the outlier group is from the baseline. That works well for some data types, but statistical difference and causal relevance aren't always the same thing, and context always matters. Also, dimensions with very high cardinality, like user ID, may not have a meaningful ‘baseline’ to establish difference from, so they may not be ranked highly by the sorting algorithm. A strong correlation in a low-cardinality dimension, like a customer support tier, might rank in the first page of results, while a more diagnostically relevant dimension, like a single misbehaving user ID, sits several pages down. If you're not deep in the specific telemetry your services emit, the most significant dimensions can be hard to spot.\n\nWhat AI insights add\n\nAI insights read the BubbleUp results and surface the dimensions most likely to be relevant to the problem, even when they aren't the top results by raw statistical difference. A few things to note about how this works:\n\nAI is always an add-on, never a replacement. Raw BubbleUp results are still right there. You can scroll, sort, and verify everything the AI flagged and find things it didn't.\n\nThe AI reasons over your real telemetry. Insights come from the same high-cardinality event data you'd inspect by hand, so the recommendations are relevant to what actually happened in your system.\n\nIt works on any BubbleUp, no need for setup or configuration. Run BubbleUp the way you always have and the insights appear with the results.\n\nAI helps most when it's given the right raw material, and for production debugging, that means high-fidelity event telemetry. BubbleUp was already one of the highest-leverage things you could do with a wide-event store. Adding AI on top means that even people who aren't experts in every dimension your services emit can still get to the relevant signal quickly.\n\nGet started\n\nAI insights in BubbleUp are now available to all Honeycomb customers who have enabled Honeycomb Intelligence. Run any BubbleUp in your environment and you'll see them in your results.\n\nCheck out the documentation for BubbleUp."])</script><script>self.__next_f.push([1,"49:Td26,"])</script><script>self.__next_f.push([1,"BubbleUp has always been the fastest way to figure out what a group of outliers have in common. Draw a box around a band of slow traces, a cluster of errors, or any set of events you're interested in, and BubbleUp compares that selection to the baseline across every dimension you've sent us. It's how Honeycomb users find the \"unknown unknowns\" that dashboards can’t show you.\n\nWe recently shipped a big upgrade. BubbleUp now comes with AI-powered insights that summarize your selections’ most significant correlations, how they differ from the baseline, and how they are likely to be relevant. By surfacing these correlations immediately, AI BubbleUp can save hours of investigation time and make debugging insights available to team members who aren’t experts in your system’s telemetry.\n\nThe challenge with high-fidelity telemetry\n\nHoneycomb captures wide events with as many dimensions as you want to send, at any level of cardinality. That's what makes BubbleUp powerful, but it can also make the results dense and sometimes challenging for non-experts to interpret. A typical environment has well over a hundred dimensions on its core spans. Some have many more.\n\nTo help you make sense of the results, Honeycomb has always sorted those dimensions by how different the outlier group is from the baseline. That works well for some data types, but statistical difference and causal relevance aren't always the same thing, and context always matters. Also, dimensions with very high cardinality, like user ID, may not have a meaningful ‘baseline’ to establish difference from, so they may not be ranked highly by the sorting algorithm. A strong correlation in a low-cardinality dimension, like a customer support tier, might rank in the first page of results, while a more diagnostically relevant dimension, like a single misbehaving user ID, sits several pages down. If you're not deep in the specific telemetry your services emit, the most significant dimensions can be hard to spot.\n\nWhat AI insights add\n\nAI insights read the BubbleUp results and surface the dimensions most likely to be relevant to the problem, even when they aren't the top results by raw statistical difference. A few things to note about how this works:\n\nAI is always an add-on, never a replacement. Raw BubbleUp results are still right there. You can scroll, sort, and verify everything the AI flagged and find things it didn't.\n\nThe AI reasons over your real telemetry. Insights come from the same high-cardinality event data you'd inspect by hand, so the recommendations are relevant to what actually happened in your system.\n\nIt works on any BubbleUp, no need for setup or configuration. Run BubbleUp the way you always have and the insights appear with the results.\n\nAI helps most when it's given the right raw material, and for production debugging, that means high-fidelity event telemetry. BubbleUp was already one of the highest-leverage things you could do with a wide-event store. Adding AI on top means that even people who aren't experts in every dimension your services emit can still get to the relevant signal quickly.\n\nGet started\n\nAI insights in BubbleUp are now available to all Honeycomb customers who have enabled Honeycomb Intelligence. Run any BubbleUp in your environment and you'll see them in your results.\n\nCheck out the documentation for BubbleUp."])</script><script>self.__next_f.push([1,"4a:T2717,"])</script><script>self.__next_f.push([1,"Last week, we sat down with the authors of Observability Engineering for a live AMA. We ended up getting so many questions (pre-submitted and live) that we couldn't get through them all.\n\nCharity, Liz, George, and Austin kindly stuck around afterward to answer more, ranging from low-hanging observability fruits and telemetry to AI and what software engineers can do that Claude can't.\n\nMissed the live session? Watch it on demand now:\n\n\nAdditional questions\n\nWhat was the most painful thing to read from the first version of your book?\n\nCharity: The predictions chapter at the end. And yes, if you ask me again in three years, I expect my answer will be the same.\n\nGeorge: We were still pretty passionate and maybe a bit raw from arguing across the industry about what observability meant and how it was different from monitoring. We relitigated those arguments repeatedly in several early chapters (that were written out of order—and what was in the first edition book was even after we edited our arguments way down). It felt like we needed to defend ourselves.\n\nThis time around, all of that has changed. The industry has started to catch on. It's less about the differences and more about what they enable. We included many more voices and viewpoints. We spent less time arguing and more time examining impacts across use cases. Now I think the book is more inclusive, way more streamlined, and yet somehow twice as meaty.\n\nWhy do we need so many metrics, logs, and traces when only a small portion of them are useful?\n\nCharity: Is this a trick question? We don't need so many metrics, logs, and traces. We should think much more critically about the telemetry we collect, instead of treating it like it's carpet bombing or nothing. One arbitrarily-wide, structured log event or well-designed trace can replace hundreds of metrics and spammy logs, and be cheaper, more effective, and easier to reason about with its connective tissue intact. Stop making decisions about signal types at write time. Treat your telemetry like data.\n\nGeorge: What Charity said. Also, if you're asking that question, it sounds like you might need to sample more.\n\nHow do we get engineers to think for themselves again rather than responding to everything with “...well Claude says...”?\n\nCharity: First, will you please tell me when this golden age of thinking for ourselves ever existed? It sounds exhausting to me. We are humans, we take shortcuts—it's one of our charms.\n\nBut I do have some practical advice for you: be specific. When you want someone's opinion, ask for their opinion. When someone gives you Claude's opinion, feign confusion. “Who is this 'Claude'? Alas, I do not speak French,” or “I have a Claude of my own, I want to know what Liz thinks.” But try to say this in good humor. After the initial shock at its capabilities, we are all well on our way to understanding the limits of AI. Stack Overflowification comes for all authority, in time.\n\nHow do you manage human-in-the-loop (especially domain experts) in observability?\n\nLiz: Signal-to-noise has always been a challenge, but the robots are really good at picking out signal. It is our job as the humans to then make decisions about what to do with the signal.\n\nGeorge: I'm going to presume you're asking about the operating procedure vs. the orchestration layer (e.g., Temporal, Langgraph, etc). Even shifting to process instead of technology, the target keeps moving and best practices in AI are evolving. That said, check out the revamped “Getting Started with Observability Analysis” chapter in the book. Specifically, the section on Agentic personas.\n\nWe tried not to tie AI recommendations in the book to specific tools (writing about AI risks making your content obsolete before it even gets published), so we focus on process. The thing to remember though is that the copilot, commander, and caretaker personas mentioned are all human-in-the-loop processes; the only thing that changes is if the human gates before or after action. Which agent “persona” you decide to use will depend on the sophistication of your observability tooling, robustness of your orchestration layer, and how much trust your particular agents have earned. Generally speaking, most people will start with the copilot and work their way toward the caretaker.\n\nWhen an AI application produces a wrong or unexpected response, how can observability help teams determine whether the problem came from the model, the prompt, the data, or the surrounding infrastructure?\n\nAustin: That's the fun part—it can be all of those things at the same time! I've been doing a lot of thinking about this and there's two ways I'd slice it: there's a bundle of bog-standard stuff that you want to look at (golden signals, etc.) about the actual runtime environment, and then there's a lot of attributes that you'll want to build into traces. You're never gonna get the same thing twice out of an agent or AI application, so you want to shift as much of the attribution over to the client as possible and bake it into your spans.\n\nNow, there are a lot of ways this can get complicated real quick (e.g., storing and querying prompts or outputs). I'm excited to see more progress on interesting ways to do annotation and classification closer to the generation loop itself.\n\nI want to challenge the notion of “production” is the only place where you can actually see things. I understand and agree in general, but testing beforehand is so important that I'm not sure if it's the highest bit about which we should care.\n\nCharity: Who said production was the only place you could actually see things? Certainly not me. On the contrary, if we relied exclusively on production for detecting faults, we would be swimming in far too many of them to pick out the long tail of aberrant behaviors.\n\nTesting and validating pre-production is vital. Keeping up on improvements to the state of the art is necessary. But the mistake I see most software engineering teams making is investing too heavily in pre-production testing at the expense of their production tooling. And far too many companies still assume software engineers will never look at production at all. Until that changes, I will keep banging this drum.\n\nWhat is the one advice you would provide a young person who is considering entering computer science today?\n\nLiz: Focus on what you can uniquely do that Claude cannot. If the only value you provide is pressing enter or acting like the sipping bird from the Simpsons episode who always presses y, then why should anyone pay you? At the moment, the models do not learn over longer time horizons, become myopically focused on individual tasks, and do not have judgment about wider design calls. That is what you should specialise in, rather than the writing of the code itself.\n\nGeorge: Prioritize learning core fundamentals around system architecture, algorithms, and leveraging AI tools for code generation. There's less value in cranking out code itself and more value in architecting outcomes. The importance of systems thinking, turning that into system design, and knowing which data matters, how it moves, and how to apply it is what really excites me about the AI era. Technology is only valuable when it solves real customer or business needs, so the domain expertise and people skills matter more than ever. You will need to think bigger than ever before because, now, accomplishing the small things will increasingly become a commodity.\n\nIn the AI space, I think one of the durable questions is how to move as much into the deterministic layer that we give the agents as possible, and the right types of things. Do you agree and if so, what have you seen successfully move into determinism for instrumenting with AI? Sorry if this is in the book, not had a chance to read it fully yet.\n\nAustin: I kinda agree and kinda disagree. I remember about a year and change ago, there was a lot of “well this would be good if the agents could talk to a language server, it seems so inefficient...” and then the models/harnesses just got really good at using grep and it turns out that it didn't really matter that much.\n\nI think there's a lot of value in having models write code in order to achieve outcomes, such as refactoring. I think you discover those deterministic outcomes through a lot of non-determinism. If a task was easy to make deterministic, then we'd already be doing it that way! Ultimately I think that this is less of a binary than it is a sliding scale—common patterns will get baked in over time. For example, I recently refactored a library in our codebase that had a bunch of different span attributes created with strings (e.g., span.SetAttribute(\"foo\", \"bar\")) scattered throughout. Some had the same key, some had subtly different keys. I had an agent go through, find all the callsites, analyze/classify the attribute keys, then refactor them all to a shared helper. What's really interesting and fun about doing this with AI is that it went ahead and just wrote a test case for the entire library that fails loudly if someone tries to set an attribute using a string rather than using the helper.\n\nWhen a team starts the observability journey, what is the low hanging fruit to get started that will yield the most value?\n\nGeorge: Auto-instrumentation is a great place to get started and you'll get a ton out of the box. But custom instrumentation is where the value really accelerates. Check out Jeremy Morell's contributed chapter, Making Structured Events Arbitrarily Wide. There's a ton of concrete recommendations around standard environmental information to help you quickly ramp up value as you get started on your observability journey.\n\nConclusion\n\nThat's a wrap on this AMA, but if you want more time with the authors, Liz Fong-Jones is running a live masterclass, walking through how to actually put Observability Engineering into practice. Save your spot here, or watch this AMA on demand if you missed it."])</script><script>self.__next_f.push([1,"4b:T2717,"])</script><script>self.__next_f.push([1,"Last week, we sat down with the authors of Observability Engineering for a live AMA. We ended up getting so many questions (pre-submitted and live) that we couldn't get through them all.\n\nCharity, Liz, George, and Austin kindly stuck around afterward to answer more, ranging from low-hanging observability fruits and telemetry to AI and what software engineers can do that Claude can't.\n\nMissed the live session? Watch it on demand now:\n\n\nAdditional questions\n\nWhat was the most painful thing to read from the first version of your book?\n\nCharity: The predictions chapter at the end. And yes, if you ask me again in three years, I expect my answer will be the same.\n\nGeorge: We were still pretty passionate and maybe a bit raw from arguing across the industry about what observability meant and how it was different from monitoring. We relitigated those arguments repeatedly in several early chapters (that were written out of order—and what was in the first edition book was even after we edited our arguments way down). It felt like we needed to defend ourselves.\n\nThis time around, all of that has changed. The industry has started to catch on. It's less about the differences and more about what they enable. We included many more voices and viewpoints. We spent less time arguing and more time examining impacts across use cases. Now I think the book is more inclusive, way more streamlined, and yet somehow twice as meaty.\n\nWhy do we need so many metrics, logs, and traces when only a small portion of them are useful?\n\nCharity: Is this a trick question? We don't need so many metrics, logs, and traces. We should think much more critically about the telemetry we collect, instead of treating it like it's carpet bombing or nothing. One arbitrarily-wide, structured log event or well-designed trace can replace hundreds of metrics and spammy logs, and be cheaper, more effective, and easier to reason about with its connective tissue intact. Stop making decisions about signal types at write time. Treat your telemetry like data.\n\nGeorge: What Charity said. Also, if you're asking that question, it sounds like you might need to sample more.\n\nHow do we get engineers to think for themselves again rather than responding to everything with “...well Claude says...”?\n\nCharity: First, will you please tell me when this golden age of thinking for ourselves ever existed? It sounds exhausting to me. We are humans, we take shortcuts—it's one of our charms.\n\nBut I do have some practical advice for you: be specific. When you want someone's opinion, ask for their opinion. When someone gives you Claude's opinion, feign confusion. “Who is this 'Claude'? Alas, I do not speak French,” or “I have a Claude of my own, I want to know what Liz thinks.” But try to say this in good humor. After the initial shock at its capabilities, we are all well on our way to understanding the limits of AI. Stack Overflowification comes for all authority, in time.\n\nHow do you manage human-in-the-loop (especially domain experts) in observability?\n\nLiz: Signal-to-noise has always been a challenge, but the robots are really good at picking out signal. It is our job as the humans to then make decisions about what to do with the signal.\n\nGeorge: I'm going to presume you're asking about the operating procedure vs. the orchestration layer (e.g., Temporal, Langgraph, etc). Even shifting to process instead of technology, the target keeps moving and best practices in AI are evolving. That said, check out the revamped “Getting Started with Observability Analysis” chapter in the book. Specifically, the section on Agentic personas.\n\nWe tried not to tie AI recommendations in the book to specific tools (writing about AI risks making your content obsolete before it even gets published), so we focus on process. The thing to remember though is that the copilot, commander, and caretaker personas mentioned are all human-in-the-loop processes; the only thing that changes is if the human gates before or after action. Which agent “persona” you decide to use will depend on the sophistication of your observability tooling, robustness of your orchestration layer, and how much trust your particular agents have earned. Generally speaking, most people will start with the copilot and work their way toward the caretaker.\n\nWhen an AI application produces a wrong or unexpected response, how can observability help teams determine whether the problem came from the model, the prompt, the data, or the surrounding infrastructure?\n\nAustin: That's the fun part—it can be all of those things at the same time! I've been doing a lot of thinking about this and there's two ways I'd slice it: there's a bundle of bog-standard stuff that you want to look at (golden signals, etc.) about the actual runtime environment, and then there's a lot of attributes that you'll want to build into traces. You're never gonna get the same thing twice out of an agent or AI application, so you want to shift as much of the attribution over to the client as possible and bake it into your spans.\n\nNow, there are a lot of ways this can get complicated real quick (e.g., storing and querying prompts or outputs). I'm excited to see more progress on interesting ways to do annotation and classification closer to the generation loop itself.\n\nI want to challenge the notion of “production” is the only place where you can actually see things. I understand and agree in general, but testing beforehand is so important that I'm not sure if it's the highest bit about which we should care.\n\nCharity: Who said production was the only place you could actually see things? Certainly not me. On the contrary, if we relied exclusively on production for detecting faults, we would be swimming in far too many of them to pick out the long tail of aberrant behaviors.\n\nTesting and validating pre-production is vital. Keeping up on improvements to the state of the art is necessary. But the mistake I see most software engineering teams making is investing too heavily in pre-production testing at the expense of their production tooling. And far too many companies still assume software engineers will never look at production at all. Until that changes, I will keep banging this drum.\n\nWhat is the one advice you would provide a young person who is considering entering computer science today?\n\nLiz: Focus on what you can uniquely do that Claude cannot. If the only value you provide is pressing enter or acting like the sipping bird from the Simpsons episode who always presses y, then why should anyone pay you? At the moment, the models do not learn over longer time horizons, become myopically focused on individual tasks, and do not have judgment about wider design calls. That is what you should specialise in, rather than the writing of the code itself.\n\nGeorge: Prioritize learning core fundamentals around system architecture, algorithms, and leveraging AI tools for code generation. There's less value in cranking out code itself and more value in architecting outcomes. The importance of systems thinking, turning that into system design, and knowing which data matters, how it moves, and how to apply it is what really excites me about the AI era. Technology is only valuable when it solves real customer or business needs, so the domain expertise and people skills matter more than ever. You will need to think bigger than ever before because, now, accomplishing the small things will increasingly become a commodity.\n\nIn the AI space, I think one of the durable questions is how to move as much into the deterministic layer that we give the agents as possible, and the right types of things. Do you agree and if so, what have you seen successfully move into determinism for instrumenting with AI? Sorry if this is in the book, not had a chance to read it fully yet.\n\nAustin: I kinda agree and kinda disagree. I remember about a year and change ago, there was a lot of “well this would be good if the agents could talk to a language server, it seems so inefficient...” and then the models/harnesses just got really good at using grep and it turns out that it didn't really matter that much.\n\nI think there's a lot of value in having models write code in order to achieve outcomes, such as refactoring. I think you discover those deterministic outcomes through a lot of non-determinism. If a task was easy to make deterministic, then we'd already be doing it that way! Ultimately I think that this is less of a binary than it is a sliding scale—common patterns will get baked in over time. For example, I recently refactored a library in our codebase that had a bunch of different span attributes created with strings (e.g., span.SetAttribute(\"foo\", \"bar\")) scattered throughout. Some had the same key, some had subtly different keys. I had an agent go through, find all the callsites, analyze/classify the attribute keys, then refactor them all to a shared helper. What's really interesting and fun about doing this with AI is that it went ahead and just wrote a test case for the entire library that fails loudly if someone tries to set an attribute using a string rather than using the helper.\n\nWhen a team starts the observability journey, what is the low hanging fruit to get started that will yield the most value?\n\nGeorge: Auto-instrumentation is a great place to get started and you'll get a ton out of the box. But custom instrumentation is where the value really accelerates. Check out Jeremy Morell's contributed chapter, Making Structured Events Arbitrarily Wide. There's a ton of concrete recommendations around standard environmental information to help you quickly ramp up value as you get started on your observability journey.\n\nConclusion\n\nThat's a wrap on this AMA, but if you want more time with the authors, Liz Fong-Jones is running a live masterclass, walking through how to actually put Observability Engineering into practice. Save your spot here, or watch this AMA on demand if you missed it."])</script><script>self.__next_f.push([1,"4c:T3672,"])</script><script>self.__next_f.push([1,"A few months ago, I noticed something happening. I would spend all day working with LLMs—prompting them, reviewing their work, and correcting them—and when I wasn’t working on my own code, I was reviewing LLM-generated code. By the end of the day, I was exhausted. This was a very unusual thing for me: I’ve been a software developer at startups for 30 years, and while sometimes I might have gotten stressed out, I had never been exhausted by the actual act of writing code.\n\nAnd I noticed that I wasn’t the only person. My peer staff engineers were also tired. The junior engineers on my team were stressed out and worried. LLMs were doing more of the work that they would have normally done themselves and they weren’t sure that they were learning the right things to continue to have a career. On top of that, they didn’t even have a real idea of what that might look like.\n\nIt felt like, overall, the team was shipping more, but understanding less. We were worried about the quality of the code that we were shipping, worried that the next time something broke in production, there wouldn’t be anybody able to understand it and fix it. We also had less and less of an idea of what was going on outside of our team as well; everything was moving faster and it was harder to keep up.\n\nWhat was happening, and what could we do about it? Well, LLMs have drastically changed how software engineering is done. I’m going to elaborate on my observations on what those changes are. As for what we can do about it, the title of this blog post gives it away. But it’s important to know why we should be spending more time talking to humans, who we should be talking to, and about what.\n\nLLMs have changed the core work of software development\n\nThe root of what’s happening (and why we’re seeing so much more exhaustion and stress) is the fact that LLM-driven coding is changing core parts of the software engineering lifecycle and of the day-to-day work of a software engineer. To understand these changes, we need to go back to first principles and remember what it is our teams are trying to accomplish.\n\nWhat is the core of software engineering?\n\nFor me, the core of software engineering involves the following four functions:\n\nDesign: Decide what we’re building and how we should build it to meet the requirements and be resilient in production.\n\nImplementation: Actually build the thing.\n\nValidation: Make sure the thing we built actually meets the requirements and will work in production. Validate that the requirements still make sense. Validation is usually done by someone else in addition to yourself to get different context and skills and knowledge share.\n\nOperation: Run the system in production and provide feedback into the design and implementation of the next iteration.\n\nTypically, this has been treated as a loop (note: this is also known as the Plan-Do-Check-Act cycle in other domains. I like DIVO because it’s a cooler acronym). Design up front, implement by writing code, validate through code review and testing, and then operate in production and deal with the fallout. We’ll call this the DIVO loop going forward.\n\nA pre-LLM workflow\n\nHow did this high-level core manifest itself? A typical medium-sized project might involve this work:\n\nOne or two days of design, either solo or collaborating with your team.\n\nA week doing implementation, usually solo.\n\nA couple of hours of validation and code review, involving someone else on the team.\n\nA couple of hours of watching it in production to make sure that it’s working.\n\nFor the most part, it meant that there was a rhythm to the day. For example:\n\nSpend a few minutes, maybe an hour, reviewing PRs.\n\nSpend most of the day writing code.\n\nOn the odd day when projects are being kicked off, focus on designing things with your team.\n\nWhen you ship something, observe it in production to make sure that it has the desired outcomes.\n\nWhat has changed?\n\nLLM-based development is different in a few specific ways that have cascading impacts:\n\nImplementation is often much faster than it used to be, especially for refactors and writing tests. You can generate output multiple times faster than before.\n\nThe code and mistakes that LLMs make are often different from the code that humans make. This often makes validating the quality of code written by LLMs harder.\n\nWorking with an LLM generally involves natural language skills that are more like interacting with another human (i.e., it feels more like Slack than crafting algorithms and logic). You’re describing a design, letting it try to implement it, and then looking at and validating the results. Basically, it’s a miniature design, implementation, and validation loop, except that often the implementation is in minutes.\n\nInstead of a single long DIVO loop covering multiple days, you’re doing dozens of small DIV loops inside a bigger DIVO loop.\n\nOverall, less time is being spent on implementation, and more time is spent doing design and validation.\n\nWhat hasn’t changed?\n\nIt’s also important to know what aspects of software development LLM-based development don’t change:\n\nYou still need to coordinate with teams, especially towards the end of the development cycle when you’re going to ship your changes to prod:\n\nNotifying dependencies that you’re changing how something works\n\nWorking with your product/sales/marketing teams to actually launch the project publicly.\n\nYou still need to do final validation of what you’re shipping.\n\nYou still need to be responsible for your changes operating in production.\n\nAnother important result of adopting LLM-based development broadly is that you can expect that everybody else is shipping faster, not just your own team. This means that the amount of cross-team collaborative communication needs to increase.\n\nWhat is the impact on individual engineers?\n\nLet’s look at the impact of these changes on senior and junior developers (I’m not referring to traditional senior or junior engineer levels. I’m referring to senior and junior on the relative experience and responsibility scale).\n\nAs a more senior engineer:\n\nYou’re spending an increasing amount of time doing design and validation, both on the specific projects you and your team are working on, and on work other teams are working on, because they’re all moving faster.\n\nLooking at all of these different things in flight requires a lot more context switching, and loading of context for work that you didn’t do yourself. The context-related overhead is starting to overwhelm the actual amount of time working on your own projects.\n\nThis doesn’t apply just to the development side of things. There are more operational impacts on the systems you own based not just on what your team is shipping, but on what the teams around you are shipping. The operational landscape around you is changing more rapidly than it has before.\n\nBasically, all of the low-skill, easy parts of software development are being handled by the LLMs and you’re now spending an ever-increasing amount of your time on high-skill, high-effort design, validation, and communication.\n\nYou’re in a spiral of ever-increasing, ever more exhausting work.\n\nAs a more junior engineer:\n\nIn the past, improving implementation skills was the primary thing that you needed to do to progress in your career. Your ability to implement quickly drove your seniority.\n\nWith LLMs doing most of the implementation and low-level validation, those lower level skills aren’t as valuable. High-level design, validation, and communication skills are. But you can’t learn those skills from LLMs. By definition, your job is to do the things that the LLMs are incapable of doing, so it can feel like you’re caught between what the LLMs can do and what the more senior engineers can do. There are only two ways to gain those skills:\n\nGaining experience by making mistakes and seeing the results.\n\nLearning from people who already have those skills and experience.\n\nRecapping:\n\nSenior engineers are exhausted by spending more of their time doing high-skill, high-effort work, which involves lots of context-switching and loading new context. They feel like they are the bottleneck for the output of their team/company.\n\nJunior engineers are stressed because they feel like they are being replaced. They want and need to improve their design, validation, and communication skills, and the best way to get these skills is by working with more senior engineers. But the senior engineers are busy because they are the bottleneck for the team.\n\nIn addition, everyone is feeling stress simply due to the overall uncertainty that AI as a new technology introduces.\n\nHow do we solve these problems?\n\nReduce the amount of context-switching and context transfer costs so that everybody can work more efficiently.\n\nWork to increase the number of engineers capable of doing the higher-level work by leveling up your junior engineers.\n\nCreate more social cohesion between people on your team to help manage stress and change. We are in a period of true instability right now. Change won’t be slowing down any time soon.\n\nSpend more time talking to humans.\n\nReduce parallelism and context churn\n\nExplicitly fight against parallelizing and fragmenting work at an individual and team level. Fight the instinct to try and use AI as “efficiently” as possible by doing more and more work in parallel. You’re not necessarily getting more work done that way, you’re just generating more context churn for everyone on your team.\n\nIf you do parallelize to try to move faster, structure the work in ways that allow you to reduce the amount of context that you need while you’re working on them. If you’re going to do side quests, make them related to your main quest, or have them be related to each other.\n\nPair (but don’t pair program)\n\nReduce parallelism and the need for context switching and transfer between team members by having pairs of developers work together. In particular, consider having pairs of senior and junior developers work together in a master/apprentice setup. This doesn’t have to be a long term thing—it can be just for an individual small deliverable—but you want to avoid changing out who’s working on something if you can avoid it.\n\nI’m not advocating what you might stereotypically think of as pair programming. LLM-based development means pairing is very different, and arguably much more beneficial than it used to be.\n\nIn traditional software development, pair programming often meant that you were doing implementation (writing code) together. This was strictly a consequence of the fact that most time spent in software development was doing implementation.\n\nWhile beneficial, it wasn’t necessarily as meaningful as it could have been. Oftentimes, implementation didn’t lend itself as well to transferring critical skills that characterized being a senior engineer.\n\nLLM-based development is much more focused on rapid design and validation cycles as opposed to implementation. This means that there are more opportunities for the junior engineer to learn valuable senior-level skills of design and validation, as well as to transfer critical context on what’s being worked on between participants.\n\nIn these rapid design, implementation, and validation loops, pairing compresses what might have been weeks worth of learning about how to design and validate systems in a pre-LLM world into hours. You can level up your junior engineers much faster than you used to be able to, as long as you create the right environment for learning.\n\nFocus on:\n\nSharing context. Senior engineers often have more context on the relationship between the project and the business. Junior engineers often know more about the specific details and roadblocks driving what they’re working on. Sharing this context allows everybody to gain more understanding about what’s going on in the businesses and systems that are relevant to them.\n\nCreating a safe space for articulating thought processes. Don’t clean up what you’re thinking like you would for a design document. Exposing the internals of your thought process is actually critical here. Be comfortable making mistakes and telling stories of mistakes that have been made in the past. The principles of cognitive apprenticeship may prove to be useful here: focus on having your senior engineers model and demonstrate behaviors in real-world situations, and have your junior engineers drive the development lifecycle.\n\nNot worrying about being “productive.” Take time for side quests and non-work conversations. You’re not trying to maximize short-term output! Learning and creating relationships is just as important as shipping code.\n\nTalking to one another. If one person is just watching and not contributing, switch to a different work stream, spend more time discussing the task at hand, or stop the session and pick it up another day.\n\nCommunicate with other teams\n\nRemember that your team is part of a broader organization and everybody moving faster means that there needs to be more overall coordination and communication. It’s important to spend more time keeping track of the broader context of what’s happening around you.\n\nUse the same principles of spending more time talking with each other with other teams. Spend more time talking about what projects you’re working on with each other. Think about embedding engineers from your team in other teams you’re working with.\n\nConclusion\n\nAs AI coding continues to accelerate the pace of software development implementation, it has become increasingly important to understand its impact on the people and the human systems that surround software development.\n\nThose impacts can be good rather than bad, but only if you proactively change how you work in a way to adapt to those changes and focus on what the people on your teams need."])</script><script>self.__next_f.push([1,"4d:T3672,"])</script><script>self.__next_f.push([1,"A few months ago, I noticed something happening. I would spend all day working with LLMs—prompting them, reviewing their work, and correcting them—and when I wasn’t working on my own code, I was reviewing LLM-generated code. By the end of the day, I was exhausted. This was a very unusual thing for me: I’ve been a software developer at startups for 30 years, and while sometimes I might have gotten stressed out, I had never been exhausted by the actual act of writing code.\n\nAnd I noticed that I wasn’t the only person. My peer staff engineers were also tired. The junior engineers on my team were stressed out and worried. LLMs were doing more of the work that they would have normally done themselves and they weren’t sure that they were learning the right things to continue to have a career. On top of that, they didn’t even have a real idea of what that might look like.\n\nIt felt like, overall, the team was shipping more, but understanding less. We were worried about the quality of the code that we were shipping, worried that the next time something broke in production, there wouldn’t be anybody able to understand it and fix it. We also had less and less of an idea of what was going on outside of our team as well; everything was moving faster and it was harder to keep up.\n\nWhat was happening, and what could we do about it? Well, LLMs have drastically changed how software engineering is done. I’m going to elaborate on my observations on what those changes are. As for what we can do about it, the title of this blog post gives it away. But it’s important to know why we should be spending more time talking to humans, who we should be talking to, and about what.\n\nLLMs have changed the core work of software development\n\nThe root of what’s happening (and why we’re seeing so much more exhaustion and stress) is the fact that LLM-driven coding is changing core parts of the software engineering lifecycle and of the day-to-day work of a software engineer. To understand these changes, we need to go back to first principles and remember what it is our teams are trying to accomplish.\n\nWhat is the core of software engineering?\n\nFor me, the core of software engineering involves the following four functions:\n\nDesign: Decide what we’re building and how we should build it to meet the requirements and be resilient in production.\n\nImplementation: Actually build the thing.\n\nValidation: Make sure the thing we built actually meets the requirements and will work in production. Validate that the requirements still make sense. Validation is usually done by someone else in addition to yourself to get different context and skills and knowledge share.\n\nOperation: Run the system in production and provide feedback into the design and implementation of the next iteration.\n\nTypically, this has been treated as a loop (note: this is also known as the Plan-Do-Check-Act cycle in other domains. I like DIVO because it’s a cooler acronym). Design up front, implement by writing code, validate through code review and testing, and then operate in production and deal with the fallout. We’ll call this the DIVO loop going forward.\n\nA pre-LLM workflow\n\nHow did this high-level core manifest itself? A typical medium-sized project might involve this work:\n\nOne or two days of design, either solo or collaborating with your team.\n\nA week doing implementation, usually solo.\n\nA couple of hours of validation and code review, involving someone else on the team.\n\nA couple of hours of watching it in production to make sure that it’s working.\n\nFor the most part, it meant that there was a rhythm to the day. For example:\n\nSpend a few minutes, maybe an hour, reviewing PRs.\n\nSpend most of the day writing code.\n\nOn the odd day when projects are being kicked off, focus on designing things with your team.\n\nWhen you ship something, observe it in production to make sure that it has the desired outcomes.\n\nWhat has changed?\n\nLLM-based development is different in a few specific ways that have cascading impacts:\n\nImplementation is often much faster than it used to be, especially for refactors and writing tests. You can generate output multiple times faster than before.\n\nThe code and mistakes that LLMs make are often different from the code that humans make. This often makes validating the quality of code written by LLMs harder.\n\nWorking with an LLM generally involves natural language skills that are more like interacting with another human (i.e., it feels more like Slack than crafting algorithms and logic). You’re describing a design, letting it try to implement it, and then looking at and validating the results. Basically, it’s a miniature design, implementation, and validation loop, except that often the implementation is in minutes.\n\nInstead of a single long DIVO loop covering multiple days, you’re doing dozens of small DIV loops inside a bigger DIVO loop.\n\nOverall, less time is being spent on implementation, and more time is spent doing design and validation.\n\nWhat hasn’t changed?\n\nIt’s also important to know what aspects of software development LLM-based development don’t change:\n\nYou still need to coordinate with teams, especially towards the end of the development cycle when you’re going to ship your changes to prod:\n\nNotifying dependencies that you’re changing how something works\n\nWorking with your product/sales/marketing teams to actually launch the project publicly.\n\nYou still need to do final validation of what you’re shipping.\n\nYou still need to be responsible for your changes operating in production.\n\nAnother important result of adopting LLM-based development broadly is that you can expect that everybody else is shipping faster, not just your own team. This means that the amount of cross-team collaborative communication needs to increase.\n\nWhat is the impact on individual engineers?\n\nLet’s look at the impact of these changes on senior and junior developers (I’m not referring to traditional senior or junior engineer levels. I’m referring to senior and junior on the relative experience and responsibility scale).\n\nAs a more senior engineer:\n\nYou’re spending an increasing amount of time doing design and validation, both on the specific projects you and your team are working on, and on work other teams are working on, because they’re all moving faster.\n\nLooking at all of these different things in flight requires a lot more context switching, and loading of context for work that you didn’t do yourself. The context-related overhead is starting to overwhelm the actual amount of time working on your own projects.\n\nThis doesn’t apply just to the development side of things. There are more operational impacts on the systems you own based not just on what your team is shipping, but on what the teams around you are shipping. The operational landscape around you is changing more rapidly than it has before.\n\nBasically, all of the low-skill, easy parts of software development are being handled by the LLMs and you’re now spending an ever-increasing amount of your time on high-skill, high-effort design, validation, and communication.\n\nYou’re in a spiral of ever-increasing, ever more exhausting work.\n\nAs a more junior engineer:\n\nIn the past, improving implementation skills was the primary thing that you needed to do to progress in your career. Your ability to implement quickly drove your seniority.\n\nWith LLMs doing most of the implementation and low-level validation, those lower level skills aren’t as valuable. High-level design, validation, and communication skills are. But you can’t learn those skills from LLMs. By definition, your job is to do the things that the LLMs are incapable of doing, so it can feel like you’re caught between what the LLMs can do and what the more senior engineers can do. There are only two ways to gain those skills:\n\nGaining experience by making mistakes and seeing the results.\n\nLearning from people who already have those skills and experience.\n\nRecapping:\n\nSenior engineers are exhausted by spending more of their time doing high-skill, high-effort work, which involves lots of context-switching and loading new context. They feel like they are the bottleneck for the output of their team/company.\n\nJunior engineers are stressed because they feel like they are being replaced. They want and need to improve their design, validation, and communication skills, and the best way to get these skills is by working with more senior engineers. But the senior engineers are busy because they are the bottleneck for the team.\n\nIn addition, everyone is feeling stress simply due to the overall uncertainty that AI as a new technology introduces.\n\nHow do we solve these problems?\n\nReduce the amount of context-switching and context transfer costs so that everybody can work more efficiently.\n\nWork to increase the number of engineers capable of doing the higher-level work by leveling up your junior engineers.\n\nCreate more social cohesion between people on your team to help manage stress and change. We are in a period of true instability right now. Change won’t be slowing down any time soon.\n\nSpend more time talking to humans.\n\nReduce parallelism and context churn\n\nExplicitly fight against parallelizing and fragmenting work at an individual and team level. Fight the instinct to try and use AI as “efficiently” as possible by doing more and more work in parallel. You’re not necessarily getting more work done that way, you’re just generating more context churn for everyone on your team.\n\nIf you do parallelize to try to move faster, structure the work in ways that allow you to reduce the amount of context that you need while you’re working on them. If you’re going to do side quests, make them related to your main quest, or have them be related to each other.\n\nPair (but don’t pair program)\n\nReduce parallelism and the need for context switching and transfer between team members by having pairs of developers work together. In particular, consider having pairs of senior and junior developers work together in a master/apprentice setup. This doesn’t have to be a long term thing—it can be just for an individual small deliverable—but you want to avoid changing out who’s working on something if you can avoid it.\n\nI’m not advocating what you might stereotypically think of as pair programming. LLM-based development means pairing is very different, and arguably much more beneficial than it used to be.\n\nIn traditional software development, pair programming often meant that you were doing implementation (writing code) together. This was strictly a consequence of the fact that most time spent in software development was doing implementation.\n\nWhile beneficial, it wasn’t necessarily as meaningful as it could have been. Oftentimes, implementation didn’t lend itself as well to transferring critical skills that characterized being a senior engineer.\n\nLLM-based development is much more focused on rapid design and validation cycles as opposed to implementation. This means that there are more opportunities for the junior engineer to learn valuable senior-level skills of design and validation, as well as to transfer critical context on what’s being worked on between participants.\n\nIn these rapid design, implementation, and validation loops, pairing compresses what might have been weeks worth of learning about how to design and validate systems in a pre-LLM world into hours. You can level up your junior engineers much faster than you used to be able to, as long as you create the right environment for learning.\n\nFocus on:\n\nSharing context. Senior engineers often have more context on the relationship between the project and the business. Junior engineers often know more about the specific details and roadblocks driving what they’re working on. Sharing this context allows everybody to gain more understanding about what’s going on in the businesses and systems that are relevant to them.\n\nCreating a safe space for articulating thought processes. Don’t clean up what you’re thinking like you would for a design document. Exposing the internals of your thought process is actually critical here. Be comfortable making mistakes and telling stories of mistakes that have been made in the past. The principles of cognitive apprenticeship may prove to be useful here: focus on having your senior engineers model and demonstrate behaviors in real-world situations, and have your junior engineers drive the development lifecycle.\n\nNot worrying about being “productive.” Take time for side quests and non-work conversations. You’re not trying to maximize short-term output! Learning and creating relationships is just as important as shipping code.\n\nTalking to one another. If one person is just watching and not contributing, switch to a different work stream, spend more time discussing the task at hand, or stop the session and pick it up another day.\n\nCommunicate with other teams\n\nRemember that your team is part of a broader organization and everybody moving faster means that there needs to be more overall coordination and communication. It’s important to spend more time keeping track of the broader context of what’s happening around you.\n\nUse the same principles of spending more time talking with each other with other teams. Spend more time talking about what projects you’re working on with each other. Think about embedding engineers from your team in other teams you’re working with.\n\nConclusion\n\nAs AI coding continues to accelerate the pace of software development implementation, it has become increasingly important to understand its impact on the people and the human systems that surround software development.\n\nThose impacts can be good rather than bad, but only if you proactively change how you work in a way to adapt to those changes and focus on what the people on your teams need."])</script><script>self.__next_f.push([1,"4e:T1474,"])</script><script>self.__next_f.push([1,"For the third consecutive year, Honeycomb has been recognized for its Ability to Execute and Completeness of Vision, and we believe for its strong vision around fast, flexible, high-cardinality querying that helps engineers understand not just that something broke, but why.\n\nThe software development lifecycle has collapsed. The neat sequence of plan, build, test, and ship that teams have relied on for 20 years is now happening in a single afternoon. AI writes a large share of the code. Agents run in production and make decisions no one scripted. The old checkpoints that used to catch problems before customers did are mostly gone.\n\nWhat is left is one question that matters more than any other: do you actually understand what your software (or agent) is doing right now? When your software is the business, that understanding is the job.\n\nThat belief is why Honeycomb exists, and we think it is why Gartner named us a Visionary in the 2026 Magic Quadrant for Observability Platforms for the third year in a row.\n\nUnderstanding, not dashboards\n\nMost tools were built to tell you that something broke. Honeycomb was built to tell you why.\n\nWith fast, flexible querying and native support for high-cardinality data, engineers can follow a question in real time across trillions of events, without deciding in advance which dashboards to build. That is the difference between watching a chart move and knowing what actually changed.\n\nThis matters more as the SDLC compresses. When code ships in hours instead of weeks, slow understanding stops being an engineering inconvenience and becomes a business risk that compounds at scale. The teams that win are the ones that can move from “something looks off” to “here is exactly why” before the customer ever notices.\n\nThe agent era asks a harder question\n\nAI has fundamentally changed the question observability has to answer. Your eval tool can tell you the answer was wrong. It cannot tell you why the run went wrong. And the root cause of an agent failure is rarely the model. It is a tool call, an API, a database, or a piece of context that was missing at the moment it mattered.\n\nThat is what Honeycomb's Agent Timeline is for. It organizes every agent invocation, LLM call, and tool call by conversation ID, so an engineer can drill from a failing span into the full trace and find the real cause. It works alongside Honeycomb Canvas, our AI-native investigation surface where engineers and AI work through the data together.\n\nWe are deliberate about where we fit. New tools are being developed to build, debug, and evaluate agents before they ship. Honeycomb owns the production picture and coexists with them, connecting a bad conversation to what the infrastructure was doing at that moment, and treating cost, quality, and reliability as one objective rather than three separate tabs or reports.\n\nPredictable costs at trillions of events\n\nCost is where most observability stories fall apart. Vendors promote flexibility right up until the bill arrives.\n\nHoneycomb takes a different position. Event-based pricing rewards teams for collecting the rich, high-cardinality telemetry that actually helps them debug, instead of taxing it. With Refinery tail sampling and the ability to route, filter, sample, and rehydrate data from S3 in real time, teams shape their data volumes without losing signal. The result is observability costs that stay predictable while keeping the telemetry signals that are most important to you.\n\nWe created this category, and we are still ahead of it\n\nHoneycomb created the observability category, and that same instinct now drives our work in agent observability. We think that is why the vision resonates. The platform is aligned with where software is actually going: AI-native, event-driven, and impossible to run blind.\n\nWe are not the only ones who see it. In a June 2026 research note, IDC wrote that Honeycomb's Agent Timeline addresses the agent audit-trace problem “with depth no competitor in this segment matches,” and described our direction as a move from remediation toward validation.\n\nFor us, this placement is a signal, not a destination. Honeycomb was built for teams thinking five steps ahead: platform engineers, AI engineers, SREs, and DevOps teams building for what comes next. If that is you, you want Honeycomb in your stack today.\n\nThank you to our customers and community who push us forward every day.\n\nNew to Honeycomb? Get your free account today\n\nDistributed tracing, BubbleUp, Agent Timeline, and more. Start for free.\n\nGartner, Magic Quadrant for Observability Platforms, 13 July 2026.\n\nGartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner's business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.\n\nGARTNER and MAGIC QUADRANT are trademarks of Gartner, Inc. and/or its affiliates."])</script><script>self.__next_f.push([1,"4f:T1474,"])</script><script>self.__next_f.push([1,"For the third consecutive year, Honeycomb has been recognized for its Ability to Execute and Completeness of Vision, and we believe for its strong vision around fast, flexible, high-cardinality querying that helps engineers understand not just that something broke, but why.\n\nThe software development lifecycle has collapsed. The neat sequence of plan, build, test, and ship that teams have relied on for 20 years is now happening in a single afternoon. AI writes a large share of the code. Agents run in production and make decisions no one scripted. The old checkpoints that used to catch problems before customers did are mostly gone.\n\nWhat is left is one question that matters more than any other: do you actually understand what your software (or agent) is doing right now? When your software is the business, that understanding is the job.\n\nThat belief is why Honeycomb exists, and we think it is why Gartner named us a Visionary in the 2026 Magic Quadrant for Observability Platforms for the third year in a row.\n\nUnderstanding, not dashboards\n\nMost tools were built to tell you that something broke. Honeycomb was built to tell you why.\n\nWith fast, flexible querying and native support for high-cardinality data, engineers can follow a question in real time across trillions of events, without deciding in advance which dashboards to build. That is the difference between watching a chart move and knowing what actually changed.\n\nThis matters more as the SDLC compresses. When code ships in hours instead of weeks, slow understanding stops being an engineering inconvenience and becomes a business risk that compounds at scale. The teams that win are the ones that can move from “something looks off” to “here is exactly why” before the customer ever notices.\n\nThe agent era asks a harder question\n\nAI has fundamentally changed the question observability has to answer. Your eval tool can tell you the answer was wrong. It cannot tell you why the run went wrong. And the root cause of an agent failure is rarely the model. It is a tool call, an API, a database, or a piece of context that was missing at the moment it mattered.\n\nThat is what Honeycomb's Agent Timeline is for. It organizes every agent invocation, LLM call, and tool call by conversation ID, so an engineer can drill from a failing span into the full trace and find the real cause. It works alongside Honeycomb Canvas, our AI-native investigation surface where engineers and AI work through the data together.\n\nWe are deliberate about where we fit. New tools are being developed to build, debug, and evaluate agents before they ship. Honeycomb owns the production picture and coexists with them, connecting a bad conversation to what the infrastructure was doing at that moment, and treating cost, quality, and reliability as one objective rather than three separate tabs or reports.\n\nPredictable costs at trillions of events\n\nCost is where most observability stories fall apart. Vendors promote flexibility right up until the bill arrives.\n\nHoneycomb takes a different position. Event-based pricing rewards teams for collecting the rich, high-cardinality telemetry that actually helps them debug, instead of taxing it. With Refinery tail sampling and the ability to route, filter, sample, and rehydrate data from S3 in real time, teams shape their data volumes without losing signal. The result is observability costs that stay predictable while keeping the telemetry signals that are most important to you.\n\nWe created this category, and we are still ahead of it\n\nHoneycomb created the observability category, and that same instinct now drives our work in agent observability. We think that is why the vision resonates. The platform is aligned with where software is actually going: AI-native, event-driven, and impossible to run blind.\n\nWe are not the only ones who see it. In a June 2026 research note, IDC wrote that Honeycomb's Agent Timeline addresses the agent audit-trace problem “with depth no competitor in this segment matches,” and described our direction as a move from remediation toward validation.\n\nFor us, this placement is a signal, not a destination. Honeycomb was built for teams thinking five steps ahead: platform engineers, AI engineers, SREs, and DevOps teams building for what comes next. If that is you, you want Honeycomb in your stack today.\n\nThank you to our customers and community who push us forward every day.\n\nNew to Honeycomb? Get your free account today\n\nDistributed tracing, BubbleUp, Agent Timeline, and more. Start for free.\n\nGartner, Magic Quadrant for Observability Platforms, 13 July 2026.\n\nGartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner's business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.\n\nGARTNER and MAGIC QUADRANT are trademarks of Gartner, Inc. and/or its affiliates."])</script><script>self.__next_f.push([1,"50:T2436,"])</script><script>self.__next_f.push([1,"A developing bottleneck\n\nRoughly a year ago, I left Honeycomb’s SRE team to join the newly formed Tenant team, which works on our Private Cloud offering. This team held some significant challenges on its roadmap if it wanted to demonstrate that the offering was possible, would be worth the cost, and could be done without representing a heavy tax on the rest of the organization.\n\nIt required taking software that was written and maintained by teams dedicated to continuous delivery—and operated in a very hands-on manner—and repackaging it in point-in-time delivery to infrastructure that isn’t fully owned—nor scalably operable—in the same way. It both had significant greenfield and brownfield elements, and the uncertainty around the project meant we needed to keep our team as small as possible.\n\nThis, of course, meant that we were expected to do some prototyping, but mostly a lot of falsework—a temporary structure used to hold a building in place until it can stand on its own, at which point the falsework is thrown away—and so using AI tools made sense.\n\nOne thing we did early on was reach team-level agreements on AI usage. We wanted to avoid a focus on individual experimentation and go for what would make the whole team productive, aligned, and coherent in our approaches—similar harnesses, editors, and models, with multiple early pairing sessions so everyone could get on a similar level as the team gelled and established the foundations we’d work on.\n\nAs our product’s (and our team’s) maturity grew, and while the technical landscape changed, we frequently revisited our choices and norms. At some point, like many teams out there, we felt that most of our work consisted of an endless stream of code reviews, as new code could be generated much faster than we could assimilate.\n\nSome more subtle patterns also surfaced. For example, people sharing time zones could end up reviewing each other’s work and moving faster than teammates who had less overlap. If someone had started slinging PRs while someone else was reviewing them, one person tended to remain in a reviewer role and the other to remain in a producer role, since reviewers wouldn’t produce and producers awaiting reviews could pick up more tasks. Our team has a very wide area (”awareness of all of Honeycomb’s features and infrastructure, plus the new places it all runs”), and knowledge concentration got amplified. We were each rapidly over-specializing in some portions of our stack.\n\nThe experiment\n\nWhen we had the inevitable discussion about what it is we should do about code reviews, three options were available:\n\nChange nothing\n\nReduce the reviewing bottleneck (this is what the industry keeps suggesting)\n\nLean into the reviewing bottleneck\n\nWe all agreed that changing nothing was suboptimal, and we weren’t willing to review nothing at this point of development. So, we decided to lean into the bottleneck. The flatly maximalist agreement we came up with was announced in February and looked a bit like this:\n\nOver in Tenant land, we’re trying to live the future of AI writing code. We clearly need to review the code before merging, but are thinking that, perhaps more importantly, we need to review the plan and prompt given to the AI that is writing the code. We came up with a few ways of doing this and are trying them out.\n\nFor each of the four major phases (plan, review, implement, finish), a Claude skill was created and put in our repositories to automate feedback phases and have a uniform set of steps.\n\nI am one of the most dissentious engineers at Honeycomb when it comes to AI. I’ve written about the risks of bad AI integration into workflows, how dissatisfied I’ve been with the marketing around it, given a keynote with Charity about all of this, and further written about the risks of mismanaging bottlenecks.\n\nHere we’d actually go nearly hands off on the code and fall into a far more passive (and risky) monitoring role. I was particularly reluctant about this aspect of it. But we were also going for the counterintuitive option: as Donella Meadows mentions when discussing complex systems, people tend to know what the leverage points are, but they also tend to try very hard to push in the wrong direction. Complex systems are counterintuitive, and pushing along the intuitive direction can often make things worse.\n\nWhat if the bottleneck exists because this stuff matters? What would happen if we were to decide our job isn’t producing and running code, but owning the system? After all, knowing what changes are happening, keeping up with the structure of our systems, discussing the changes we want to see happen, staying aligned on plans and asking for each other’s input are all critically important. If code takes almost no time to write anymore, what if we instead could use all the freed-up time to do more of everything else?\n\nDespite my disdain of a review-centric workflow, our experiment is one I was fairly enthusiastic about, because it embraced that counterintuitive sense and kept a heavy focus on us as a team rather than on individuals or automation specifically. There was a chance to emphasize different qualitative aspects of software development, where everything could be a sort of small-scale RFC, rather than obsessed with quantitatively-visible code production. And agent-driven programming where you keep steering coding assistants already felt like code reviews all the time anyway.\n\nThis is not to say the entire team liked it for these reasons. Some of us wanted to try it because it would let us spend time on things that should also be done but were usually ignored; some felt it was a good test of how hard you could drive LLMs. I can’t speak for the whole team and don’t know all of their reasoning, but we all found bits that individually made us agree to this approach. \n\nWe ran the experiment for a while, for all sizes of tickets and pull requests, with larger, more complex ones requiring everyone’s participation and some requiring only one peer.\n\nThe outcomes\n\nThe results were not bad. Despite people still owning tickets end to end in a solo manner, it started feeling like everyone was more aware of what was happening. Despite plans being wrong here and there, the surprises were more easily communicated (that’s learning and updating our shared mental models right there), and when similar tasks were reoccurring (e.g., supporting a new SaaS service into the HnyPC environment), the steps and plans could be borrowed again for inspiration and caveats. There were multiple discussions such as What’s the right level of detail for a good plan? since we all had to review it and commit to it (something glaringly missing from all the spec-oriented discussions out there).\n\nOur velocity did not seem to go down; it kept up, even as we exited greenfield and entered brownfield projects of correcting and shedding our old falsework. We created (or generated) tools that could deterministically provide output to support planning efforts, and we tried to surface some patterns that could be useful.\n\nIn practice, we ended up not sticking with the experiment in its strictest form for every piece of development we do, but still use it from time to time. The original form of the experiment is a heavy workflow. There are often tasks that are straightforward and for which the heavy planning is unnecessary. The plan may then be private and only the overall task reviewed. There are sometimes tasks where the plan is worth sharing, but steps of it may be done manually and left to be decided by the engineer—whether it is due to complexity going beyond what models do, personal desire to work on something “hands on” (either for fun or to see if we still like what the code looks like), or to experiment with alternative approaches.\n\nWe relaxed our norms and trust each other’s judgment as to when to bring up the heavy process. It may have become easier, through the new protocol, to properly break down a potential task and get everyone on the team aligned with a plan regardless of how much automation plays into it.\n\nMy own personal stance is that there are parts of our system, mainly some tests, that I think are now difficult to maintain without AI involvement, because it breaks some long-standing rules of thumb about DRY principles that AI can deal with well but people won’t. There are gotchas and brittle bits that I think people wouldn’t have put in place. But there’s also a greater shared awareness of what our roadmap is, what our team goals may be, and of what’s coming down the road. If we were on a road toward AI generating everything, we might as well make it happen in a way that builds up the team rather than one that simply accumulates more code.\n\nOther groups at Honeycomb have experimented with similar practices as well, and some of them have told us that they are gradually making their way to similar conclusions and practices, whether it comes from trying our approach or meeting us there through a different path. Elsewhere within the organization, there are still other approaches being attempted. \n\nThe code review “bottleneck” is visible to everyone, but it hasn’t been embraced everywhere."])</script><script>self.__next_f.push([1,"51:T2436,"])</script><script>self.__next_f.push([1,"A developing bottleneck\n\nRoughly a year ago, I left Honeycomb’s SRE team to join the newly formed Tenant team, which works on our Private Cloud offering. This team held some significant challenges on its roadmap if it wanted to demonstrate that the offering was possible, would be worth the cost, and could be done without representing a heavy tax on the rest of the organization.\n\nIt required taking software that was written and maintained by teams dedicated to continuous delivery—and operated in a very hands-on manner—and repackaging it in point-in-time delivery to infrastructure that isn’t fully owned—nor scalably operable—in the same way. It both had significant greenfield and brownfield elements, and the uncertainty around the project meant we needed to keep our team as small as possible.\n\nThis, of course, meant that we were expected to do some prototyping, but mostly a lot of falsework—a temporary structure used to hold a building in place until it can stand on its own, at which point the falsework is thrown away—and so using AI tools made sense.\n\nOne thing we did early on was reach team-level agreements on AI usage. We wanted to avoid a focus on individual experimentation and go for what would make the whole team productive, aligned, and coherent in our approaches—similar harnesses, editors, and models, with multiple early pairing sessions so everyone could get on a similar level as the team gelled and established the foundations we’d work on.\n\nAs our product’s (and our team’s) maturity grew, and while the technical landscape changed, we frequently revisited our choices and norms. At some point, like many teams out there, we felt that most of our work consisted of an endless stream of code reviews, as new code could be generated much faster than we could assimilate.\n\nSome more subtle patterns also surfaced. For example, people sharing time zones could end up reviewing each other’s work and moving faster than teammates who had less overlap. If someone had started slinging PRs while someone else was reviewing them, one person tended to remain in a reviewer role and the other to remain in a producer role, since reviewers wouldn’t produce and producers awaiting reviews could pick up more tasks. Our team has a very wide area (”awareness of all of Honeycomb’s features and infrastructure, plus the new places it all runs”), and knowledge concentration got amplified. We were each rapidly over-specializing in some portions of our stack.\n\nThe experiment\n\nWhen we had the inevitable discussion about what it is we should do about code reviews, three options were available:\n\nChange nothing\n\nReduce the reviewing bottleneck (this is what the industry keeps suggesting)\n\nLean into the reviewing bottleneck\n\nWe all agreed that changing nothing was suboptimal, and we weren’t willing to review nothing at this point of development. So, we decided to lean into the bottleneck. The flatly maximalist agreement we came up with was announced in February and looked a bit like this:\n\nOver in Tenant land, we’re trying to live the future of AI writing code. We clearly need to review the code before merging, but are thinking that, perhaps more importantly, we need to review the plan and prompt given to the AI that is writing the code. We came up with a few ways of doing this and are trying them out.\n\nFor each of the four major phases (plan, review, implement, finish), a Claude skill was created and put in our repositories to automate feedback phases and have a uniform set of steps.\n\nI am one of the most dissentious engineers at Honeycomb when it comes to AI. I’ve written about the risks of bad AI integration into workflows, how dissatisfied I’ve been with the marketing around it, given a keynote with Charity about all of this, and further written about the risks of mismanaging bottlenecks.\n\nHere we’d actually go nearly hands off on the code and fall into a far more passive (and risky) monitoring role. I was particularly reluctant about this aspect of it. But we were also going for the counterintuitive option: as Donella Meadows mentions when discussing complex systems, people tend to know what the leverage points are, but they also tend to try very hard to push in the wrong direction. Complex systems are counterintuitive, and pushing along the intuitive direction can often make things worse.\n\nWhat if the bottleneck exists because this stuff matters? What would happen if we were to decide our job isn’t producing and running code, but owning the system? After all, knowing what changes are happening, keeping up with the structure of our systems, discussing the changes we want to see happen, staying aligned on plans and asking for each other’s input are all critically important. If code takes almost no time to write anymore, what if we instead could use all the freed-up time to do more of everything else?\n\nDespite my disdain of a review-centric workflow, our experiment is one I was fairly enthusiastic about, because it embraced that counterintuitive sense and kept a heavy focus on us as a team rather than on individuals or automation specifically. There was a chance to emphasize different qualitative aspects of software development, where everything could be a sort of small-scale RFC, rather than obsessed with quantitatively-visible code production. And agent-driven programming where you keep steering coding assistants already felt like code reviews all the time anyway.\n\nThis is not to say the entire team liked it for these reasons. Some of us wanted to try it because it would let us spend time on things that should also be done but were usually ignored; some felt it was a good test of how hard you could drive LLMs. I can’t speak for the whole team and don’t know all of their reasoning, but we all found bits that individually made us agree to this approach. \n\nWe ran the experiment for a while, for all sizes of tickets and pull requests, with larger, more complex ones requiring everyone’s participation and some requiring only one peer.\n\nThe outcomes\n\nThe results were not bad. Despite people still owning tickets end to end in a solo manner, it started feeling like everyone was more aware of what was happening. Despite plans being wrong here and there, the surprises were more easily communicated (that’s learning and updating our shared mental models right there), and when similar tasks were reoccurring (e.g., supporting a new SaaS service into the HnyPC environment), the steps and plans could be borrowed again for inspiration and caveats. There were multiple discussions such as What’s the right level of detail for a good plan? since we all had to review it and commit to it (something glaringly missing from all the spec-oriented discussions out there).\n\nOur velocity did not seem to go down; it kept up, even as we exited greenfield and entered brownfield projects of correcting and shedding our old falsework. We created (or generated) tools that could deterministically provide output to support planning efforts, and we tried to surface some patterns that could be useful.\n\nIn practice, we ended up not sticking with the experiment in its strictest form for every piece of development we do, but still use it from time to time. The original form of the experiment is a heavy workflow. There are often tasks that are straightforward and for which the heavy planning is unnecessary. The plan may then be private and only the overall task reviewed. There are sometimes tasks where the plan is worth sharing, but steps of it may be done manually and left to be decided by the engineer—whether it is due to complexity going beyond what models do, personal desire to work on something “hands on” (either for fun or to see if we still like what the code looks like), or to experiment with alternative approaches.\n\nWe relaxed our norms and trust each other’s judgment as to when to bring up the heavy process. It may have become easier, through the new protocol, to properly break down a potential task and get everyone on the team aligned with a plan regardless of how much automation plays into it.\n\nMy own personal stance is that there are parts of our system, mainly some tests, that I think are now difficult to maintain without AI involvement, because it breaks some long-standing rules of thumb about DRY principles that AI can deal with well but people won’t. There are gotchas and brittle bits that I think people wouldn’t have put in place. But there’s also a greater shared awareness of what our roadmap is, what our team goals may be, and of what’s coming down the road. If we were on a road toward AI generating everything, we might as well make it happen in a way that builds up the team rather than one that simply accumulates more code.\n\nOther groups at Honeycomb have experimented with similar practices as well, and some of them have told us that they are gradually making their way to similar conclusions and practices, whether it comes from trying our approach or meeting us there through a different path. Elsewhere within the organization, there are still other approaches being attempted. \n\nThe code review “bottleneck” is visible to everyone, but it hasn’t been embraced everywhere."])</script><script>self.__next_f.push([1,"52:T209e,"])</script><script>self.__next_f.push([1,"A year ago, I wrote “It’s the End of Observability (and I Feel Fine).” The upshot of that post was that AI was about to fundamentally change the way we approach systems design and operation in the future. In the grand tradition, I’d like to revisit my claims from then and see how my predictions panned out.\n\nClaim: Agents can zero-shot investigations for less than a dollar\n\nI asked the agent the same question we’d ask you in a demo, and the agent figured it out with no additional prompts, training, or guidance…and it did it for sixty cents.\n\nI pointed out in my original blog that the way I evaluated our MCP server was to feed it a prompt based on the same demo that we give to people—e.g., here’s this weird latency spike, investigate it, tell me why it happened. At the time, that demo took eight tool calls and about $0.60 of inference. A year later, we process about 2 million agent-initiated query runs through Honeycomb every month!\n\nWhat’s really interesting, though, is that we’ve seen agents start to accomplish significantly longer-horizon tasks. Frontier models—like Sonnet or Fable 5—are increasingly agentic and capable. In the same agent session, we’ve seen tool calls double on average between February and June of this year. Our original demo of eight queries looks downright quaint.\n\nClaim: Humans stay in the loop\n\nI’m not gonna sit here and say this destroys the idea of humans being involved in the process, though. I don’t think that’s true. The rise of the cloud didn’t destroy the idea of IT. The existence of Rails doesn’t mean we don’t need server programmers. Productivity increases expand the map. There’ll be more software, of all shapes and sizes. We’re going to need more of everything.\n\nWhat’s really interesting is that human-initiated queries haven’t shrunk. Agents aren’t taking investigations away from humans, they’re accentuating them. People still use the UI, people still check their boards, but they’re now able to do more than they could before by leveraging AI. We see this a lot in terms of edits—while people are using agents to build boards and update SLOs, the overwhelming majority of tool calls are to just run queries.\n\nIn my blog, I claimed that productivity increases weren’t going to diminish the impact or effect of people, and that’s what the data shows. The map is not the territory, but the map has grown significantly thanks to agents.\n\nThis doesn’t mean that all of these agents are being driven by a human, though. We’re seeing an increasing amount of headless agents using our MCP; it’s actually the fastest-growing segment.\n\nClaim: It’s only getting cheaper to do this\n\nInference costs are only going down…If your product’s value proposition is nice graphs and easy instrumentation, you are cooked. An LLM commoditizes the analysis piece, OpenTelemetry commoditizes the instrumentation piece.\n\nIn my original post, I focused on the idea of inference costs going down. I think that’s, broadly, still true (even if a lot of people are getting sticker shock as they transition from all-you-can-eat to API pricing for development workloads). That said, I’m writing this post on a laptop that effortlessly runs Google’s Gemma4 model, and it’s perfectly capable of using our MCP. I think, long-run, the “cost of AI” is going to keep going down at a fixed level of capability.\n\nWhat I didn’t call, though, is that the robots are actually surprisingly efficient when it comes to using Honeycomb! On average, agent queries cost about half as much to serve as human ones. There’s a pretty easy explanation for this: the agents are able to much more accurately figure out what to search for, especially if they’re running with access to your code. They know exactly what to look at, and they don’t need to spend as much time searching across an entire environment to orient themselves.\n\nInterestingly enough, we also notice that agents—on average—tend to run queries over a 50% shorter time range than humans. Where this gets really interesting is how different the agent runs tend to be. Custom agents tend to look at smaller time windows, while human-driven ones tend to look across longer periods of time. My hypothesis is that those custom agents are probably more task-oriented (“Here’s an error, look around this time for traces”) vs. more exploratory work being done in the development loop.\n\nThe headline number, though? On average, an agent-initiated query fans out to 3.3x fewer lambdas, scans 1.8x fewer bytes, and burns 2.2x less compute. What does this mean for us? Well, from March to June we’ve grown 4x in query volume while only increasing cost by 23%, leading to a 72% reduction in unit costs for agent-initiated queries. I’ll take that!\n\n\n\nAn interesting coda to this, though, is that agents are significantly worse for caching. While we don’t see significant amounts of caching for interactive queries in general, we see almost none for agent-driven queries. This is mostly because agents don’t need to ask the same question twice. I’ve also personally observed that agents prefer to re-run queries rather than reuse existing ones, which is interesting and probably deserves more attention.\n\nThat said, we’ve seen pretty staggering levels of adoption, especially in the enterprise. One of our larger customers read 62 PiB of data in one month's time exclusively through agents, mostly through off-the-shelf tools like Claude Code.\n\nThere’s a downside to this as well, though: a lot of those queries wind up being kinda slow, because the agents aren’t chewing through nicely structured data, they’re grepping across unstructured body fields. Structured, high-cardinality, high-dimensionality data is no longer a nice-to-have for humans, it is a requirement for making agent investigations affordable. All of that data that the agent has to chew through in order to find the needle in the haystack? That’s tokens coming out of your pocket. Do you want to pay Fable rates to look through gigabytes of crappy logs?\n\nClaim: Fast feedback loops are all that matter\n\nI’m gonna put a marker out there: the only thing that really matters is fast, tight feedback loops at every stage of development and operations. AI thrives on speed—it’ll outrun you every time.\n\nJust go ask Claude to summarize the current state of the “Loops” discourse and you’ll see that the rest of the AI thought leadership industry is talking about something you read here a year ago.\n\nAnyway, there’s no prize for being first, so I instead want to share a story from one of our customers. Guy writes in to tell us how much he loves MCP and how he’s using it. He’s hooked up everything to agents that talk to Honeycomb. When a customer reports an issue or someone files a bug, the agent goes out to verify it using production telemetry. When an SLO burns, agent goes out, looks into it. Agent takes that investigation, hands it off to another agent, which goes out and writes a fix, makes a PR. Yet another agent reviews the PR and pings a human for final review and merge. PR gets deployed, goes into prod, wakes up that original agent to look at production telemetry to see if the problem was fixed. If it wasn’t, enter the loop again.\n\nThat’s the kind of tool that we’re building at Honeycomb today, yes. But what we’re building for tomorrow is so much more than that. I don’t want us to build just a really fast column store (although a really fast column store is cool). I want to make it easy for everyone to have these fast feedback loops. I want you to be able to understand what your agents are doing with your code, and I want to make it easy for you—and your agents—to learn about production and turn those learnings into knowledge.\n\nIf you’ve had the chance to check out Canvas, and our Canvas Agent, you’ve seen the first cut of this (and if you haven’t, you should check it out; it’s free!). This is just the first chapter of what we’re building, though. If you're interested in learning more about how we see AI changing observability and what we're working on here at Honeycomb, join me and the other authors of the Observability Engineering book in our on-demand AMA.\n\nP.S. We’re hiring if you wanna come work on agents with us."])</script><script>self.__next_f.push([1,"53:T209e,"])</script><script>self.__next_f.push([1,"A year ago, I wrote “It’s the End of Observability (and I Feel Fine).” The upshot of that post was that AI was about to fundamentally change the way we approach systems design and operation in the future. In the grand tradition, I’d like to revisit my claims from then and see how my predictions panned out.\n\nClaim: Agents can zero-shot investigations for less than a dollar\n\nI asked the agent the same question we’d ask you in a demo, and the agent figured it out with no additional prompts, training, or guidance…and it did it for sixty cents.\n\nI pointed out in my original blog that the way I evaluated our MCP server was to feed it a prompt based on the same demo that we give to people—e.g., here’s this weird latency spike, investigate it, tell me why it happened. At the time, that demo took eight tool calls and about $0.60 of inference. A year later, we process about 2 million agent-initiated query runs through Honeycomb every month!\n\nWhat’s really interesting, though, is that we’ve seen agents start to accomplish significantly longer-horizon tasks. Frontier models—like Sonnet or Fable 5—are increasingly agentic and capable. In the same agent session, we’ve seen tool calls double on average between February and June of this year. Our original demo of eight queries looks downright quaint.\n\nClaim: Humans stay in the loop\n\nI’m not gonna sit here and say this destroys the idea of humans being involved in the process, though. I don’t think that’s true. The rise of the cloud didn’t destroy the idea of IT. The existence of Rails doesn’t mean we don’t need server programmers. Productivity increases expand the map. There’ll be more software, of all shapes and sizes. We’re going to need more of everything.\n\nWhat’s really interesting is that human-initiated queries haven’t shrunk. Agents aren’t taking investigations away from humans, they’re accentuating them. People still use the UI, people still check their boards, but they’re now able to do more than they could before by leveraging AI. We see this a lot in terms of edits—while people are using agents to build boards and update SLOs, the overwhelming majority of tool calls are to just run queries.\n\nIn my blog, I claimed that productivity increases weren’t going to diminish the impact or effect of people, and that’s what the data shows. The map is not the territory, but the map has grown significantly thanks to agents.\n\nThis doesn’t mean that all of these agents are being driven by a human, though. We’re seeing an increasing amount of headless agents using our MCP; it’s actually the fastest-growing segment.\n\nClaim: It’s only getting cheaper to do this\n\nInference costs are only going down…If your product’s value proposition is nice graphs and easy instrumentation, you are cooked. An LLM commoditizes the analysis piece, OpenTelemetry commoditizes the instrumentation piece.\n\nIn my original post, I focused on the idea of inference costs going down. I think that’s, broadly, still true (even if a lot of people are getting sticker shock as they transition from all-you-can-eat to API pricing for development workloads). That said, I’m writing this post on a laptop that effortlessly runs Google’s Gemma4 model, and it’s perfectly capable of using our MCP. I think, long-run, the “cost of AI” is going to keep going down at a fixed level of capability.\n\nWhat I didn’t call, though, is that the robots are actually surprisingly efficient when it comes to using Honeycomb! On average, agent queries cost about half as much to serve as human ones. There’s a pretty easy explanation for this: the agents are able to much more accurately figure out what to search for, especially if they’re running with access to your code. They know exactly what to look at, and they don’t need to spend as much time searching across an entire environment to orient themselves.\n\nInterestingly enough, we also notice that agents—on average—tend to run queries over a 50% shorter time range than humans. Where this gets really interesting is how different the agent runs tend to be. Custom agents tend to look at smaller time windows, while human-driven ones tend to look across longer periods of time. My hypothesis is that those custom agents are probably more task-oriented (“Here’s an error, look around this time for traces”) vs. more exploratory work being done in the development loop.\n\nThe headline number, though? On average, an agent-initiated query fans out to 3.3x fewer lambdas, scans 1.8x fewer bytes, and burns 2.2x less compute. What does this mean for us? Well, from March to June we’ve grown 4x in query volume while only increasing cost by 23%, leading to a 72% reduction in unit costs for agent-initiated queries. I’ll take that!\n\n\n\nAn interesting coda to this, though, is that agents are significantly worse for caching. While we don’t see significant amounts of caching for interactive queries in general, we see almost none for agent-driven queries. This is mostly because agents don’t need to ask the same question twice. I’ve also personally observed that agents prefer to re-run queries rather than reuse existing ones, which is interesting and probably deserves more attention.\n\nThat said, we’ve seen pretty staggering levels of adoption, especially in the enterprise. One of our larger customers read 62 PiB of data in one month's time exclusively through agents, mostly through off-the-shelf tools like Claude Code.\n\nThere’s a downside to this as well, though: a lot of those queries wind up being kinda slow, because the agents aren’t chewing through nicely structured data, they’re grepping across unstructured body fields. Structured, high-cardinality, high-dimensionality data is no longer a nice-to-have for humans, it is a requirement for making agent investigations affordable. All of that data that the agent has to chew through in order to find the needle in the haystack? That’s tokens coming out of your pocket. Do you want to pay Fable rates to look through gigabytes of crappy logs?\n\nClaim: Fast feedback loops are all that matter\n\nI’m gonna put a marker out there: the only thing that really matters is fast, tight feedback loops at every stage of development and operations. AI thrives on speed—it’ll outrun you every time.\n\nJust go ask Claude to summarize the current state of the “Loops” discourse and you’ll see that the rest of the AI thought leadership industry is talking about something you read here a year ago.\n\nAnyway, there’s no prize for being first, so I instead want to share a story from one of our customers. Guy writes in to tell us how much he loves MCP and how he’s using it. He’s hooked up everything to agents that talk to Honeycomb. When a customer reports an issue or someone files a bug, the agent goes out to verify it using production telemetry. When an SLO burns, agent goes out, looks into it. Agent takes that investigation, hands it off to another agent, which goes out and writes a fix, makes a PR. Yet another agent reviews the PR and pings a human for final review and merge. PR gets deployed, goes into prod, wakes up that original agent to look at production telemetry to see if the problem was fixed. If it wasn’t, enter the loop again.\n\nThat’s the kind of tool that we’re building at Honeycomb today, yes. But what we’re building for tomorrow is so much more than that. I don’t want us to build just a really fast column store (although a really fast column store is cool). I want to make it easy for everyone to have these fast feedback loops. I want you to be able to understand what your agents are doing with your code, and I want to make it easy for you—and your agents—to learn about production and turn those learnings into knowledge.\n\nIf you’ve had the chance to check out Canvas, and our Canvas Agent, you’ve seen the first cut of this (and if you haven’t, you should check it out; it’s free!). This is just the first chapter of what we’re building, though. If you're interested in learning more about how we see AI changing observability and what we're working on here at Honeycomb, join me and the other authors of the Observability Engineering book in our on-demand AMA.\n\nP.S. We’re hiring if you wanna come work on agents with us."])</script><script>self.__next_f.push([1,"54:T7dfe,"])</script><script>self.__next_f.push([1,"In this two-part blog series, I give a detailed report-out on how our Honeycomb engineering team 2.5x-ed our throughput using AI without breaking everything or lowering our standards for quality. Part 1 explains how we did it and shows data about how that ramp-up happened. Part 2 shares what we learned.\n\nTL;DR\n\nPeak-weekday merges roughly doubled (~30 to ~74) as AI-attributed lines went from near-zero to a floor of 82.6% of new code by June 2026. Incidents grew too, tracking that change volume about as linearly as you'd expect; the goal now is keeping each failure cheap to contain, not holding the count flat.\n\nThe gains came in three phases: slow experimentation (2025), a tooling-driven adoption bump (October 2025), then a step-change in delegation intensity after Opus 4.6 shipped in February 2026—same engineers, same tools, but they stopped supervising every step.\n\nOur core thesis: AI amplifies your existing practices. It makes a dysfunctional org more dysfunctional and a high-autonomy, high-ownership org faster. The practices—continuous delivery, fast and AI-legible CI, closed-loop observability, CLAUDE.md, feature flags—are the actual story, not the multiplier.\n\nWhy did I put that big number in the title? It’s the number that gets you to click. But we’re going to dig into all of the caveats and details beyond just 2.5x-ing our throughput, including whether we let quality slip. This blog and its companion post are our report-out on what we did to achieve that result, how we kept the systems underneath that throughput from falling over, and what we learned in the process.\n\nSetting out to double productivity in a year\n\nIn mid-August 2025, our founders sent a letter to the whole company, not just engineering: each of us should aim to double our productivity over the next year. It was addressed to individuals; the framing underneath it was a team sport, not an individual race, and nobody was supposed to read it as a contest with their teammates. The letter named Darragh Curran’s Intercom 2x post as the framing inspiration, explicitly. Eight months later, we started to measure and reflect. This post follows on from Darragh’s retrospective on hitting 2x in nine months and Kesha Mykhailov and Niamh Young’s post on safely scaling AI auto-approval. We’re smaller than Intercom and a couple of years younger, and we’ve historically followed similar paths a few months behind them.\n\nThe number of merges on a peak weekday to Honeycomb’s monorepo more than doubled from about 30 in early 2025 to about 74 in April 2026. This codebase doubled in sixteen and a half months, from approximately 0.97 million lines at the end of 2024 past 1.94 million in the first week of May 2026, and it sits at 2.1 million as of early July. The previous doubling had taken nearly three years. Most of that net-new code was co-written with or reviewed by AI somewhere in its history.\n\nBee-ing honest about that number\n\nIt’s peak weekday, not calendar average. Wednesday no-meeting days are the most productive, both before and after AI; calendar average is roughly half of peak. That’s the peak. Don’t go looking for 70 PRs on a random Tuesday and conclude I lied to you.\n\nIt’s a floor, not a true count. One of our heaviest Claude Code users, by token volume, has zero AI-attributed git commits. They ran 22 sessions and 199 million tokens through Claude Code in 30 days, and git saw none of it, because their Co-Authored-By trailer is disabled at the tool level. If we can’t measure their AI usage, we can’t measure several other people’s either.\n\nIt’s entangled with org changes happening at the same time. In early January 2026, our founders sent a follow-up letter naming sharper strategic stakes than the August one had: rebuilding Honeycomb’s product surface and market posture to be AI-first, well beyond the original productivity target. The mid-January realignment toward greenfield, higher-AI-leverage work followed from that letter. We onboarded new engineers. We invested in platform engineering. Anyone who tells you a single factor caused their team’s gain is overstating it, including us.\n\nThere’s a big leap from “AI tooling makes engineering teams genuinely faster” to “any team that adopts it will get the same result.” Most of this post lives in the gap between those two claims. The interesting story isn’t the multiplier; it’s what we did to keep things stable underneath it, what it cost us, and what we’re still figuring out. The short version, and the line I keep coming back to every time I’m invited on stage: AI amplifies your existing practices. It can make a dysfunctional org more dysfunctional, or it can bring out the best in an org that already has high autonomy, ownership, and feedback loops. We weren’t setting out to prove that thesis; we took a challenge, and the thesis became visible after the fact.\n\nIf you caught my “AI is like chocolate” talk, you know the bit: chocolate doesn’t belong on everything, too much of it in one sitting will make you sick, and no amount of chocolate substitutes for knowing how to cook. I gave that talk as a pessimist turned realist, and that’s still who I am. What changed between then and now isn’t the metaphor; it’s that the tooling and the practices around it got good enough that chocolate’s rightful place in the kitchen got bigger. It’s more versatile and forgiving than it used to be. The concessions later in this post, in “Where the skeptics are right,” are concessions I’m still making. Being a reformed skeptic doesn’t mean I stopped being one.\n\nYou should take every number on this page, including ours, with a grain of salt. The methodology matters more than the magnitude. Keep your semantic bullshit defenses up against hype and plausible-sounding data, all the way through the rest of this post.\n\nWhat the numbers do and don’t say about quality\n\nWe haven’t had a spectacular AI-caused failure. No “AI deleted my database,” no “AI shipped code that corrupted user data.” That’s not luck; it’s not new either. It’s a result of designing defensively, whether the chaos agents be human or robot. Stacking agents on top of existing infrastructure with bulkheads between components, reviews, deploy trains, feature flags, and least-privilege access has meant outages are lower-impact, rather than either non-existent or uniformly critical-severity. If you don’t have that in place yet, that’s the thing to fix before you scale up AI usage, not after. A dropped database is a systems design issue: somebody skipped building the guardrail that would have caught it, regardless of who or what wrote the code.\n\nIncidents are growing in absolute count. From a 2024 baseline of about 18.5 incidents per quarter, Q1 2026 hit 32, 1.7x baseline, against PR throughput at about 2.5x baseline; for one quarter that looked sub-linear. Q2 didn’t hold: 53 incidents, 2.9x baseline, even as PR throughput itself held roughly flat once you back out the May freeze weeks and the January ramp-up swarm. Two quarters in, incident growth tracks change volume about as linearly as you’d expect. Change is the leading driver of incidents industry-wide (see the VOID report, Google’s DORA research), and we’re shipping a lot more of it. The law of large numbers caught up with us.\n\nWhat the data actually supports is two things: the absence of spectacular failures, plus some integrated second-order effects we’re picking up on. Broader AI-causation narratives tend to be self-flattering, whichever direction they point; AI is woven in deeply enough at this point that isolating it as a single cause is rarely a meaningful exercise. Attribution-by-cause is a fairy tale we humans tell ourselves to feel better about whatever stance we already hold.\n\nMore changes shipped means more chances for a defect to land somewhere in the batch, at whatever the org’s baseline defect rate happens to be. We’re shipping far more change, so we get far more incidents, in roughly the proportion you’d expect. It’s too early to say whether AI assistance in debugging reduces incident severity once something breaks; in some cases it’s helped us find the root cause fast, in others it’s sent us chasing a confident, wrong answer instead. That volume showed up as real strain on the teams absorbing it, not just as a line going up on a chart. We’re leaning on better automated preflight checks, among other levers, to try to bend that curve back down. The burnout risk that comes with capturing AI’s speed as pure output rather than sustainable pace is a real one, and worth naming rather than assuming away.\n\nThe metric I’d rather put on the wall isn’t PRs per day. Throughput is an input metric, not the product; it’s just the coarse measure we have today to demonstrate step-change. Throughput going up while user outcomes plateau or decline is, by definition, enshittification.\n\nWhat does “AI contribution” actually mean?\n\nThere’s no single “AI percentage.” There are at least four different denominators, and you have to be precise about which question you’re asking before you quote a number at anyone.\n\n(Vendor dashboards will happily hand you an “AI-influenced PRs” number with a confidence toggle. Set to loose confidence, ours cheerfully reported a majority of PRs as AI before we’d done any of the work below. Don’t trust low confidence. The numbers in this post come from our own git history and telemetry, calibrated by hand.)\n\nThese are calibrated floors, not point estimates. We got there by layering three corrections onto git’s raw signal: local branch trailers (245 PRs whose AI attribution was stripped by squash-merge), GitHub-API branch trailers (117 PRs where branches were deleted post-merge but we recovered the trailers via GraphQL across all 7,952 PRs), and a smell-test telemetry override (112 PRs from engineers with zero git AI attribution but heavy Claude Code session telemetry, gated per month against their actual session activity).\n\nThe 95% engineer-level adoption figure, which is closer to our gut estimates, reconciles naturally with the lower PR-level (63%) and line-level (75%) floors: high adoption, selective per-PR use. We can measure floors from git history. We can’t measure ceilings. Being clear about the difference matters more than the specific numbers do.\n\nSurviving lines at HEAD since 2024. The red band is a floor; lines from PRs with AI attribution somewhere in their history. The blue band is “no attribution,” not “no AI.”\n\nWhat happened\n\nThe adoption curve at Honeycomb has three distinct phases. Each one was driven by something different.\n\nThe first phase, April through September 2025, was sustained low-rate experimentation. About one or two new engineers adopted Claude Code per month, with support but no mandate; engineers were exploring on their own, at least until mid-August, when the founders’ letter landed and the picture blurs. AI’s share of new lines climbed modestly, peaked around 18% in June, then drifted back down to 8% by October as the honeymoon wore off. This is what “leadership opened the door” looks like in practice: not a discrete push so much as a sustained green light. The dip in the second half of 2025 was evaluation, not failure: engineers tried Claude with the model available at the time, decided it didn’t yet justify the friction, and pulled back. If the catnip is rotten, herding cats to eat the catnip is even more difficult.\n\nThe second phase began in October 2025 with a Claude Code harness improvement. Seven new adopters that month, with no model release behind it; tooling quality alone moved the needle. November and December were a pause (although some engineers used the holiday break to try the tools in their personal capacities). Then Claude 4.5 landed in late December, and adoption picked back up in January 2026 with eight new adopters, and AI’s share of new lines climbing to 18% by January.\n\nEngineers with at least one AI-attributed commit, cumulative. Each step change lines up with a capability event, not a flat schedule.\n\n\n\nOpus 4.6 launched on Thursday, February 5, 2026. The session-rate takeoff in our Claude Code telemetry lands on February 11-13: the first full work-week after a Thursday launch with a Friday-and-weekend bake-in. Distinct monthly Claude Code users stayed nearly flat across January, February, and March (59, 63, 64). Sessions per user 3.3x’d over the same window (21, 35, 70). AI’s share of new lines went from 18% in January to 46% in February to 65% in March.\n\nWe’ve been calling this confidence to delegate. The same engineers, with the same tooling, with access to the same model family, simply changed how they used it. They stopped consulting or closely monitoring each step, and started delegating. The lift is per-user-intensity, not headcount enabled.\n\nThe Q1 proof, one magnitude per panel: engineer count barely moved, sessions per engineer exploded, and committed PRs-by-model shows the delegation landing on Opus 4.6 specifically.\n\n\n\nWhile the median engineer’s PR throughput grew about 45% relative to its pre-February baseline (call that baseline 1.0x), the top of the distribution moved much further. P75 went from about 1.8x baseline to about 2.9x, roughly +64% in relative terms; the weekly maximum across our active engineers went from a 3.2x-6.4x baseline range pre-February to a 7.7x-12.3x range in April. The floor barely moved at all (P25 went from about 0.5x baseline to about 0.8x). The AI uplift is concentrated at the top end of the distribution. It is not a universal rising tide that automatically boosts every engineer, and that’s okay, because not all engineering is in the bucket of things AI accelerates. As Charity says, the closer to touching bytes on disk you are, the more cautious you need to be about reviewing everything with a paranoid lens.\n\nWe’d never had a dozen engineers a week shipping 7+ PRs each in our entire 10-year history, until March 2026. Pre-February, two to four engineers a week hit seven or more PRs; in February that was three to seven, in March seven to twelve, in April eight to sixteen. New, and now routine. And the engineers at the top aren’t a stable cast; the March-selected and April-selected top-twelve cohorts only overlap by about half. It’s a rotating cast riding the new ceiling, not a handful of superusers carrying everyone else.\n\nWeekly merged PRs (total/AI-attributed/no-attribution) and the per-engineer weekly distribution for each cut, September 2025 through the week of June 22. The top tail past 20 PRs per engineer-week appears in March and persists; the May dent is the freeze weeks, not decay. Bots excluded, including the autobot.\n\n\n\nPeak-weekday non-AI merges held roughly steady at 25-30 across the entire window; humans didn’t slow down on their best days to make room for AI. But at the org-wide weekly level, non-AI commit-hash volume declined notably, from about 120 PR commits a week pre-February to about 60-80 a week through February to April, while AI commit-hash volume grew from near-zero to 150-200 a week.\n\nSo engineers didn’t slow down on the days they were shipping; they shipped fewer human-attributed PRs in aggregate while shipping many more AI-attributed ones. Some of the +44 peak-weekday delta is genuinely new capacity. Some of it is substitution, where work that used to be human-attributed is now agent-attributed because the same engineers shifted to driving with AI rather than typing by hand. We can’t cleanly separate lift from substitution without a controlled experiment we don’t have.\n\nMay, June, and a third workflow\n\nFor this blog, we pulled a fresh data cut through June 28, rather than waiting the six months we’d originally planned since the May and June presentations. One methodology note before the numbers: this refresh also excludes mechanical bots (e.g. Dependabot) from every throughput denominator, something the April numbers above didn’t do. So the figures in this section aren’t a perfectly clean continuation of the ones above them. Same discipline as the rest of this post: check the methodology before you trust the magnitude.\n\nOn that basis, weekday-average merges went 38.0 in March, 47.9 in April, then dipped to 36.0 in May before climbing back to 41.9 across the four complete weeks of June. The May dip isn’t engineers slowing down; it’s a supply constraint. May carried an intense marketing push plus merge freezes around Innovation Week and O11yCon SF. June rebounded as soon as the freezes lifted, and peak-day merges hit 70 again on June 18, matching and sustaining April’s peak.\n\nThe more interesting news isn’t the wobble in the average. It’s that a third category of work showed up entirely.\n\nhoneycomb-autobot[bot] landed its first commit on main on April 23. It’s Claude Code on AgentCore, dispatched from RWX (the same CI substrate from earlier in this post) and traced by Honeycomb, triggered from a Linear issue or an @honeycomb-autobot mention on a review, with no human anywhere in the commit-generation loop, only the review loop. That’s categorically different from “AI-assisted coding.” Human-in-loop coding still means a person is driving the session and choosing what to commit. The autobot doesn’t have anyone in that seat at all, but instead back-loads the work onto the review cycle where work is more mechanical and a human feels confident going hands-free during the actual coding.\n\nThree months of data on it: 3 autonomous merges in April (0.3% of the month), 13 in May (1.7%), 70 across the four weeks of June (8.4%). Over the same window, human-authored merges with zero AI attribution kept shrinking, down to 211 in four weeks of June against a 2025 baseline in the 400s a month, while total throughput held at roughly twice the 2025 baseline the whole time. Same pattern as everywhere else in this post: substitution, not addition.\n\nThe three-way split, January 2025 through the four full weeks of June 2026, mechanical bots excluded. The assisted band is a floor; the autonomous band is exact, because bot authorship is self-evident.\n\n\n\nThe adoption shape looks like the rest of the story too, not a power-user phenomenon. Of the 96 autobot squashes on main through July 6, 63 carry an explicit “Triggered by” line naming 23 distinct engineers; one of the eng enablement leads who co-authored autobot is the heaviest user at 18, and everyone else in the tail is 2 to 4 each. And 55 of those 96 squashes carry no Claude co-author trailer at all, which means the same trailer-based blind spot from the “Bee-ing honest” section up top shows up here too. If we counted the autobot’s work by trailer the way we count human-driven work, we’d have missed 57% of it. We count it by author identity instead, which for a bot account is exact rather than a floor. But it’s a reminder that every attribution method has exactly one failure mode it’s blind to, and you only find out what it is by checking, not by assuming it doesn’t have one.\n\nThe autonomous workflow rides the frontier model the same way human delegation does: 30 of 33 model-tagged autobot squashes in the four weeks of June cite Opus 4.8. And it isn’t yet a lines-of-code story. Autonomous work has added roughly 5,500 lines total since April, about 0.3% of the codebase’s current size. (Added, not surviving; it’s too early to measure how many of those lines are still alive at HEAD.) Right now this is a merge-count phenomenon, not a codebase-composition one. It’ll be worth watching whether that changes.\n\nThe codebase kept growing underneath all of this. HEAD was at 1.88 million lines in April; by July 6 it’s 2,096,286, more than double the 972,000 lines at the end of 2024. Net-new code since end-2024 is now majority AI-attributed for the first time: 599,000 of 1,124,000 added lines, at least 53%, up from 41% in April. June’s line-level floor, at least 82.6% of new lines AI-attributed, is the highest month on record, ahead of April’s 75%. The projection in the April data I presented on-stage, that AI would cross a third of HEAD “around end of 2026,” turned out to be conservative; the current slope puts that closer to September, with half of HEAD by roughly mid-2027.\n\nOne number needs its own caveat rather than a triumphant read. Human-attributed lines surviving at HEAD actually ticked down slightly, from 1,509,000 in April to 1,497,000 in July. That’s not a clean “AI replaced human code” story. Some of it is genuine replacement; some of it is recalibration retroactively reclassifying PRs that were originally counted as human, as we keep finding hidden AI attribution in old PRs. Don’t read a precise story into that number. Read it as more evidence that the floor keeps rising as we get better at measuring it, which has been true of every number in this post so far.\n\nEngineers with at least one AI-attributed commit: 70, up from 64 in April. That’s broadening, not just the same 50-plus people going faster. And the frontier-model succession kept stair-stepping exactly the way it did in February: Opus 4.6 gave way to Opus 4.7, which gave way to Opus 4.8 (366 of June’s model-tagged PRs, against 31 for 4.7 and 29 for 4.6, the same one-month displacement pattern each time). Claude Fable 5, the newest Mythos-tier model, shows up in June’s trailers too, on 34 PRs. Sonnet 5 hasn’t landed a merged PR yet, since it only just launched, but it’s already showing up on PRs out for review, which tends to be the leading indicator before it shows up in this table. And the autonomous workflow doesn’t relax the one constraint that’s held the whole way through this post: a person still has to trigger it, via a Linear ticket or an @-mention. Our human names have stopped showing up on the commit messages. The only adoption ceiling is still how many engineers choose to reach for it.\n\nThe succession, extended through June. Each Opus release displaces its predecessor in committed work within about a month of arriving; the February pattern wasn’t a one-off.\n\nPossible (overlapping) explanations\n\nWe can name several factors that line up with the inflection. None of them, on its own, explains the curve, and we can’t isolate which mattered most without a controlled test we can’t run in retrospect. What follows is a list of overlapping contributions our own team has flagged, not one single cause dressed up as several.\n\nFrontier-model capability: Opus 4.6, in February 2026, was the specific release that produced the session-rate jump. Earlier Opus releases (4.1 in August 2025, 4.5 in December) shifted the floor without producing a takeoff. The rest of the model family in the same window, Sonnet 4.6 and Haiku 4.5, didn’t move the committable-delegation needle in our telemetry: Sonnet 4.6 launched February 17 with full Honeycomb adoption (41 distinct users) but produced only 35 commits in March and 27 in April, against Opus 4.6’s 232 and 127. It was frontier-model capability specifically that crossed the threshold from consultation to delegation, not “any new model.”\n\nLeadership signaling, twice: August 2025’s letter set the explicit “experiment, take time to figure out what AI does for your work” frame. January 2026’s follow-up named sharper strategic stakes: rebuild the product surface and the market posture for AI-first. The mid-January realignment toward greenfield, higher-AI-leverage work followed from that. Without either signal, I doubt the throughput curve looks the same.\n\nTooling that improved over months: The October 2025 Claude Code harness improvements produced a noticeable adoption step on their own, with no model release behind them. Each release of the tooling added something some engineer needed before they could delegate. Models alone don’t explain the curve; the wrapper around the model matters just as much as the model does.\n\nSubstrate already in place: Continuous delivery, code-ownership practices, fast CI, blameless incident analysis, observability that links shipped code back to the PR that created it: the practices the rest of this post is about. AI work landed in an org that already had the substrate to absorb it. We can’t run the counterfactual, but the practices section below is our best account of why this didn’t go badly.\n\nCumulative engineer-level expertise: From April through September 2025, one or two engineers a month adopted Claude Code. By February 2026 we had a base of fifty-plus engineers who’d been using it for months and could mentor everyone else. That cohort effect is hard to pin to any single date; it’s the gradual accumulation of in-house expertise that the February takeoff drew on.\n\nThese factors overlap, and we can’t say any one of them in isolation would have gotten us here. Leadership signaling probably amplifies tooling improvements. Substrate makes it possible for engineers to share what they’re learning. Frontier-model capability matters more in an org that already has the substrate and the cohort to use it well. The factors compound rather than substitute for one another. Anyone telling you a single factor caused their team’s gain is overstating it. Including us.\n\nWe followed Intercom, with caveats\n\nThree things are worth crediting in Intercom's playbook.\n\nThey set a more realistic and achievable 2x goal, not the 10x-and-up claims that were common currency during the 2024 hype cycle. Discipline matters when the temptation is to oversell what AI delivers. We wanted some of that discipline for ourselves.\n\nThey were transparent about both the methodology and the org-shape changes that came with the gain. The substrate Intercom built, a Claude Code plugin marketplace with 153 contributors representing 31% of their R\u0026D org and 267 skills, is genuinely platform infrastructure that ships its own product. They spun up a dedicated team, team-2x, to build it. We’re smaller and a couple of years younger, but we’re building toward something in the same shape, at our scale.\n\nThey engaged their auditors, Schellman, early, before scaling auto-approval, to confirm that the evidence trail an AI-approved PR produces is the same evidence trail an auditor expects from a human-approved one. The “who” changes. The “what” doesn’t. That’s a model worth following: build for safety first, and compliance follows from it.\n\nWhere we differ is that we’re at zero auto-approval today, and they’re at 19.2% as of April. That’s deliberate sequencing on our part, not a sign that we're “behind.” Before you can safely scale auto-approval, which is automating the bug-catching half of PR review, you need substantial substrate underneath it. The compliance question is necessary but not sufficient; the technical preconditions sit underneath the procedural ones. You need codified rules in CLAUDE.md and skills that an auto-review agent can actually verify against; MCP-mediated dev-loop access so the agent reviews against the same context a human would have had (design intent, ticket history, production behavior); fast and AI-legible CI so the verification loop closes quickly; closed-loop production observability that links shipped code back to the PR that created it; and a dissemination layer so humans stay aware of what’s shipping even when they’re not gating it.\n\nA 19% auto-approval number means radically different things at an org that invested in the substrate before turning the switch versus one that just turned the switch. Intercom’s number is downstream of substrate they built first. A company that turns on “auto-approve PRs under 20 lines” without equivalent substrate will report the same number, but it’s measuring rubber-stamping against weak constraints, not safe automation against strong ones. Different point on the same trajectory.\n\nThe headline finding from Intercom’s auto-approval post is the most striking parallel to our own data. They report AI-authored backend code reverting at 0.53% and AI-authored frontend code reverting at 0.22%, against human-authored revert rates of 5.39% and 2.00% respectively. It’s worth naming the selection effect here: if the easier, lower-risk changes increasingly get auto-approved, humans are left reviewing the harder residual cases, which would push human revert rates up for reasons that have nothing to do with humans getting worse at their jobs. Their downtime from breaking code changes dropped 35% even as deployment frequency doubled. Theirs is a per-PR claim about strict, decomposed, sub-agent-driven review against an Intercom-specific guidance flywheel. Ours is a per-quarter claim about severity, not volume: incident count is tracking change volume about as linearly as you’d expect, but we haven’t had a spectacular AI failure, and our guardrails are aimed at containing how bad any one incident gets rather than pretending we can hold the count flat. Different denominators, same direction. Both posts are pushing back on the naive “more code, more failures” intuition, from different evidence.\n\nWe had a private conversation with the Intercom team in early May 2026. They hit the same February 2026 inflection point we did. The Opus 4.6 unlock was the gut-call attribution from multiple Intercom engineers, though they noted it was almost impossible to disentangle from their internal mandates and team-2x activity in the same period. They’re partnering with a Stanford research group to try to isolate the variables, and even that group’s initial pre-January analysis missed the inflection entirely. The world’s most data-rich org on this exact question is paying academic researchers to help them figure it out, and they still don’t know.\n\nThat independent-org corroboration is the cleanest natural experiment either of us has. Two separate orgs, same month, same uncertainty about cause, same direction. That’s worth more than either of our individual analyses on its own. It’s also worth weighing against the broader base rate: DX’s longitudinal study across roughly 400 companies found AI usage up 65% translating to only about 8% more PR throughput on average. We’re the outlier case here, not the median one.\n\nHere's the truth: Nothing I've written here will help you if your underlying org isn't already healthy and functional. AI just amplifies what you're already doing. Read part 2 of this blog series to see what we learned.\n\nAI Influence Level disclosure\n\nThis post: AIL-3.0 (substantial AI involvement, human steering on every load-bearing call). The data analysis, custom git-of-theseus extensions, commit-history trawling, calibration overrides, the merge-rate and incident charts, was AI-assisted. The July refresh, the May-June numbers and the autonomous-workflow analysis added above, was pulled with Claude Fable 5. The slide deck this post derives from was composed with AI assistance, and AI assistance was used to reformat the slide bullet points and speaker notes into essay form. The voice and tone polish was done in a separate Claude project tuned to my writing style, followed by a very extensive manual editing process where I further added or changed at least 20% of the words.\n\nStrategic decisions, data interpretation, and judgment calls about what to keep and what to cut are mine. AI helped me move faster on a deadline; it didn’t supply the substance. The talk and this post are themselves an example of the same 2x story they describe: weeks of human work, AI-assisted, not 10x. The substance wouldn’t exist without me, and the level of polish wouldn’t exist without AI.\n\nAIL framework: danielmiessler.com/blog/ai-influence-level-ail. Illustrations in the original talk: AIL-0, by bbghost.bsky.social. Art should be made by artists, not machines. Illustrations in the blog by our amazing design team.\n\nSources and context: Fin/Intercom 2x post; Fin/Intercom AI PR approval safety post; Honeycomb-Intercom case study; Emily Nakashima on AI-amplified engineering leadership. This post is adapted from the talk of the same name, delivered at Sydney Tech Leaders and LDX3 London in 2026."])</script><script>self.__next_f.push([1,"55:T7dfe,"])</script><script>self.__next_f.push([1,"In this two-part blog series, I give a detailed report-out on how our Honeycomb engineering team 2.5x-ed our throughput using AI without breaking everything or lowering our standards for quality. Part 1 explains how we did it and shows data about how that ramp-up happened. Part 2 shares what we learned.\n\nTL;DR\n\nPeak-weekday merges roughly doubled (~30 to ~74) as AI-attributed lines went from near-zero to a floor of 82.6% of new code by June 2026. Incidents grew too, tracking that change volume about as linearly as you'd expect; the goal now is keeping each failure cheap to contain, not holding the count flat.\n\nThe gains came in three phases: slow experimentation (2025), a tooling-driven adoption bump (October 2025), then a step-change in delegation intensity after Opus 4.6 shipped in February 2026—same engineers, same tools, but they stopped supervising every step.\n\nOur core thesis: AI amplifies your existing practices. It makes a dysfunctional org more dysfunctional and a high-autonomy, high-ownership org faster. The practices—continuous delivery, fast and AI-legible CI, closed-loop observability, CLAUDE.md, feature flags—are the actual story, not the multiplier.\n\nWhy did I put that big number in the title? It’s the number that gets you to click. But we’re going to dig into all of the caveats and details beyond just 2.5x-ing our throughput, including whether we let quality slip. This blog and its companion post are our report-out on what we did to achieve that result, how we kept the systems underneath that throughput from falling over, and what we learned in the process.\n\nSetting out to double productivity in a year\n\nIn mid-August 2025, our founders sent a letter to the whole company, not just engineering: each of us should aim to double our productivity over the next year. It was addressed to individuals; the framing underneath it was a team sport, not an individual race, and nobody was supposed to read it as a contest with their teammates. The letter named Darragh Curran’s Intercom 2x post as the framing inspiration, explicitly. Eight months later, we started to measure and reflect. This post follows on from Darragh’s retrospective on hitting 2x in nine months and Kesha Mykhailov and Niamh Young’s post on safely scaling AI auto-approval. We’re smaller than Intercom and a couple of years younger, and we’ve historically followed similar paths a few months behind them.\n\nThe number of merges on a peak weekday to Honeycomb’s monorepo more than doubled from about 30 in early 2025 to about 74 in April 2026. This codebase doubled in sixteen and a half months, from approximately 0.97 million lines at the end of 2024 past 1.94 million in the first week of May 2026, and it sits at 2.1 million as of early July. The previous doubling had taken nearly three years. Most of that net-new code was co-written with or reviewed by AI somewhere in its history.\n\nBee-ing honest about that number\n\nIt’s peak weekday, not calendar average. Wednesday no-meeting days are the most productive, both before and after AI; calendar average is roughly half of peak. That’s the peak. Don’t go looking for 70 PRs on a random Tuesday and conclude I lied to you.\n\nIt’s a floor, not a true count. One of our heaviest Claude Code users, by token volume, has zero AI-attributed git commits. They ran 22 sessions and 199 million tokens through Claude Code in 30 days, and git saw none of it, because their Co-Authored-By trailer is disabled at the tool level. If we can’t measure their AI usage, we can’t measure several other people’s either.\n\nIt’s entangled with org changes happening at the same time. In early January 2026, our founders sent a follow-up letter naming sharper strategic stakes than the August one had: rebuilding Honeycomb’s product surface and market posture to be AI-first, well beyond the original productivity target. The mid-January realignment toward greenfield, higher-AI-leverage work followed from that letter. We onboarded new engineers. We invested in platform engineering. Anyone who tells you a single factor caused their team’s gain is overstating it, including us.\n\nThere’s a big leap from “AI tooling makes engineering teams genuinely faster” to “any team that adopts it will get the same result.” Most of this post lives in the gap between those two claims. The interesting story isn’t the multiplier; it’s what we did to keep things stable underneath it, what it cost us, and what we’re still figuring out. The short version, and the line I keep coming back to every time I’m invited on stage: AI amplifies your existing practices. It can make a dysfunctional org more dysfunctional, or it can bring out the best in an org that already has high autonomy, ownership, and feedback loops. We weren’t setting out to prove that thesis; we took a challenge, and the thesis became visible after the fact.\n\nIf you caught my “AI is like chocolate” talk, you know the bit: chocolate doesn’t belong on everything, too much of it in one sitting will make you sick, and no amount of chocolate substitutes for knowing how to cook. I gave that talk as a pessimist turned realist, and that’s still who I am. What changed between then and now isn’t the metaphor; it’s that the tooling and the practices around it got good enough that chocolate’s rightful place in the kitchen got bigger. It’s more versatile and forgiving than it used to be. The concessions later in this post, in “Where the skeptics are right,” are concessions I’m still making. Being a reformed skeptic doesn’t mean I stopped being one.\n\nYou should take every number on this page, including ours, with a grain of salt. The methodology matters more than the magnitude. Keep your semantic bullshit defenses up against hype and plausible-sounding data, all the way through the rest of this post.\n\nWhat the numbers do and don’t say about quality\n\nWe haven’t had a spectacular AI-caused failure. No “AI deleted my database,” no “AI shipped code that corrupted user data.” That’s not luck; it’s not new either. It’s a result of designing defensively, whether the chaos agents be human or robot. Stacking agents on top of existing infrastructure with bulkheads between components, reviews, deploy trains, feature flags, and least-privilege access has meant outages are lower-impact, rather than either non-existent or uniformly critical-severity. If you don’t have that in place yet, that’s the thing to fix before you scale up AI usage, not after. A dropped database is a systems design issue: somebody skipped building the guardrail that would have caught it, regardless of who or what wrote the code.\n\nIncidents are growing in absolute count. From a 2024 baseline of about 18.5 incidents per quarter, Q1 2026 hit 32, 1.7x baseline, against PR throughput at about 2.5x baseline; for one quarter that looked sub-linear. Q2 didn’t hold: 53 incidents, 2.9x baseline, even as PR throughput itself held roughly flat once you back out the May freeze weeks and the January ramp-up swarm. Two quarters in, incident growth tracks change volume about as linearly as you’d expect. Change is the leading driver of incidents industry-wide (see the VOID report, Google’s DORA research), and we’re shipping a lot more of it. The law of large numbers caught up with us.\n\nWhat the data actually supports is two things: the absence of spectacular failures, plus some integrated second-order effects we’re picking up on. Broader AI-causation narratives tend to be self-flattering, whichever direction they point; AI is woven in deeply enough at this point that isolating it as a single cause is rarely a meaningful exercise. Attribution-by-cause is a fairy tale we humans tell ourselves to feel better about whatever stance we already hold.\n\nMore changes shipped means more chances for a defect to land somewhere in the batch, at whatever the org’s baseline defect rate happens to be. We’re shipping far more change, so we get far more incidents, in roughly the proportion you’d expect. It’s too early to say whether AI assistance in debugging reduces incident severity once something breaks; in some cases it’s helped us find the root cause fast, in others it’s sent us chasing a confident, wrong answer instead. That volume showed up as real strain on the teams absorbing it, not just as a line going up on a chart. We’re leaning on better automated preflight checks, among other levers, to try to bend that curve back down. The burnout risk that comes with capturing AI’s speed as pure output rather than sustainable pace is a real one, and worth naming rather than assuming away.\n\nThe metric I’d rather put on the wall isn’t PRs per day. Throughput is an input metric, not the product; it’s just the coarse measure we have today to demonstrate step-change. Throughput going up while user outcomes plateau or decline is, by definition, enshittification.\n\nWhat does “AI contribution” actually mean?\n\nThere’s no single “AI percentage.” There are at least four different denominators, and you have to be precise about which question you’re asking before you quote a number at anyone.\n\n(Vendor dashboards will happily hand you an “AI-influenced PRs” number with a confidence toggle. Set to loose confidence, ours cheerfully reported a majority of PRs as AI before we’d done any of the work below. Don’t trust low confidence. The numbers in this post come from our own git history and telemetry, calibrated by hand.)\n\nThese are calibrated floors, not point estimates. We got there by layering three corrections onto git’s raw signal: local branch trailers (245 PRs whose AI attribution was stripped by squash-merge), GitHub-API branch trailers (117 PRs where branches were deleted post-merge but we recovered the trailers via GraphQL across all 7,952 PRs), and a smell-test telemetry override (112 PRs from engineers with zero git AI attribution but heavy Claude Code session telemetry, gated per month against their actual session activity).\n\nThe 95% engineer-level adoption figure, which is closer to our gut estimates, reconciles naturally with the lower PR-level (63%) and line-level (75%) floors: high adoption, selective per-PR use. We can measure floors from git history. We can’t measure ceilings. Being clear about the difference matters more than the specific numbers do.\n\nSurviving lines at HEAD since 2024. The red band is a floor; lines from PRs with AI attribution somewhere in their history. The blue band is “no attribution,” not “no AI.”\n\nWhat happened\n\nThe adoption curve at Honeycomb has three distinct phases. Each one was driven by something different.\n\nThe first phase, April through September 2025, was sustained low-rate experimentation. About one or two new engineers adopted Claude Code per month, with support but no mandate; engineers were exploring on their own, at least until mid-August, when the founders’ letter landed and the picture blurs. AI’s share of new lines climbed modestly, peaked around 18% in June, then drifted back down to 8% by October as the honeymoon wore off. This is what “leadership opened the door” looks like in practice: not a discrete push so much as a sustained green light. The dip in the second half of 2025 was evaluation, not failure: engineers tried Claude with the model available at the time, decided it didn’t yet justify the friction, and pulled back. If the catnip is rotten, herding cats to eat the catnip is even more difficult.\n\nThe second phase began in October 2025 with a Claude Code harness improvement. Seven new adopters that month, with no model release behind it; tooling quality alone moved the needle. November and December were a pause (although some engineers used the holiday break to try the tools in their personal capacities). Then Claude 4.5 landed in late December, and adoption picked back up in January 2026 with eight new adopters, and AI’s share of new lines climbing to 18% by January.\n\nEngineers with at least one AI-attributed commit, cumulative. Each step change lines up with a capability event, not a flat schedule.\n\n\n\nOpus 4.6 launched on Thursday, February 5, 2026. The session-rate takeoff in our Claude Code telemetry lands on February 11-13: the first full work-week after a Thursday launch with a Friday-and-weekend bake-in. Distinct monthly Claude Code users stayed nearly flat across January, February, and March (59, 63, 64). Sessions per user 3.3x’d over the same window (21, 35, 70). AI’s share of new lines went from 18% in January to 46% in February to 65% in March.\n\nWe’ve been calling this confidence to delegate. The same engineers, with the same tooling, with access to the same model family, simply changed how they used it. They stopped consulting or closely monitoring each step, and started delegating. The lift is per-user-intensity, not headcount enabled.\n\nThe Q1 proof, one magnitude per panel: engineer count barely moved, sessions per engineer exploded, and committed PRs-by-model shows the delegation landing on Opus 4.6 specifically.\n\n\n\nWhile the median engineer’s PR throughput grew about 45% relative to its pre-February baseline (call that baseline 1.0x), the top of the distribution moved much further. P75 went from about 1.8x baseline to about 2.9x, roughly +64% in relative terms; the weekly maximum across our active engineers went from a 3.2x-6.4x baseline range pre-February to a 7.7x-12.3x range in April. The floor barely moved at all (P25 went from about 0.5x baseline to about 0.8x). The AI uplift is concentrated at the top end of the distribution. It is not a universal rising tide that automatically boosts every engineer, and that’s okay, because not all engineering is in the bucket of things AI accelerates. As Charity says, the closer to touching bytes on disk you are, the more cautious you need to be about reviewing everything with a paranoid lens.\n\nWe’d never had a dozen engineers a week shipping 7+ PRs each in our entire 10-year history, until March 2026. Pre-February, two to four engineers a week hit seven or more PRs; in February that was three to seven, in March seven to twelve, in April eight to sixteen. New, and now routine. And the engineers at the top aren’t a stable cast; the March-selected and April-selected top-twelve cohorts only overlap by about half. It’s a rotating cast riding the new ceiling, not a handful of superusers carrying everyone else.\n\nWeekly merged PRs (total/AI-attributed/no-attribution) and the per-engineer weekly distribution for each cut, September 2025 through the week of June 22. The top tail past 20 PRs per engineer-week appears in March and persists; the May dent is the freeze weeks, not decay. Bots excluded, including the autobot.\n\n\n\nPeak-weekday non-AI merges held roughly steady at 25-30 across the entire window; humans didn’t slow down on their best days to make room for AI. But at the org-wide weekly level, non-AI commit-hash volume declined notably, from about 120 PR commits a week pre-February to about 60-80 a week through February to April, while AI commit-hash volume grew from near-zero to 150-200 a week.\n\nSo engineers didn’t slow down on the days they were shipping; they shipped fewer human-attributed PRs in aggregate while shipping many more AI-attributed ones. Some of the +44 peak-weekday delta is genuinely new capacity. Some of it is substitution, where work that used to be human-attributed is now agent-attributed because the same engineers shifted to driving with AI rather than typing by hand. We can’t cleanly separate lift from substitution without a controlled experiment we don’t have.\n\nMay, June, and a third workflow\n\nFor this blog, we pulled a fresh data cut through June 28, rather than waiting the six months we’d originally planned since the May and June presentations. One methodology note before the numbers: this refresh also excludes mechanical bots (e.g. Dependabot) from every throughput denominator, something the April numbers above didn’t do. So the figures in this section aren’t a perfectly clean continuation of the ones above them. Same discipline as the rest of this post: check the methodology before you trust the magnitude.\n\nOn that basis, weekday-average merges went 38.0 in March, 47.9 in April, then dipped to 36.0 in May before climbing back to 41.9 across the four complete weeks of June. The May dip isn’t engineers slowing down; it’s a supply constraint. May carried an intense marketing push plus merge freezes around Innovation Week and O11yCon SF. June rebounded as soon as the freezes lifted, and peak-day merges hit 70 again on June 18, matching and sustaining April’s peak.\n\nThe more interesting news isn’t the wobble in the average. It’s that a third category of work showed up entirely.\n\nhoneycomb-autobot[bot] landed its first commit on main on April 23. It’s Claude Code on AgentCore, dispatched from RWX (the same CI substrate from earlier in this post) and traced by Honeycomb, triggered from a Linear issue or an @honeycomb-autobot mention on a review, with no human anywhere in the commit-generation loop, only the review loop. That’s categorically different from “AI-assisted coding.” Human-in-loop coding still means a person is driving the session and choosing what to commit. The autobot doesn’t have anyone in that seat at all, but instead back-loads the work onto the review cycle where work is more mechanical and a human feels confident going hands-free during the actual coding.\n\nThree months of data on it: 3 autonomous merges in April (0.3% of the month), 13 in May (1.7%), 70 across the four weeks of June (8.4%). Over the same window, human-authored merges with zero AI attribution kept shrinking, down to 211 in four weeks of June against a 2025 baseline in the 400s a month, while total throughput held at roughly twice the 2025 baseline the whole time. Same pattern as everywhere else in this post: substitution, not addition.\n\nThe three-way split, January 2025 through the four full weeks of June 2026, mechanical bots excluded. The assisted band is a floor; the autonomous band is exact, because bot authorship is self-evident.\n\n\n\nThe adoption shape looks like the rest of the story too, not a power-user phenomenon. Of the 96 autobot squashes on main through July 6, 63 carry an explicit “Triggered by” line naming 23 distinct engineers; one of the eng enablement leads who co-authored autobot is the heaviest user at 18, and everyone else in the tail is 2 to 4 each. And 55 of those 96 squashes carry no Claude co-author trailer at all, which means the same trailer-based blind spot from the “Bee-ing honest” section up top shows up here too. If we counted the autobot’s work by trailer the way we count human-driven work, we’d have missed 57% of it. We count it by author identity instead, which for a bot account is exact rather than a floor. But it’s a reminder that every attribution method has exactly one failure mode it’s blind to, and you only find out what it is by checking, not by assuming it doesn’t have one.\n\nThe autonomous workflow rides the frontier model the same way human delegation does: 30 of 33 model-tagged autobot squashes in the four weeks of June cite Opus 4.8. And it isn’t yet a lines-of-code story. Autonomous work has added roughly 5,500 lines total since April, about 0.3% of the codebase’s current size. (Added, not surviving; it’s too early to measure how many of those lines are still alive at HEAD.) Right now this is a merge-count phenomenon, not a codebase-composition one. It’ll be worth watching whether that changes.\n\nThe codebase kept growing underneath all of this. HEAD was at 1.88 million lines in April; by July 6 it’s 2,096,286, more than double the 972,000 lines at the end of 2024. Net-new code since end-2024 is now majority AI-attributed for the first time: 599,000 of 1,124,000 added lines, at least 53%, up from 41% in April. June’s line-level floor, at least 82.6% of new lines AI-attributed, is the highest month on record, ahead of April’s 75%. The projection in the April data I presented on-stage, that AI would cross a third of HEAD “around end of 2026,” turned out to be conservative; the current slope puts that closer to September, with half of HEAD by roughly mid-2027.\n\nOne number needs its own caveat rather than a triumphant read. Human-attributed lines surviving at HEAD actually ticked down slightly, from 1,509,000 in April to 1,497,000 in July. That’s not a clean “AI replaced human code” story. Some of it is genuine replacement; some of it is recalibration retroactively reclassifying PRs that were originally counted as human, as we keep finding hidden AI attribution in old PRs. Don’t read a precise story into that number. Read it as more evidence that the floor keeps rising as we get better at measuring it, which has been true of every number in this post so far.\n\nEngineers with at least one AI-attributed commit: 70, up from 64 in April. That’s broadening, not just the same 50-plus people going faster. And the frontier-model succession kept stair-stepping exactly the way it did in February: Opus 4.6 gave way to Opus 4.7, which gave way to Opus 4.8 (366 of June’s model-tagged PRs, against 31 for 4.7 and 29 for 4.6, the same one-month displacement pattern each time). Claude Fable 5, the newest Mythos-tier model, shows up in June’s trailers too, on 34 PRs. Sonnet 5 hasn’t landed a merged PR yet, since it only just launched, but it’s already showing up on PRs out for review, which tends to be the leading indicator before it shows up in this table. And the autonomous workflow doesn’t relax the one constraint that’s held the whole way through this post: a person still has to trigger it, via a Linear ticket or an @-mention. Our human names have stopped showing up on the commit messages. The only adoption ceiling is still how many engineers choose to reach for it.\n\nThe succession, extended through June. Each Opus release displaces its predecessor in committed work within about a month of arriving; the February pattern wasn’t a one-off.\n\nPossible (overlapping) explanations\n\nWe can name several factors that line up with the inflection. None of them, on its own, explains the curve, and we can’t isolate which mattered most without a controlled test we can’t run in retrospect. What follows is a list of overlapping contributions our own team has flagged, not one single cause dressed up as several.\n\nFrontier-model capability: Opus 4.6, in February 2026, was the specific release that produced the session-rate jump. Earlier Opus releases (4.1 in August 2025, 4.5 in December) shifted the floor without producing a takeoff. The rest of the model family in the same window, Sonnet 4.6 and Haiku 4.5, didn’t move the committable-delegation needle in our telemetry: Sonnet 4.6 launched February 17 with full Honeycomb adoption (41 distinct users) but produced only 35 commits in March and 27 in April, against Opus 4.6’s 232 and 127. It was frontier-model capability specifically that crossed the threshold from consultation to delegation, not “any new model.”\n\nLeadership signaling, twice: August 2025’s letter set the explicit “experiment, take time to figure out what AI does for your work” frame. January 2026’s follow-up named sharper strategic stakes: rebuild the product surface and the market posture for AI-first. The mid-January realignment toward greenfield, higher-AI-leverage work followed from that. Without either signal, I doubt the throughput curve looks the same.\n\nTooling that improved over months: The October 2025 Claude Code harness improvements produced a noticeable adoption step on their own, with no model release behind them. Each release of the tooling added something some engineer needed before they could delegate. Models alone don’t explain the curve; the wrapper around the model matters just as much as the model does.\n\nSubstrate already in place: Continuous delivery, code-ownership practices, fast CI, blameless incident analysis, observability that links shipped code back to the PR that created it: the practices the rest of this post is about. AI work landed in an org that already had the substrate to absorb it. We can’t run the counterfactual, but the practices section below is our best account of why this didn’t go badly.\n\nCumulative engineer-level expertise: From April through September 2025, one or two engineers a month adopted Claude Code. By February 2026 we had a base of fifty-plus engineers who’d been using it for months and could mentor everyone else. That cohort effect is hard to pin to any single date; it’s the gradual accumulation of in-house expertise that the February takeoff drew on.\n\nThese factors overlap, and we can’t say any one of them in isolation would have gotten us here. Leadership signaling probably amplifies tooling improvements. Substrate makes it possible for engineers to share what they’re learning. Frontier-model capability matters more in an org that already has the substrate and the cohort to use it well. The factors compound rather than substitute for one another. Anyone telling you a single factor caused their team’s gain is overstating it. Including us.\n\nWe followed Intercom, with caveats\n\nThree things are worth crediting in Intercom's playbook.\n\nThey set a more realistic and achievable 2x goal, not the 10x-and-up claims that were common currency during the 2024 hype cycle. Discipline matters when the temptation is to oversell what AI delivers. We wanted some of that discipline for ourselves.\n\nThey were transparent about both the methodology and the org-shape changes that came with the gain. The substrate Intercom built, a Claude Code plugin marketplace with 153 contributors representing 31% of their R\u0026D org and 267 skills, is genuinely platform infrastructure that ships its own product. They spun up a dedicated team, team-2x, to build it. We’re smaller and a couple of years younger, but we’re building toward something in the same shape, at our scale.\n\nThey engaged their auditors, Schellman, early, before scaling auto-approval, to confirm that the evidence trail an AI-approved PR produces is the same evidence trail an auditor expects from a human-approved one. The “who” changes. The “what” doesn’t. That’s a model worth following: build for safety first, and compliance follows from it.\n\nWhere we differ is that we’re at zero auto-approval today, and they’re at 19.2% as of April. That’s deliberate sequencing on our part, not a sign that we're “behind.” Before you can safely scale auto-approval, which is automating the bug-catching half of PR review, you need substantial substrate underneath it. The compliance question is necessary but not sufficient; the technical preconditions sit underneath the procedural ones. You need codified rules in CLAUDE.md and skills that an auto-review agent can actually verify against; MCP-mediated dev-loop access so the agent reviews against the same context a human would have had (design intent, ticket history, production behavior); fast and AI-legible CI so the verification loop closes quickly; closed-loop production observability that links shipped code back to the PR that created it; and a dissemination layer so humans stay aware of what’s shipping even when they’re not gating it.\n\nA 19% auto-approval number means radically different things at an org that invested in the substrate before turning the switch versus one that just turned the switch. Intercom’s number is downstream of substrate they built first. A company that turns on “auto-approve PRs under 20 lines” without equivalent substrate will report the same number, but it’s measuring rubber-stamping against weak constraints, not safe automation against strong ones. Different point on the same trajectory.\n\nThe headline finding from Intercom’s auto-approval post is the most striking parallel to our own data. They report AI-authored backend code reverting at 0.53% and AI-authored frontend code reverting at 0.22%, against human-authored revert rates of 5.39% and 2.00% respectively. It’s worth naming the selection effect here: if the easier, lower-risk changes increasingly get auto-approved, humans are left reviewing the harder residual cases, which would push human revert rates up for reasons that have nothing to do with humans getting worse at their jobs. Their downtime from breaking code changes dropped 35% even as deployment frequency doubled. Theirs is a per-PR claim about strict, decomposed, sub-agent-driven review against an Intercom-specific guidance flywheel. Ours is a per-quarter claim about severity, not volume: incident count is tracking change volume about as linearly as you’d expect, but we haven’t had a spectacular AI failure, and our guardrails are aimed at containing how bad any one incident gets rather than pretending we can hold the count flat. Different denominators, same direction. Both posts are pushing back on the naive “more code, more failures” intuition, from different evidence.\n\nWe had a private conversation with the Intercom team in early May 2026. They hit the same February 2026 inflection point we did. The Opus 4.6 unlock was the gut-call attribution from multiple Intercom engineers, though they noted it was almost impossible to disentangle from their internal mandates and team-2x activity in the same period. They’re partnering with a Stanford research group to try to isolate the variables, and even that group’s initial pre-January analysis missed the inflection entirely. The world’s most data-rich org on this exact question is paying academic researchers to help them figure it out, and they still don’t know.\n\nThat independent-org corroboration is the cleanest natural experiment either of us has. Two separate orgs, same month, same uncertainty about cause, same direction. That’s worth more than either of our individual analyses on its own. It’s also worth weighing against the broader base rate: DX’s longitudinal study across roughly 400 companies found AI usage up 65% translating to only about 8% more PR throughput on average. We’re the outlier case here, not the median one.\n\nHere's the truth: Nothing I've written here will help you if your underlying org isn't already healthy and functional. AI just amplifies what you're already doing. Read part 2 of this blog series to see what we learned.\n\nAI Influence Level disclosure\n\nThis post: AIL-3.0 (substantial AI involvement, human steering on every load-bearing call). The data analysis, custom git-of-theseus extensions, commit-history trawling, calibration overrides, the merge-rate and incident charts, was AI-assisted. The July refresh, the May-June numbers and the autonomous-workflow analysis added above, was pulled with Claude Fable 5. The slide deck this post derives from was composed with AI assistance, and AI assistance was used to reformat the slide bullet points and speaker notes into essay form. The voice and tone polish was done in a separate Claude project tuned to my writing style, followed by a very extensive manual editing process where I further added or changed at least 20% of the words.\n\nStrategic decisions, data interpretation, and judgment calls about what to keep and what to cut are mine. AI helped me move faster on a deadline; it didn’t supply the substance. The talk and this post are themselves an example of the same 2x story they describe: weeks of human work, AI-assisted, not 10x. The substance wouldn’t exist without me, and the level of polish wouldn’t exist without AI.\n\nAIL framework: danielmiessler.com/blog/ai-influence-level-ail. Illustrations in the original talk: AIL-0, by bbghost.bsky.social. Art should be made by artists, not machines. Illustrations in the blog by our amazing design team.\n\nSources and context: Fin/Intercom 2x post; Fin/Intercom AI PR approval safety post; Honeycomb-Intercom case study; Emily Nakashima on AI-amplified engineering leadership. This post is adapted from the talk of the same name, delivered at Sydney Tech Leaders and LDX3 London in 2026."])</script><script>self.__next_f.push([1,"56:T627f,"])</script><script>self.__next_f.push([1,"In this two-part blog series, I give a detailed report-out on how our Honeycomb engineering team 2.5x-ed our throughput using AI without breaking everything or lowering our standards for quality. Part 1 explains how we did it and shows data about how that ramp-up happened. In this blog, I share what we learned.\n\nThe “platform engineering” frame and the “autonomy, ownership, feedback loops” frame are the same frame, spoken in two different vocabularies. AI amplifies your existing practices. It can make a dysfunctional org more dysfunctional, or it can bring out the best in an org that has high autonomy, ownership, and feedback loops.\n\nAutonomy is the ability to ship without asking permission. Continuous delivery, hermetic builds, feature flagging, fast CI: this is the substrate that lets work flow. Skip it, and your build queue saturates the moment AI shortens the writing loop.\n\nOwnership is accountability for what gets shipped, even when AI wrote it. CLAUDE.md and skills, code review, blameless incident analysis, the post-incident substrate updates that close the loop on whatever slipped through: these are how teams stay accountable to the system as a whole, regardless of the skill of whoever’s driving the tool. Skip these, and “the AI did it” becomes the default explanation for every production bug.\n\nFeedback loops are how you learn whether the work actually landed. MCP-mediated dev-loop access, closed-loop production observability, SLOs, and a dissemination layer that surfaces what shipped to the humans who need to know: these are how the agent and the human both find out whether what they did worked. Without them, AI just gives you faster shipping of code whose effects nobody’s measuring.\n\nBefore any of this can help you, your underlying org has to be functional in the first place. Nothing Honeycomb, or Intercom, or anyone else on a stage tells you about AI will land if your starting substrate is unhealthy. That’s the most important sentence in this post.\n\nContinuous delivery: Bound the duration of any individual bad PR\n\nWe run an hourly deploy train. Twelve to fourteen deployment events on a typical workday, packing about 70 PRs across them, with one to three reverts. Recovery is within the hour, because the next train is right behind. This bounds the duration of any individual bad PR’s impact in production. It doesn’t bound the radius; when something deploys, everyone gets it. But the duration of “everyone gets it” is short enough that we can absorb the cost.\n\nWithout this, none of the rest works. The agent feedback loop—i.e., Did this code do the thing in production?—doesn’t close. A merged PR that ships in six weeks effectively doesn’t exist as far as the agent is concerned.\n\nFeature flags are a complementary lever. Train architecture bounds incident duration; feature flags bound blast radius at the level of the individual change, since one flagged change can be turned off without rolling back the whole train. Both reduce change failure rate when something does slip through. Feature flagging is an under-emphasized partner to CD, especially for AI-shipped work, now that the marginal cost of “let’s gate this behind a flag” has gone down.\n\nWhat’s coming next is what we’re calling actually-continuous delivery: batches shipped as fast as they can be safely verified, rather than on an hourly schedule. We’d wanted this for two to three years already; the increased PR rate made it a necessity rather than a desire, and AI made it cheaper to build in the first place, since writing the code for it got cheaper too. Each platform investment unlocks the next one.\n\nCLAUDE.md and skills: Code ownership reframed\n\nDORA-style code ownership was about authorship: who wrote the code, who’s on the hook to maintain it. With agents writing the majority of new lines, authorship is no longer load-bearing. What survives is accountability for what humans allow AI to ship, even when humans no longer wrote the code themselves.\n\nCLAUDE.md is “what we will ship and what we will not,” at codebase or team level. Skills are reusable, specialized capabilities the agent can pick up for specific tasks. Together, they make team standards legible to the substrate that’s actually writing the code.\n\nWhen something slips through that both the human driving the AI and the human reviewer missed, the miss becomes a substrate update. It goes back into CLAUDE.md, into a skill file, or into a review-agent rule. Accountability here isn’t “we’re on the hook.” It’s “we close the loop when we miss.”\n\nThe blameless-incident reframe isn’t “blame the typewriter” or “blame the typist.” It’s that we’re accountable for the system as a whole, regardless of the skill of whoever’s driving the tool. The integration matters more than any of the individual components.\n\nAuto PR review, with humans empowered to push back\n\nAuto-review agents catching style violations and obvious holes are useful, and they don’t substitute for senior engineers willing to say, “This is slop, this is waste, this is over-verbose, this is missing tests,” out loud and in writing. Humans empowered to push back, including pushing back vigorously, is the load-bearing practice here.\n\nTwo worked examples from the public record. In one PR, closed unmerged, I’d pushed an AI-driven optimization. Ian Wilkes escalated through three rounds of review, ending with: “You need to test code like this thoroughly. Given the opportunities for problems here I would be fine with the original, slower sorted set implementation.”\n\nThe auto-review bot also weighed in. It claimed a “high-severity race condition” in the relevant cache. Ian: “This is false. That cache only stores directory names. I think it’s super confused. Definitely don’t take Claude’s word for it.” The bot’s claim was specific, confident, and wrong; the cache it flagged stores directory names, and the race it described couldn’t physically happen against that data structure. Without Ian’s codebase context, that false signal would have driven defensive changes nobody needed.\n\nWhat did ship was a simpler version that took the general-purpose SortedSet library type from the earlier commit as a drop-in replacement for the Set in one specific hot path. The bsearch-by-prefix optimization from the original was deferred. It was roughly 80% of the gain at 10% of the complexity. Ian had speculatively asked for the AI optimization (because how hard could it be to make Claude spit out the code?), then had regrets once he was reviewing it, and we landed on a simpler approach together. The experimentation gave us value. Just not the value we originally thought we’d get. Just because you can do something with AI doesn’t mean you should.\n\nFinally, in a third PR that was ultimately merged after rework, the discipline was escalating attention. The first review was architecture-only; Ian wouldn’t engage with line-level detail until the structure was right. After the rework, he left 12 inline comments. The most pointed of them: “obvious AI slop.” On the third review pass: “OK, let’s try it.” Merged.\n\nA senior engineer’s detailed attention is allocated, not assumed by default; that’s the inverse of typical reviewer behavior. And the practice has to reproduce all the way down. Both Ian and I are senior in our orgs. Two distinguished and principal engineers arguing is the easy case. The hard case is junior engineers blocking principal engineers’ PRs on the merits. Hierarchy shouldn’t insulate me from review, and seniority isn’t what makes the practice work.\n\nMCP: Give the agent the tools the human had\n\nIn a single Claude Code session or Slack thread (pointing autobot at the issue), an engineer can file a Linear ticket, fix the issue, and submit a PR pointing back at the ticket. Intent capture happens automatically, because the ticket lives in the same conversation as the fix. The cost of capturing intent goes to near-zero. It doesn’t stop mattering; the audit trail and the design rationale still matter, and now they’re recorded by default rather than skipped because nobody had time.\n\nClosed-loop conversation needs two categories of MCP server, and most teams under-invest in the second one. Tooling-side servers (Honeycomb for production telemetry, Playwright for UI verification) give the agent runtime feedback. Documentation-and-ticket-side servers (Notion for design docs and RFCs, Linear for tickets, user stories, and acceptance criteria) give the agent the user story, design intent, and verification criteria the human originally had.\n\nAn agent without these tools is flying blind in a way a junior engineer wouldn’t be. A junior engineer would pull up the dashboard, click through the UI, read the doc, read the ticket. The principle generalizes well beyond engineering; revops connecting HubSpot, Salesforce, Gong, and Apollo via MCP for Claude is the same pattern, applied to a different function.\n\nFast and AI-legible CI\n\nTwo things have to be true for CI to function as part of an agent’s feedback loop. It has to be fast, and it has to be AI-legible.\n\nMainline CI builds per day (top) and build-duration heatmap (bottom), September 2025 through June 28, 2026. The late-March step change is the CI investment landing: builds-per-day roughly doubled while duration halved. Spliced from two CI systems, CircleCI through March 23 and Mint (RWX) after, both counting end-to-end mainline pipeline runs.\n\n\n\nFast comes first, because it’s the half most rooms underweight. AI shortens the writing loop, so the testing loop has to shorten with it. A 60-minute coding session against a 15-minute CI run is a fine ratio. A 5-minute AI-generated change against that same 15-minute CI run means the build queue dominates both wall-clock time and agent iteration speed. As AI raises the rate at which changes get authored, build time has to come down to keep the loop closed. Fast CI is no longer a nice-to-have. It’s now a precondition for AI throughput to be worth anything at all.\n\nAI-legible means the CLI is readable by agents, especially with skill files teaching them how to drive it. Agents run code analysis via the CLI, and fix their own build failures fast. We use RWX; the principle generalizes beyond the specific vendor. RWX hosts our Claude Code auto-review agents too. It isn’t itself an AI tool, and that’s rather the point: feedback infrastructure has to be AI-legible and fast, not necessarily AI-native. MCP servers are one way to get there; well-designed CLIs with skill files are another.\n\nThe flipside worth flagging: some CI vendors’ MCP wrappers add overhead that’s net-negative. Plain CLI is often just faster, so long as the agent can figure out how to drive it.\n\nClosed-loop observability for agent work\n\nThe trap to avoid is treating “agentic observability” as monitoring the agent itself. Tokens spent, sub-agent decisions, internal flow: these are interesting, and they’re not the point. The point is monitoring the consequences of what the agent shipped, in production, on real users.\n\nThree things matter here.\n\nInstrument the shipped code, not just the agent. Your production data should let you find what the agent shipped, later. Span attributes that link the running code back to the PR and the agent session that created it let you ask, “This PR shipped Tuesday; what’s it doing in production right now?” That’s the loop you actually need to close.\n\nProduction outcomes matter more than agent activity. Latency, error rate, cost, user behavior on agent-shipped features. Did it work? What happened to real users? An agent that took 47 seconds and made 12 sub-agent calls tells you nothing about whether the change improved or broke anything. Production telemetry tells you that.\n\nThen there’s the closed-loop pattern itself: production signal feeding back into the next change. Cost-per-interaction SLOs firing back into the agent’s context for the next iteration. Anomalies in BubbleUp auto-converting into review-agent rules, so the same shape of mistake can’t slip through twice.\n\nThe worked example, from our own customer base: the Honeycomb-Intercom case study. A cost-per-interaction SLO on Fin, an AI-built product, caught eager-request waste that finance would otherwise have found a quarter later. That’s observability of agent-shipped code catching a real issue, not observability of the agent’s internal flow.\n\nSpeed without closed-loop signals is enshittification. Speed with them is engineering.\n\nAI for slop cleanup, not just generation\n\nWhen you buy a table saw, you don’t keep doing your woodworking the way you did with a hand saw. You redesign the work around what the table saw does well: long straight cuts, repeated dimensions, less fatigue per cut. The hand saw still earns its keep on what it’s good at; you just stop reaching for it on the things the table saw handles better.\n\nAI is the same type of tool. The question isn’t whether to use it. It’s what shape your work takes once you have it. Migrations. Dead-code deletion. Dependency upgrades. Doc rewrites. Deletion is productivity.\n\nAI lets you do the side quests: things we ought to be doing, that deliver quick wins, but that historically cost too much of a context switch to fit into anyone’s week. Dependency merges are the canonical example. A human’s honest response to Dependabot is “rubber-stamp it” or “ignore it,” because the time to read every changelog isn’t there. An agent has the time. It can read the changelog, run the regression tests, check for deprecations.\n\nReclaiming work that humans were doing badly anyway is reallocation, not a surrender of autonomy.\n\nThe dissemination layer\n\nCode review does two jobs: it catches bugs, and it produces shared understanding among humans about what’s changing. Automate the first, and the second needs its own surface area, decoupled from approval gating.\n\nConcrete examples from our own production environment: an Argo bot that surfaces what’s deploying via Argo, scoped to the humans who care about it; a Deploy Train bot that gives visibility into the hourly train (who’s on it, what’s pending, what shipped); Terraform Hush, a TFC notifier built as an INSTALL.md-driven internal PaaS that tags humans on infrastructure changes; and a sister team’s hound-changelog watcher, surfacing upstream changes from our shared monorepo into a separate codebase that has to keep pace. All four of these were themselves built with AI. We used AI capacity to build the tooling that lets humans stay aware of what AI is shipping.\n\nThat’s “AI amplifies your existing practices” operating at the meta level: it amplifies your ability to build the practices you never had time to build before. The marginal cost of internal tooling has dropped far enough that small categories of dissemination tooling, which were never worth a full project, are now worth the afternoon it takes to build them.\n\nFeature flagging and SLOs\n\nFeature flagging sits at the intersection of autonomy and feedback loops. AI changes ride behind flags the same way risky human changes always have. The new angle is that agents can be given the ability to gate their own changes for gradual rollout; the flag itself becomes the feedback signal for whether the change is doing what it claimed.\n\nSLOs sit at the intersection of ownership and feedback loops. AI features need SLOs on cost-per-interaction and latency, not just availability. An SLO is an ownership statement, since you’re committing to a level, and a feedback mechanism, since you’re measuring compliance against it. It’s a constraint on autonomy bounded from outside, which is why it sits at this intersection rather than at the center of the framework.\n\nWhere the skeptics are right\n\nTwo real concessions belong here.\n\nThe first is that bank line-of-business (LOB) engineering won’t benefit as much from this new AI-driven 2x results world. You’re not going to radically realign Line of Business (LOB) engineering at a bank. Most of what makes this work at Honeycomb, or at Intercom, is downstream of cultural conditions that don’t exist at a typical five-thousand-person regulated enterprise. This shape of story is reproducible at companies like Honeycomb or Intercom. It is not reproducible at the average bank’s LOB engineering org. If your organization can’t make the structural changes we and Intercom both made, cross-team realignment, plugin marketplaces, internal PaaS substrate, blameless accountability, you won’t get the same shape of result. Regulation isn’t actually the barrier; willingness to change how you work is. Bank LOB engineering is just the clearest example of an org that structurally can’t or won’t make that change, and any org in that position hits the same wall, regulated or not. That’s the realistic shape of this story for most companies.\n\nThe second concession is on spot-fix versus systematic-fix tension; complexity has a cost. Tickets aren’t the failure mode anymore; we always file them, programmatically enforced. The real worry is that AI makes spot-fixes so cheap that you keep reaching for them when a systematic answer, a refactor, an abstraction, a root-cause fix, would actually be better. Cause-fix cost held steady; symptom-fix dropped to near-zero; the ratio shifted underneath us. And the write-cost of code dropping doesn’t drag the maintenance-cost down with it. New code still has to be read, debugged, paged on, and onboarded against.\n\nThe receipts in the performance optimization PRs cash both halves of that concession. Spot-versus-systematic: “I would be fine with the original, slower implementation.” Complexity-has-a-cost: “this is a lot of kludge for a pretty fringe optimization.” Both sides show up in the same PR comments. The judgment call stays human. The skeptics are right that this is harder than it looks.\n\nOrder of adoption\n\nThis is the question we get asked most: which platform practices to adopt, in which order.\n\nThere isn’t a strict ordering. CD and observability co-evolve, and you need both to close the agent feedback loop. Trying to do one without the other won’t unlock AI throughput on its own.\n\nCD plus observability and SLOs form the paired foundation. Each one without the other is half a story. CD without observability is fast deploys you can’t debug. Observability without CD is a tight loop that takes weeks to act on. You can’t safely add AI throughput on top of either alone.\n\nCode ownership plus CLAUDE.md and skills come next. Without these, AI amplifies confusion as agent-emitted volume grows.\n\nHermetic, speedy builds plus feature flags scale with you. Reproducibility for verification, gradual rollout for safety. Both matter more under AI throughput than they did before it.\n\nChaos engineering is audit, not foundation. Do it once the rest is solid. Trying chaos engineering before the foundation is in place is just unstructured outage.\n\nStructuring the platform team\n\nIn an AI-amplified world, the platform team’s job grew. Classic platform work still matters: CI/CD, infrastructure, internal tooling, eng-prod foundations. The new work is maintaining the agent substrate: CLAUDE.md cultivation, MCP servers, AI-legible CI, dissemination tooling, auto-review agent rules. That’s platform work, not eng-prod tools work, and it belongs to the same team.\n\nIntercom’s pattern is a dedicated team, team-2x, running a Claude Code plugin marketplace with 153 contributors (31% of their R\u0026D org) and 267 skills. The substrate is platform infrastructure that ships its own product, and modernizing the factory is now everyone’s job rather than something a platform team hands down to others. The platform team doesn’t just maintain the platform. In an AI-amplified world, it maintains the agent’s relationship to the platform.\n\nOur platform team is busy building autobots for coding and review, to ensure that we can best allocate human attention where it matters, and to abstract the humans away from needing to stare at a Claude Code window all day long. The higher-value work is to have real human conversations with your teammates and stakeholders, and break up the work into the right chunks. That is your competitive differentiation. Everyone has access to Claude Code and the models. It’s what you choose to do with them that matters.\n\nWhat’s left if you read nothing else\n\nAI amplifies your existing practices. Going fast without autonomy, ownership, and feedback loops is enshittification. Going fast with them is engineering finally working closer to the way DevOps promised it would back in 2014. Fix your org’s dysfunction first.\n\nCapacity is a choice. AI gives you new capacity; the highest-leverage thing you can do with it is reinvest in the platform substrate that lets you absorb more of it, not spend it on marginal features. Actually-continuous delivery, AI-legible CI, agent-accessible observability, the dissemination layer: each of those was itself built with the new capacity. The compounding is the point.\n\n“We didn’t obviously break anything” isn’t success on its own. It’s a necessary condition for the rest to matter, but it’s a low bar to clear. Real success looks like sustainable team load, real user outcomes from the shipping rate, complexity managed rather than accumulating off-dashboard, and cultural practices reproducing all the way down rather than concentrated at the top. No one is done. Including us.\n\nIf you came here looking for permission to skip the platform work and let agents carry the velocity on their own, that isn’t a thing that exists. The work is still the work. AI just changed which parts of it you can finally get to. And you can’t skip past observability and CI.\n\nWhat we’re watching\n\nThe bottoms-up process for “what we’re going to measure next” is still landing inside the org. One candidate I’d push for is the tie to slop reduction and the quality of delivered results, not just throughput; how much of the new capacity goes into reinvestment versus marginal features, and how that ratio moves over time. Sustained-use metrics for AI-built features. Rework rate over rolling six-month windows.\n\nOther questions we haven’t fully answered yet. April’s 75% AI-line floor turned out to be an inflection, not a high-water mark; June hit 82.6%, so we still haven’t found the ceiling. Whether the autonomous workflow’s 8.4% share of June merges keeps compounding the way human delegation did after February, or plateaus, and whether it turns into a lines-of-code story the way human-driven AI work already has, rather than staying a merge-count one. What happens to PR cycle time once auto-review runs at scale. Whether the platform substrate we’ve built is enough to safely scale auto-approval, and on what timeline, and whether that answer changes once part of the workload has no human in the commit loop at all. Whether we can keep incident severity trending down even as incident count keeps climbing with change volume. Holding the count flat looks like a losing game at this point; the target that matters is how cheap each individual failure is to contain, not whether failures happen at all.\n\nWe’ll have more in another six months. For now, this is our report-out, and our answer to Intercom’s 2x posts. They got there. We got there too. And so can you.\n\nAI Influence Level disclosure\n\nThis post: AIL-3.0 (substantial AI involvement, human steering on every load-bearing call). The data analysis, custom git-of-theseus extensions, commit-history trawling, calibration overrides, the merge-rate and incident charts, was AI-assisted. The July refresh, the May-June numbers and the autonomous-workflow analysis added above, was pulled with Claude Fable 5. The slide deck this post derives from was composed with AI assistance, and AI assistance was used to reformat the slide bullet points and speaker notes into essay form. The voice and tone polish was done in a separate Claude project tuned to my writing style, followed by a very extensive manual editing process where I further added or changed at least 20% of the words.\n\nStrategic decisions, data interpretation, and judgment calls about what to keep and what to cut are mine. AI helped me move faster on a deadline; it didn’t supply the substance. The talk and this post are themselves an example of the same 2x story they describe: weeks of human work, AI-assisted, not 10x. The substance wouldn’t exist without me, and the level of polish wouldn’t exist without AI.\n\nAIL framework: danielmiessler.com/blog/ai-influence-level-ail. Illustrations in the original talk: AIL-0, by bbghost.bsky.social. Art should be made by artists, not machines. Illustrations in the blog by our amazing design team.\n\nSources and context: Fin/Intercom 2x post; Fin/Intercom AI PR approval safety post; Honeycomb-Intercom case study; Emily Nakashima on AI-amplified engineering leadership. This post is adapted from the talk of the same name, delivered at Sydney Tech Leaders and LDX3 London in 2026."])</script><script>self.__next_f.push([1,"57:T627f,"])</script><script>self.__next_f.push([1,"In this two-part blog series, I give a detailed report-out on how our Honeycomb engineering team 2.5x-ed our throughput using AI without breaking everything or lowering our standards for quality. Part 1 explains how we did it and shows data about how that ramp-up happened. In this blog, I share what we learned.\n\nThe “platform engineering” frame and the “autonomy, ownership, feedback loops” frame are the same frame, spoken in two different vocabularies. AI amplifies your existing practices. It can make a dysfunctional org more dysfunctional, or it can bring out the best in an org that has high autonomy, ownership, and feedback loops.\n\nAutonomy is the ability to ship without asking permission. Continuous delivery, hermetic builds, feature flagging, fast CI: this is the substrate that lets work flow. Skip it, and your build queue saturates the moment AI shortens the writing loop.\n\nOwnership is accountability for what gets shipped, even when AI wrote it. CLAUDE.md and skills, code review, blameless incident analysis, the post-incident substrate updates that close the loop on whatever slipped through: these are how teams stay accountable to the system as a whole, regardless of the skill of whoever’s driving the tool. Skip these, and “the AI did it” becomes the default explanation for every production bug.\n\nFeedback loops are how you learn whether the work actually landed. MCP-mediated dev-loop access, closed-loop production observability, SLOs, and a dissemination layer that surfaces what shipped to the humans who need to know: these are how the agent and the human both find out whether what they did worked. Without them, AI just gives you faster shipping of code whose effects nobody’s measuring.\n\nBefore any of this can help you, your underlying org has to be functional in the first place. Nothing Honeycomb, or Intercom, or anyone else on a stage tells you about AI will land if your starting substrate is unhealthy. That’s the most important sentence in this post.\n\nContinuous delivery: Bound the duration of any individual bad PR\n\nWe run an hourly deploy train. Twelve to fourteen deployment events on a typical workday, packing about 70 PRs across them, with one to three reverts. Recovery is within the hour, because the next train is right behind. This bounds the duration of any individual bad PR’s impact in production. It doesn’t bound the radius; when something deploys, everyone gets it. But the duration of “everyone gets it” is short enough that we can absorb the cost.\n\nWithout this, none of the rest works. The agent feedback loop—i.e., Did this code do the thing in production?—doesn’t close. A merged PR that ships in six weeks effectively doesn’t exist as far as the agent is concerned.\n\nFeature flags are a complementary lever. Train architecture bounds incident duration; feature flags bound blast radius at the level of the individual change, since one flagged change can be turned off without rolling back the whole train. Both reduce change failure rate when something does slip through. Feature flagging is an under-emphasized partner to CD, especially for AI-shipped work, now that the marginal cost of “let’s gate this behind a flag” has gone down.\n\nWhat’s coming next is what we’re calling actually-continuous delivery: batches shipped as fast as they can be safely verified, rather than on an hourly schedule. We’d wanted this for two to three years already; the increased PR rate made it a necessity rather than a desire, and AI made it cheaper to build in the first place, since writing the code for it got cheaper too. Each platform investment unlocks the next one.\n\nCLAUDE.md and skills: Code ownership reframed\n\nDORA-style code ownership was about authorship: who wrote the code, who’s on the hook to maintain it. With agents writing the majority of new lines, authorship is no longer load-bearing. What survives is accountability for what humans allow AI to ship, even when humans no longer wrote the code themselves.\n\nCLAUDE.md is “what we will ship and what we will not,” at codebase or team level. Skills are reusable, specialized capabilities the agent can pick up for specific tasks. Together, they make team standards legible to the substrate that’s actually writing the code.\n\nWhen something slips through that both the human driving the AI and the human reviewer missed, the miss becomes a substrate update. It goes back into CLAUDE.md, into a skill file, or into a review-agent rule. Accountability here isn’t “we’re on the hook.” It’s “we close the loop when we miss.”\n\nThe blameless-incident reframe isn’t “blame the typewriter” or “blame the typist.” It’s that we’re accountable for the system as a whole, regardless of the skill of whoever’s driving the tool. The integration matters more than any of the individual components.\n\nAuto PR review, with humans empowered to push back\n\nAuto-review agents catching style violations and obvious holes are useful, and they don’t substitute for senior engineers willing to say, “This is slop, this is waste, this is over-verbose, this is missing tests,” out loud and in writing. Humans empowered to push back, including pushing back vigorously, is the load-bearing practice here.\n\nTwo worked examples from the public record. In one PR, closed unmerged, I’d pushed an AI-driven optimization. Ian Wilkes escalated through three rounds of review, ending with: “You need to test code like this thoroughly. Given the opportunities for problems here I would be fine with the original, slower sorted set implementation.”\n\nThe auto-review bot also weighed in. It claimed a “high-severity race condition” in the relevant cache. Ian: “This is false. That cache only stores directory names. I think it’s super confused. Definitely don’t take Claude’s word for it.” The bot’s claim was specific, confident, and wrong; the cache it flagged stores directory names, and the race it described couldn’t physically happen against that data structure. Without Ian’s codebase context, that false signal would have driven defensive changes nobody needed.\n\nWhat did ship was a simpler version that took the general-purpose SortedSet library type from the earlier commit as a drop-in replacement for the Set in one specific hot path. The bsearch-by-prefix optimization from the original was deferred. It was roughly 80% of the gain at 10% of the complexity. Ian had speculatively asked for the AI optimization (because how hard could it be to make Claude spit out the code?), then had regrets once he was reviewing it, and we landed on a simpler approach together. The experimentation gave us value. Just not the value we originally thought we’d get. Just because you can do something with AI doesn’t mean you should.\n\nFinally, in a third PR that was ultimately merged after rework, the discipline was escalating attention. The first review was architecture-only; Ian wouldn’t engage with line-level detail until the structure was right. After the rework, he left 12 inline comments. The most pointed of them: “obvious AI slop.” On the third review pass: “OK, let’s try it.” Merged.\n\nA senior engineer’s detailed attention is allocated, not assumed by default; that’s the inverse of typical reviewer behavior. And the practice has to reproduce all the way down. Both Ian and I are senior in our orgs. Two distinguished and principal engineers arguing is the easy case. The hard case is junior engineers blocking principal engineers’ PRs on the merits. Hierarchy shouldn’t insulate me from review, and seniority isn’t what makes the practice work.\n\nMCP: Give the agent the tools the human had\n\nIn a single Claude Code session or Slack thread (pointing autobot at the issue), an engineer can file a Linear ticket, fix the issue, and submit a PR pointing back at the ticket. Intent capture happens automatically, because the ticket lives in the same conversation as the fix. The cost of capturing intent goes to near-zero. It doesn’t stop mattering; the audit trail and the design rationale still matter, and now they’re recorded by default rather than skipped because nobody had time.\n\nClosed-loop conversation needs two categories of MCP server, and most teams under-invest in the second one. Tooling-side servers (Honeycomb for production telemetry, Playwright for UI verification) give the agent runtime feedback. Documentation-and-ticket-side servers (Notion for design docs and RFCs, Linear for tickets, user stories, and acceptance criteria) give the agent the user story, design intent, and verification criteria the human originally had.\n\nAn agent without these tools is flying blind in a way a junior engineer wouldn’t be. A junior engineer would pull up the dashboard, click through the UI, read the doc, read the ticket. The principle generalizes well beyond engineering; revops connecting HubSpot, Salesforce, Gong, and Apollo via MCP for Claude is the same pattern, applied to a different function.\n\nFast and AI-legible CI\n\nTwo things have to be true for CI to function as part of an agent’s feedback loop. It has to be fast, and it has to be AI-legible.\n\nMainline CI builds per day (top) and build-duration heatmap (bottom), September 2025 through June 28, 2026. The late-March step change is the CI investment landing: builds-per-day roughly doubled while duration halved. Spliced from two CI systems, CircleCI through March 23 and Mint (RWX) after, both counting end-to-end mainline pipeline runs.\n\n\n\nFast comes first, because it’s the half most rooms underweight. AI shortens the writing loop, so the testing loop has to shorten with it. A 60-minute coding session against a 15-minute CI run is a fine ratio. A 5-minute AI-generated change against that same 15-minute CI run means the build queue dominates both wall-clock time and agent iteration speed. As AI raises the rate at which changes get authored, build time has to come down to keep the loop closed. Fast CI is no longer a nice-to-have. It’s now a precondition for AI throughput to be worth anything at all.\n\nAI-legible means the CLI is readable by agents, especially with skill files teaching them how to drive it. Agents run code analysis via the CLI, and fix their own build failures fast. We use RWX; the principle generalizes beyond the specific vendor. RWX hosts our Claude Code auto-review agents too. It isn’t itself an AI tool, and that’s rather the point: feedback infrastructure has to be AI-legible and fast, not necessarily AI-native. MCP servers are one way to get there; well-designed CLIs with skill files are another.\n\nThe flipside worth flagging: some CI vendors’ MCP wrappers add overhead that’s net-negative. Plain CLI is often just faster, so long as the agent can figure out how to drive it.\n\nClosed-loop observability for agent work\n\nThe trap to avoid is treating “agentic observability” as monitoring the agent itself. Tokens spent, sub-agent decisions, internal flow: these are interesting, and they’re not the point. The point is monitoring the consequences of what the agent shipped, in production, on real users.\n\nThree things matter here.\n\nInstrument the shipped code, not just the agent. Your production data should let you find what the agent shipped, later. Span attributes that link the running code back to the PR and the agent session that created it let you ask, “This PR shipped Tuesday; what’s it doing in production right now?” That’s the loop you actually need to close.\n\nProduction outcomes matter more than agent activity. Latency, error rate, cost, user behavior on agent-shipped features. Did it work? What happened to real users? An agent that took 47 seconds and made 12 sub-agent calls tells you nothing about whether the change improved or broke anything. Production telemetry tells you that.\n\nThen there’s the closed-loop pattern itself: production signal feeding back into the next change. Cost-per-interaction SLOs firing back into the agent’s context for the next iteration. Anomalies in BubbleUp auto-converting into review-agent rules, so the same shape of mistake can’t slip through twice.\n\nThe worked example, from our own customer base: the Honeycomb-Intercom case study. A cost-per-interaction SLO on Fin, an AI-built product, caught eager-request waste that finance would otherwise have found a quarter later. That’s observability of agent-shipped code catching a real issue, not observability of the agent’s internal flow.\n\nSpeed without closed-loop signals is enshittification. Speed with them is engineering.\n\nAI for slop cleanup, not just generation\n\nWhen you buy a table saw, you don’t keep doing your woodworking the way you did with a hand saw. You redesign the work around what the table saw does well: long straight cuts, repeated dimensions, less fatigue per cut. The hand saw still earns its keep on what it’s good at; you just stop reaching for it on the things the table saw handles better.\n\nAI is the same type of tool. The question isn’t whether to use it. It’s what shape your work takes once you have it. Migrations. Dead-code deletion. Dependency upgrades. Doc rewrites. Deletion is productivity.\n\nAI lets you do the side quests: things we ought to be doing, that deliver quick wins, but that historically cost too much of a context switch to fit into anyone’s week. Dependency merges are the canonical example. A human’s honest response to Dependabot is “rubber-stamp it” or “ignore it,” because the time to read every changelog isn’t there. An agent has the time. It can read the changelog, run the regression tests, check for deprecations.\n\nReclaiming work that humans were doing badly anyway is reallocation, not a surrender of autonomy.\n\nThe dissemination layer\n\nCode review does two jobs: it catches bugs, and it produces shared understanding among humans about what’s changing. Automate the first, and the second needs its own surface area, decoupled from approval gating.\n\nConcrete examples from our own production environment: an Argo bot that surfaces what’s deploying via Argo, scoped to the humans who care about it; a Deploy Train bot that gives visibility into the hourly train (who’s on it, what’s pending, what shipped); Terraform Hush, a TFC notifier built as an INSTALL.md-driven internal PaaS that tags humans on infrastructure changes; and a sister team’s hound-changelog watcher, surfacing upstream changes from our shared monorepo into a separate codebase that has to keep pace. All four of these were themselves built with AI. We used AI capacity to build the tooling that lets humans stay aware of what AI is shipping.\n\nThat’s “AI amplifies your existing practices” operating at the meta level: it amplifies your ability to build the practices you never had time to build before. The marginal cost of internal tooling has dropped far enough that small categories of dissemination tooling, which were never worth a full project, are now worth the afternoon it takes to build them.\n\nFeature flagging and SLOs\n\nFeature flagging sits at the intersection of autonomy and feedback loops. AI changes ride behind flags the same way risky human changes always have. The new angle is that agents can be given the ability to gate their own changes for gradual rollout; the flag itself becomes the feedback signal for whether the change is doing what it claimed.\n\nSLOs sit at the intersection of ownership and feedback loops. AI features need SLOs on cost-per-interaction and latency, not just availability. An SLO is an ownership statement, since you’re committing to a level, and a feedback mechanism, since you’re measuring compliance against it. It’s a constraint on autonomy bounded from outside, which is why it sits at this intersection rather than at the center of the framework.\n\nWhere the skeptics are right\n\nTwo real concessions belong here.\n\nThe first is that bank line-of-business (LOB) engineering won’t benefit as much from this new AI-driven 2x results world. You’re not going to radically realign Line of Business (LOB) engineering at a bank. Most of what makes this work at Honeycomb, or at Intercom, is downstream of cultural conditions that don’t exist at a typical five-thousand-person regulated enterprise. This shape of story is reproducible at companies like Honeycomb or Intercom. It is not reproducible at the average bank’s LOB engineering org. If your organization can’t make the structural changes we and Intercom both made, cross-team realignment, plugin marketplaces, internal PaaS substrate, blameless accountability, you won’t get the same shape of result. Regulation isn’t actually the barrier; willingness to change how you work is. Bank LOB engineering is just the clearest example of an org that structurally can’t or won’t make that change, and any org in that position hits the same wall, regulated or not. That’s the realistic shape of this story for most companies.\n\nThe second concession is on spot-fix versus systematic-fix tension; complexity has a cost. Tickets aren’t the failure mode anymore; we always file them, programmatically enforced. The real worry is that AI makes spot-fixes so cheap that you keep reaching for them when a systematic answer, a refactor, an abstraction, a root-cause fix, would actually be better. Cause-fix cost held steady; symptom-fix dropped to near-zero; the ratio shifted underneath us. And the write-cost of code dropping doesn’t drag the maintenance-cost down with it. New code still has to be read, debugged, paged on, and onboarded against.\n\nThe receipts in the performance optimization PRs cash both halves of that concession. Spot-versus-systematic: “I would be fine with the original, slower implementation.” Complexity-has-a-cost: “this is a lot of kludge for a pretty fringe optimization.” Both sides show up in the same PR comments. The judgment call stays human. The skeptics are right that this is harder than it looks.\n\nOrder of adoption\n\nThis is the question we get asked most: which platform practices to adopt, in which order.\n\nThere isn’t a strict ordering. CD and observability co-evolve, and you need both to close the agent feedback loop. Trying to do one without the other won’t unlock AI throughput on its own.\n\nCD plus observability and SLOs form the paired foundation. Each one without the other is half a story. CD without observability is fast deploys you can’t debug. Observability without CD is a tight loop that takes weeks to act on. You can’t safely add AI throughput on top of either alone.\n\nCode ownership plus CLAUDE.md and skills come next. Without these, AI amplifies confusion as agent-emitted volume grows.\n\nHermetic, speedy builds plus feature flags scale with you. Reproducibility for verification, gradual rollout for safety. Both matter more under AI throughput than they did before it.\n\nChaos engineering is audit, not foundation. Do it once the rest is solid. Trying chaos engineering before the foundation is in place is just unstructured outage.\n\nStructuring the platform team\n\nIn an AI-amplified world, the platform team’s job grew. Classic platform work still matters: CI/CD, infrastructure, internal tooling, eng-prod foundations. The new work is maintaining the agent substrate: CLAUDE.md cultivation, MCP servers, AI-legible CI, dissemination tooling, auto-review agent rules. That’s platform work, not eng-prod tools work, and it belongs to the same team.\n\nIntercom’s pattern is a dedicated team, team-2x, running a Claude Code plugin marketplace with 153 contributors (31% of their R\u0026D org) and 267 skills. The substrate is platform infrastructure that ships its own product, and modernizing the factory is now everyone’s job rather than something a platform team hands down to others. The platform team doesn’t just maintain the platform. In an AI-amplified world, it maintains the agent’s relationship to the platform.\n\nOur platform team is busy building autobots for coding and review, to ensure that we can best allocate human attention where it matters, and to abstract the humans away from needing to stare at a Claude Code window all day long. The higher-value work is to have real human conversations with your teammates and stakeholders, and break up the work into the right chunks. That is your competitive differentiation. Everyone has access to Claude Code and the models. It’s what you choose to do with them that matters.\n\nWhat’s left if you read nothing else\n\nAI amplifies your existing practices. Going fast without autonomy, ownership, and feedback loops is enshittification. Going fast with them is engineering finally working closer to the way DevOps promised it would back in 2014. Fix your org’s dysfunction first.\n\nCapacity is a choice. AI gives you new capacity; the highest-leverage thing you can do with it is reinvest in the platform substrate that lets you absorb more of it, not spend it on marginal features. Actually-continuous delivery, AI-legible CI, agent-accessible observability, the dissemination layer: each of those was itself built with the new capacity. The compounding is the point.\n\n“We didn’t obviously break anything” isn’t success on its own. It’s a necessary condition for the rest to matter, but it’s a low bar to clear. Real success looks like sustainable team load, real user outcomes from the shipping rate, complexity managed rather than accumulating off-dashboard, and cultural practices reproducing all the way down rather than concentrated at the top. No one is done. Including us.\n\nIf you came here looking for permission to skip the platform work and let agents carry the velocity on their own, that isn’t a thing that exists. The work is still the work. AI just changed which parts of it you can finally get to. And you can’t skip past observability and CI.\n\nWhat we’re watching\n\nThe bottoms-up process for “what we’re going to measure next” is still landing inside the org. One candidate I’d push for is the tie to slop reduction and the quality of delivered results, not just throughput; how much of the new capacity goes into reinvestment versus marginal features, and how that ratio moves over time. Sustained-use metrics for AI-built features. Rework rate over rolling six-month windows.\n\nOther questions we haven’t fully answered yet. April’s 75% AI-line floor turned out to be an inflection, not a high-water mark; June hit 82.6%, so we still haven’t found the ceiling. Whether the autonomous workflow’s 8.4% share of June merges keeps compounding the way human delegation did after February, or plateaus, and whether it turns into a lines-of-code story the way human-driven AI work already has, rather than staying a merge-count one. What happens to PR cycle time once auto-review runs at scale. Whether the platform substrate we’ve built is enough to safely scale auto-approval, and on what timeline, and whether that answer changes once part of the workload has no human in the commit loop at all. Whether we can keep incident severity trending down even as incident count keeps climbing with change volume. Holding the count flat looks like a losing game at this point; the target that matters is how cheap each individual failure is to contain, not whether failures happen at all.\n\nWe’ll have more in another six months. For now, this is our report-out, and our answer to Intercom’s 2x posts. They got there. We got there too. And so can you.\n\nAI Influence Level disclosure\n\nThis post: AIL-3.0 (substantial AI involvement, human steering on every load-bearing call). The data analysis, custom git-of-theseus extensions, commit-history trawling, calibration overrides, the merge-rate and incident charts, was AI-assisted. The July refresh, the May-June numbers and the autonomous-workflow analysis added above, was pulled with Claude Fable 5. The slide deck this post derives from was composed with AI assistance, and AI assistance was used to reformat the slide bullet points and speaker notes into essay form. The voice and tone polish was done in a separate Claude project tuned to my writing style, followed by a very extensive manual editing process where I further added or changed at least 20% of the words.\n\nStrategic decisions, data interpretation, and judgment calls about what to keep and what to cut are mine. AI helped me move faster on a deadline; it didn’t supply the substance. The talk and this post are themselves an example of the same 2x story they describe: weeks of human work, AI-assisted, not 10x. The substance wouldn’t exist without me, and the level of polish wouldn’t exist without AI.\n\nAIL framework: danielmiessler.com/blog/ai-influence-level-ail. Illustrations in the original talk: AIL-0, by bbghost.bsky.social. Art should be made by artists, not machines. Illustrations in the blog by our amazing design team.\n\nSources and context: Fin/Intercom 2x post; Fin/Intercom AI PR approval safety post; Honeycomb-Intercom case study; Emily Nakashima on AI-amplified engineering leadership. This post is adapted from the talk of the same name, delivered at Sydney Tech Leaders and LDX3 London in 2026."])</script><script>self.__next_f.push([1,"58:T58d4,"])</script><script>self.__next_f.push([1,"We recently wrapped up a large-scale, multi-month Kafka migration project. We used to run self-hosted Confluent Platform and ZooKeeper as clusters of AWS EC2 instances, and now all of our Kafka clusters run open-source Apache Kafka 4.1.1 running in KRaft mode and deployed to AWS EKS.\n\nThere are insights and lessons within the story of how we did this migration that are worth sharing. In this blog post, I highlight key themes that set this project up for success: why committing to learning from and building on past incidents and experiences matter in projects like this, why it’s important to design any kind of Kafka migration with rollback and safety top of mind, and how our sociotechnical processes support Kafka migration execution in ways that build teams’ confidence.\n\nA note to our customers: this post describes work related to a May 7, 2026, scheduled maintenance event on our US instance. We missed the mark on timely, proactive communication to you about that event, and we sincerely apologize for the negative impact it had on you. We have a separate post detailing our response to the customer impact of the event, including how we will improve our processes to ensure we provide additional mitigations and support to prevent similar communication issues in the future. Because the engineering work to prepare for and execute this migration was extensive, we’ve chosen to address the external and internal aspects of this event in separate posts; the omission of the external perspective from this post is not intended to minimize the customer-facing impact.\n\nKafka’s purpose at Honeycomb\n\nAt Honeycomb, Kafka is the beating heart of our observability data ingestion pipeline. It sits between customer observability data arriving at our edge and services like Retriever writing that data to our columnar store, ready for customers to query in Honeycomb. Kafka has been a great fit for our needs because we have to move and process millions of observability events per second through our systems, and Kafka’s capabilities and guarantees afford us numerous critical benefits:\n\nLets us decouple data ingestion from data processing in a way that allows us to update our core ingestion path services several times a day without causing downtime for our customers\n\nProvides strong data buffering, reliability, and durability guarantees to ensure customer data isn’t lost when we accept it\n\nAllows us to flexibly scale in order to meet growing ingest demand\n\nGives multiple consuming services the ability to read the same data stream independently, so all of our services can be in agreement about the data we’re receiving\n\nWhy we migrated\n\nPrioritizing a large-scale Kafka migration requires substantial cross-team and cross-functional alignment. Asking for resources across multiple teams for a project that we knew would take several quarters to execute is not a thing that can be wished for and hoped into existence. We had to be very clear about the problems we were solving and why this project aligned with business objectives. So what were our reasons?\n\nFirst, there were technical capabilities we had to be able to prove as engineering developed Honeycomb Private Cloud. Installations of Honeycomb Private Cloud require Kafka to be running on AWS EKS as part of its packaged deliverable. The way we had been running Kafka in our SaaS infrastructure would simply not have worked for Honeycomb Private Cloud installations. For long-term maintainability and sustainability of operating Kafka, we had to be able to run Kafka the same way and prove that running Kafka on Kubernetes would be able to handle production scales of traffic. Additionally, it has become increasingly more viable to deploy and run Kafka on Kubernetes in production-scale environments (we use Strimzi for the orchestration and management layer).\n\nSecond, migrating Kafka presented an opportunity to better align our current internal operational patterns and, in turn, sunset older legacy patterns that our administration of Kafka depended on. Our Honeycomb services are built and deployed to Kubernetes, and we determined that we could use a lot of those same patterns for Kafka.\n\nFinally, migrating gave us a level of deep operational control and flexibility that we wanted. For example, we were finding that the time to recover from our weekly practice of replacing Kafka brokers was gradually getting worse. A couple of years ago, this took 8 to 12 hours in production, and before the migration started, this took 48 to 72 hours. The issue centered on Confluent Platform’s Tiered Storage functionality, a solution that we depended on, but also a closed-source one that gave us no means to fix issues directly without support from Confluent. Migrating to open-source Apache Kafka gave us more agency to fix issues like this if we ever encountered them.\n\nFunctional requirements will constrain migration options\n\nDeeply understanding the behavior of the services that depend on and interact with Kafka dictated our viable migration target options, as well as the means to execute the migration. One of the most impactful of these functional requirements came from Retriever, which consumes then writes the data coming out of Kafka into our columnar store. The way Retriever handles Kafka offset management precluded us from using common Kafka migration tooling options.\n\nRetriever ingestion workers don’t commit their partition offsets back to Kafka, but instead maintain their offsets internally. Why is that? Because Retriever has strict semantic delivery requirements (it’s effectively the exactly-once semantic) and strict data guarantees it has to uphold; Retriever cannot consume a message it has already serialized and written to the columnar store. Precise offset tracking and management is critically important to us.\n\nAdditionally, as described in Chapter 13 of Observability Engineering, Second Edition, Retriever uses parallel ingestion workers to consume a single Kafka partition: one consumer uploads finalized segments to the columnar store and the other consumer spot-checks that the resulting segment data produced is identical between the pair. We operate our system as not just exactly-once, but exactly-twice (across the pair). This design matters because Retriever checkpoints its Kafka partition offset to its local disk, and all ingestion workers will use these checkpoints when Retrievers need to be restarted due to a deployment or when a Retriever node instance is replaced. Retrievers can resume consuming from the checkpoint on the backup it restores from when it comes back online. In contrast, using a pair of consumer groups would result in divergent offsets being committed.\n\nThis dependence on internally managed and precise offset management meant that cross-cluster mirroring solutions like Kafka’s MirrorMaker 2 were not appropriate for our use case, because of its use of offset translation mechanisms. If we had used this to replicate messages between clusters, Retriever would not have been able to use its checkpoints to reliably retrieve the next messages from their respectively assigned partitions.\n\nIt’s important to pay close attention to your Kafka dependencies’ functional requirements, as they will constrain how you can execute your migrations.\n\nNon-functional requirements will constrain them too\n\nWe maintain a 99.99% ingest availability SLO and tune our systems to maintain very fast end-to-end ingest latencies. When you send an event into Honeycomb, we need to be available to accept it and you need to be able to query that event in Honeycomb within one minute. We are particularly sensitive to all sources of latencies throughout the ingestion path, including Kafka disk I/O latencies. \n\nThis means that we ruled out using some managed Kafka solutions that use diskless topics, like Confluent’s Warpstream, because we can’t trade higher latencies for more cost-effective data transfer and storage. We optimized our choices for the most performant, lowest latency storage solutions for fresh data. We determined that using an EKS instance’s NVMe instance store rather than high IOPS provisioned EBS volumes (like io2) guarantees the lowest possible read and write latencies. By choosing NVMe instance stores over EBS volumes, we accept another tradeoff: Broker replacement and data recovery will take longer when using NVMe instance stores because all of the buffered data has to be rematerialized from scratch. EBS volumes can be detached and reattached during replacement, speeding up this process, but incurring an ongoing cost in dollars and latency (there are no EBS savings plans).\n\nEvery implementation decision you make, like what storage approach to use for Kafka data, needs to be informed by your non-functional requirements. Any Kafka migration evaluation must factor all requirements, and they should constrain which options you can use. Making the right design choices early in the process will pay off when you need to design the safety mechanisms of migration execution.\n\nBuild on institutional knowledge and wisdom\n\nWhen I joined Honeycomb in January 2025, a wealth of history, knowledge, and wisdom were documented and left for me to leverage. I came with my own style and opinions on how we might achieve our goals, but it was vitally important to build on my predecessors’ wisdom. I prioritized understanding why we had designed Kafka the way we did to inform how I wanted to proceed. When I put together my proposal and evaluated the best options we had, I arrived at the same conclusions my predecessors did. This alignment gave me the confidence that I was thinking about the problem space and the potential solutions correctly.\n\nMaking the effort to find documented knowledge and history will help inform your decisions when you’re considering a Kafka migration of your own.\n\nApplying lessons from incidents pays dividends\n\nBefore we started our migration work, in December 2025, we had a major incident that affected one of our production Kafka clusters. This was a stressful incident for many of us, which required completely evacuating the Confluent Platform Kafka cluster that we were on. I paid close attention to the mechanics of the emergency evacuation, because if you look at it from the right perspective, evacuation kind of looks like steady-state migration, but under time pressure and duress.\n\nI was part of the incident response team for that incident, and I participated in the subsequent incident review and public report. We learned something new about our architecture through the incident that we had speculated might be true, but had never actually tried to do. Retriever could reset its checkpointed partition offsets to zero, and then be pointed at a new Kafka cluster. Retriever would then resume reading messages from the beginning of the partition on the new cluster. We could do this deterministically and dynamically via a feature flag, without dropping data or losing data continuity.\n\nWhy was this finding meaningful? The experience of the incident opened up a Kafka migration path that we thought we could not do, but because of the outcome of the incident, we learned this was actually a viable path for us to consider. We could execute a coordinated sequence of cutovers without dropping any customer data while maintaining full data continuity.\n\nThis pathway was made possible because of the lessons we learned from the incident. Learning from your past incidents is vital because if you are able to learn from them, you can build on those lessons in your migration designs and turn a stressful process into a more robust, safe, repeatable set of procedures.\n\nSeizing the opportunity to level everyone up\n\nRunning Kafka ourselves meant confronting all of the implications of vendor independence with Kafka. Deciding to do the migration meant we were accepting terms of operational responsibility. We had to make sure that the teams who would be interacting with and operating Kafka would have the right resources to do that. The knowledge and expertise had to be set up to scale; these things could not just live in my head.\n\nIt was just as important to execute the migrations as it was to create the bridges of scalable knowledge between the old and new ways of operating Kafka. It was an opportunity to build something internally with broad value: a pedagogical library resource within internal documentation that would teach Honeycomb bees about the fundamentals of Kafka, how Kafka fits into our architecture, and how to operate and interact with our new Kafka clusters. Committing to building out a reliable foundation of knowledge benefits everyone, whether they are brand new to Kafka or they are joining an on-call rotation that will be on the hook to operate Kafka. You don’t want to be left in a position where you’re scrambling to hire to fill a knowledge or expertise gap if you can help it.\n\nPrioritizing rollback procedures\n\nThe functional and non-functional requirements that constrained our options combined with the lessons of the Kafka incident in December directed us to make sure that our migrations’ safety guardrails and rollback scenarios were robust. We pushed some of our earlier migrations out to ensure we got the safety guardrails and rollback steps right. The stakes were too high, and we could not find ourselves caught flatfooted if we had to stop and reverse course during a botched production migration. If we had to make a decision to roll back because something went sideways, we were going to be prepared.\n\nWe run one Kafka cluster in each of our environments, consisting of three tiers of environments in two different regions: Kibble, the lowest environment; Dogfood, the next tier up; and finally the Prod clusters—six clusters in total. We exercised our rollback design in one of our Kibble environments. We migrated it fully forward, then fully backward, then partially forward and backward with our rollback procedures, then finally, fully forward a second time. When we explicitly migrated backwards to prepare for the rollback test, that procedure took over four hours.\n\nKafka migrations like these are big time and resource commitments, but dedicating time to the practice of migration execution was crucially important to us to ensure we got the processes nailed down as much as possible. This was another commitment we had made to learn directly from our migration experiences and use that as a feedback loop back into our migration processes.\n\nThe practice of execution reduces uncertainty and creates learning opportunities\n\nThe original template of our migration procedure came directly from the emergency evacuation runbook we created during the December Kafka incident, which laid out the multi-team choreography and process of the evacuation itself. We followed the procedure and recorded the experience of every migration we did in a multi-tab document. For each migration—whether Kibbles, Dogfoods, or Prod clusters—we had a corresponding “What did we learn?” tab in the document. Whenever we encountered something new or weird during the migration, we added a bullet point to that tab in real time. We reviewed what we learned a day or two after each migration, and we used those lessons to refine the template for the next migration. This refinement feedback loop allowed us to do some really crucial things that greatly reduced the process’s uncertainty and created strong learning opportunities for us as we executed each one.\n\nFirst, we defined very clear roles and responsibilities, and we optimized how our team coordinated execution. Running a migration resembled running an incident: We coordinated in real time on Zoom; we had a migration lead and a communication lead; and we assigned key runbook responsibilities to other people. But early migrations were also massive, multi-team efforts. The original migration required coordination across seven teams. Because we had multiple migrations to do, we didn’t want all seven teams to have to be present for every migration. So over time, our team practiced and gradually took ownership of running other teams’ runbooks for later migrations. Eventually, our team was the only team required to run the migration. We built our confidence by having each person on our team rotate what they did each time. All of us got firsthand experience running every critical piece of a complex and choreographed process.\n\nSecondly, it created opportunities to surface confusing or ambiguous things or invalid assumptions about the procedure. We gained valuable experience documenting these things, and we refined our processes well enough to take our migration executions from four to five hours down to executions of two to three hours.\n\nFinally, it allowed us to identify and define what telemetry we needed out of Kafka and Kubernetes to make sure we could explore how Kafka was behaving in real time. We created and deployed a telemetry pipeline consisting of OpenTelemetry Collectors deployed to the EKS clusters running Kafka, which scraped Prometheus JMX metrics, extracted information through the Kafka Admin API, and gathered Kubernetes node metrics and events. We sent all of that directly to Honeycomb. We built out tactical Honeycomb Boards that centered on key signals we needed to verify during the migration. We used these visualizations as checkpoints to continue or pause if something didn’t look right.\n\nAll of us gained confidence along the way, and none of us had to play hero when we had to troubleshoot things. We saw no clearer evidence of the growth of our team’s confidence and expertise when the team executed a full Kafka migration while I was on PTO.\n\nMy team saw their growth for themselves\n\nI took a few days off a week before we did the production migrations. We had one remaining non-production migration to do. I considered pushing my PTO back to be there for the migration just as I had for all of the others, but my manager pushed back against this temptation and made me remember 1) I should prioritize my own care and 2) having the team do the last non-production migration without me in the room was a perfect opportunity for the team to see for themselves how far they had come.\n\nBefore this project, I was the de facto “Kafka expert” on the team. Throughout the course of the project, I had seen my team grow in confidence, in knowledge, and in comfort by virtue of them being directly involved with each migration’s design and execution. I am still there and available to answer deep Kafka questions, but the rest of my team can meaningfully do this too.\n\nI arranged for the team to execute the last non-production migration while I was on PTO. I had every confidence they could do this migration without me there. Do you want to know how that migration went? They executed it flawlessly, with no emergent issues to troubleshoot whatsoever, and they set a record for the fastest turn-up. I was so immensely proud of the team for achieving that. It gave us the confidence that we were going to succeed when we executed the production migrations.\n\nThe full impact of generalizing migration procedures\n\nDesigning the migration processes for repeatability and generalizability were both important components of this migration. We now have the ability to use our migration procedure in the future for any number of migration modalities: self-hosted to managed, EKS-to-EKS cluster, evacuation and disaster recovery, etc. The overarching simplicity of the designs that make them generalizable come with some important tradeoffs worth weighing. We accept some reductions in consume availability for that conceptual simplicity, and that’s a deliberate choice because it is informed by what our services and systems tolerate.\n\nI said earlier that we uncovered a new migration pathway during the December Kafka incident. Refining that evacuation procedure made under duress took a lot of time and effort to guarantee data safety and continuity for future migrations. The shape of the process’s design was dictated by what our services and systems could tolerate, and in our case, that meant the tolerances of services dependent on offset preservation. By cutting over the producers first, letting the consumers finish reading from the old cluster, followed by cutting over the consumers and resetting their checkpointed offsets, we end up creating a window of downtime between the producer cutover and the consumer cutover. We haven’t interrupted produce requests or lost any of our customers’ data, but fresh data won’t be seen by the consumers during that window and, in turn, customers will see that gap.\n\nGuaranteeing data safety and continuity as well as accepting a window of downtime to achieve that has a material effect on what success looks like. A migration procedure that has been mechanically executed well does not guarantee a successful migration sociotechnically. As we mentioned at the beginning, how effective we are in communicating scope of impact and expectations to our colleagues and customers matters just as much as smooth mechanical execution. Succeeding in one does not guarantee success in other areas of impact.\n\nYour mixture of sociotechnical system tolerances combined with what tradeoffs you’re willing to accept will likely differ. Projects of this scale need to account for as many of these impacts as possible.\n\nYou can do difficult things\n\nLearning from your experiences, both historical and present, is essential to build on when you undertake a project of this magnitude. If Kafka is as vitally important to your architecture as it is ours, you have to build in rollback and safety, and you have to explicitly exercise those procedures to help your migration teams gain the required confidence when you have to adapt and respond to unforeseen situations.\n\nIf the Kafka knowledge of your organization lives in one or two people’s heads, Kafka migration projects are a great opportunity to start to build those foundations of learning that need to scale to others. Your teams need the agency and the confidence that wisdom, knowledge, and experience will give them. Find and build on those sources if you need to undertake something like this.\n\nSuccess is not guaranteed, and your circumstances and experiences will vary from ours. But one thing I can say is that we can still do difficult things, and you can too. Kafka can be intimidating to dig into because it often serves as the beating heart of critical data streams. But if you are thoughtful about your migration designs, and your team is eager to learn and participate, you can bring them along and show them that they can do this."])</script><script>self.__next_f.push([1,"59:T58d4,"])</script><script>self.__next_f.push([1,"We recently wrapped up a large-scale, multi-month Kafka migration project. We used to run self-hosted Confluent Platform and ZooKeeper as clusters of AWS EC2 instances, and now all of our Kafka clusters run open-source Apache Kafka 4.1.1 running in KRaft mode and deployed to AWS EKS.\n\nThere are insights and lessons within the story of how we did this migration that are worth sharing. In this blog post, I highlight key themes that set this project up for success: why committing to learning from and building on past incidents and experiences matter in projects like this, why it’s important to design any kind of Kafka migration with rollback and safety top of mind, and how our sociotechnical processes support Kafka migration execution in ways that build teams’ confidence.\n\nA note to our customers: this post describes work related to a May 7, 2026, scheduled maintenance event on our US instance. We missed the mark on timely, proactive communication to you about that event, and we sincerely apologize for the negative impact it had on you. We have a separate post detailing our response to the customer impact of the event, including how we will improve our processes to ensure we provide additional mitigations and support to prevent similar communication issues in the future. Because the engineering work to prepare for and execute this migration was extensive, we’ve chosen to address the external and internal aspects of this event in separate posts; the omission of the external perspective from this post is not intended to minimize the customer-facing impact.\n\nKafka’s purpose at Honeycomb\n\nAt Honeycomb, Kafka is the beating heart of our observability data ingestion pipeline. It sits between customer observability data arriving at our edge and services like Retriever writing that data to our columnar store, ready for customers to query in Honeycomb. Kafka has been a great fit for our needs because we have to move and process millions of observability events per second through our systems, and Kafka’s capabilities and guarantees afford us numerous critical benefits:\n\nLets us decouple data ingestion from data processing in a way that allows us to update our core ingestion path services several times a day without causing downtime for our customers\n\nProvides strong data buffering, reliability, and durability guarantees to ensure customer data isn’t lost when we accept it\n\nAllows us to flexibly scale in order to meet growing ingest demand\n\nGives multiple consuming services the ability to read the same data stream independently, so all of our services can be in agreement about the data we’re receiving\n\nWhy we migrated\n\nPrioritizing a large-scale Kafka migration requires substantial cross-team and cross-functional alignment. Asking for resources across multiple teams for a project that we knew would take several quarters to execute is not a thing that can be wished for and hoped into existence. We had to be very clear about the problems we were solving and why this project aligned with business objectives. So what were our reasons?\n\nFirst, there were technical capabilities we had to be able to prove as engineering developed Honeycomb Private Cloud. Installations of Honeycomb Private Cloud require Kafka to be running on AWS EKS as part of its packaged deliverable. The way we had been running Kafka in our SaaS infrastructure would simply not have worked for Honeycomb Private Cloud installations. For long-term maintainability and sustainability of operating Kafka, we had to be able to run Kafka the same way and prove that running Kafka on Kubernetes would be able to handle production scales of traffic. Additionally, it has become increasingly more viable to deploy and run Kafka on Kubernetes in production-scale environments (we use Strimzi for the orchestration and management layer).\n\nSecond, migrating Kafka presented an opportunity to better align our current internal operational patterns and, in turn, sunset older legacy patterns that our administration of Kafka depended on. Our Honeycomb services are built and deployed to Kubernetes, and we determined that we could use a lot of those same patterns for Kafka.\n\nFinally, migrating gave us a level of deep operational control and flexibility that we wanted. For example, we were finding that the time to recover from our weekly practice of replacing Kafka brokers was gradually getting worse. A couple of years ago, this took 8 to 12 hours in production, and before the migration started, this took 48 to 72 hours. The issue centered on Confluent Platform’s Tiered Storage functionality, a solution that we depended on, but also a closed-source one that gave us no means to fix issues directly without support from Confluent. Migrating to open-source Apache Kafka gave us more agency to fix issues like this if we ever encountered them.\n\nFunctional requirements will constrain migration options\n\nDeeply understanding the behavior of the services that depend on and interact with Kafka dictated our viable migration target options, as well as the means to execute the migration. One of the most impactful of these functional requirements came from Retriever, which consumes then writes the data coming out of Kafka into our columnar store. The way Retriever handles Kafka offset management precluded us from using common Kafka migration tooling options.\n\nRetriever ingestion workers don’t commit their partition offsets back to Kafka, but instead maintain their offsets internally. Why is that? Because Retriever has strict semantic delivery requirements (it’s effectively the exactly-once semantic) and strict data guarantees it has to uphold; Retriever cannot consume a message it has already serialized and written to the columnar store. Precise offset tracking and management is critically important to us.\n\nAdditionally, as described in Chapter 13 of Observability Engineering, Second Edition, Retriever uses parallel ingestion workers to consume a single Kafka partition: one consumer uploads finalized segments to the columnar store and the other consumer spot-checks that the resulting segment data produced is identical between the pair. We operate our system as not just exactly-once, but exactly-twice (across the pair). This design matters because Retriever checkpoints its Kafka partition offset to its local disk, and all ingestion workers will use these checkpoints when Retrievers need to be restarted due to a deployment or when a Retriever node instance is replaced. Retrievers can resume consuming from the checkpoint on the backup it restores from when it comes back online. In contrast, using a pair of consumer groups would result in divergent offsets being committed.\n\nThis dependence on internally managed and precise offset management meant that cross-cluster mirroring solutions like Kafka’s MirrorMaker 2 were not appropriate for our use case, because of its use of offset translation mechanisms. If we had used this to replicate messages between clusters, Retriever would not have been able to use its checkpoints to reliably retrieve the next messages from their respectively assigned partitions.\n\nIt’s important to pay close attention to your Kafka dependencies’ functional requirements, as they will constrain how you can execute your migrations.\n\nNon-functional requirements will constrain them too\n\nWe maintain a 99.99% ingest availability SLO and tune our systems to maintain very fast end-to-end ingest latencies. When you send an event into Honeycomb, we need to be available to accept it and you need to be able to query that event in Honeycomb within one minute. We are particularly sensitive to all sources of latencies throughout the ingestion path, including Kafka disk I/O latencies. \n\nThis means that we ruled out using some managed Kafka solutions that use diskless topics, like Confluent’s Warpstream, because we can’t trade higher latencies for more cost-effective data transfer and storage. We optimized our choices for the most performant, lowest latency storage solutions for fresh data. We determined that using an EKS instance’s NVMe instance store rather than high IOPS provisioned EBS volumes (like io2) guarantees the lowest possible read and write latencies. By choosing NVMe instance stores over EBS volumes, we accept another tradeoff: Broker replacement and data recovery will take longer when using NVMe instance stores because all of the buffered data has to be rematerialized from scratch. EBS volumes can be detached and reattached during replacement, speeding up this process, but incurring an ongoing cost in dollars and latency (there are no EBS savings plans).\n\nEvery implementation decision you make, like what storage approach to use for Kafka data, needs to be informed by your non-functional requirements. Any Kafka migration evaluation must factor all requirements, and they should constrain which options you can use. Making the right design choices early in the process will pay off when you need to design the safety mechanisms of migration execution.\n\nBuild on institutional knowledge and wisdom\n\nWhen I joined Honeycomb in January 2025, a wealth of history, knowledge, and wisdom were documented and left for me to leverage. I came with my own style and opinions on how we might achieve our goals, but it was vitally important to build on my predecessors’ wisdom. I prioritized understanding why we had designed Kafka the way we did to inform how I wanted to proceed. When I put together my proposal and evaluated the best options we had, I arrived at the same conclusions my predecessors did. This alignment gave me the confidence that I was thinking about the problem space and the potential solutions correctly.\n\nMaking the effort to find documented knowledge and history will help inform your decisions when you’re considering a Kafka migration of your own.\n\nApplying lessons from incidents pays dividends\n\nBefore we started our migration work, in December 2025, we had a major incident that affected one of our production Kafka clusters. This was a stressful incident for many of us, which required completely evacuating the Confluent Platform Kafka cluster that we were on. I paid close attention to the mechanics of the emergency evacuation, because if you look at it from the right perspective, evacuation kind of looks like steady-state migration, but under time pressure and duress.\n\nI was part of the incident response team for that incident, and I participated in the subsequent incident review and public report. We learned something new about our architecture through the incident that we had speculated might be true, but had never actually tried to do. Retriever could reset its checkpointed partition offsets to zero, and then be pointed at a new Kafka cluster. Retriever would then resume reading messages from the beginning of the partition on the new cluster. We could do this deterministically and dynamically via a feature flag, without dropping data or losing data continuity.\n\nWhy was this finding meaningful? The experience of the incident opened up a Kafka migration path that we thought we could not do, but because of the outcome of the incident, we learned this was actually a viable path for us to consider. We could execute a coordinated sequence of cutovers without dropping any customer data while maintaining full data continuity.\n\nThis pathway was made possible because of the lessons we learned from the incident. Learning from your past incidents is vital because if you are able to learn from them, you can build on those lessons in your migration designs and turn a stressful process into a more robust, safe, repeatable set of procedures.\n\nSeizing the opportunity to level everyone up\n\nRunning Kafka ourselves meant confronting all of the implications of vendor independence with Kafka. Deciding to do the migration meant we were accepting terms of operational responsibility. We had to make sure that the teams who would be interacting with and operating Kafka would have the right resources to do that. The knowledge and expertise had to be set up to scale; these things could not just live in my head.\n\nIt was just as important to execute the migrations as it was to create the bridges of scalable knowledge between the old and new ways of operating Kafka. It was an opportunity to build something internally with broad value: a pedagogical library resource within internal documentation that would teach Honeycomb bees about the fundamentals of Kafka, how Kafka fits into our architecture, and how to operate and interact with our new Kafka clusters. Committing to building out a reliable foundation of knowledge benefits everyone, whether they are brand new to Kafka or they are joining an on-call rotation that will be on the hook to operate Kafka. You don’t want to be left in a position where you’re scrambling to hire to fill a knowledge or expertise gap if you can help it.\n\nPrioritizing rollback procedures\n\nThe functional and non-functional requirements that constrained our options combined with the lessons of the Kafka incident in December directed us to make sure that our migrations’ safety guardrails and rollback scenarios were robust. We pushed some of our earlier migrations out to ensure we got the safety guardrails and rollback steps right. The stakes were too high, and we could not find ourselves caught flatfooted if we had to stop and reverse course during a botched production migration. If we had to make a decision to roll back because something went sideways, we were going to be prepared.\n\nWe run one Kafka cluster in each of our environments, consisting of three tiers of environments in two different regions: Kibble, the lowest environment; Dogfood, the next tier up; and finally the Prod clusters—six clusters in total. We exercised our rollback design in one of our Kibble environments. We migrated it fully forward, then fully backward, then partially forward and backward with our rollback procedures, then finally, fully forward a second time. When we explicitly migrated backwards to prepare for the rollback test, that procedure took over four hours.\n\nKafka migrations like these are big time and resource commitments, but dedicating time to the practice of migration execution was crucially important to us to ensure we got the processes nailed down as much as possible. This was another commitment we had made to learn directly from our migration experiences and use that as a feedback loop back into our migration processes.\n\nThe practice of execution reduces uncertainty and creates learning opportunities\n\nThe original template of our migration procedure came directly from the emergency evacuation runbook we created during the December Kafka incident, which laid out the multi-team choreography and process of the evacuation itself. We followed the procedure and recorded the experience of every migration we did in a multi-tab document. For each migration—whether Kibbles, Dogfoods, or Prod clusters—we had a corresponding “What did we learn?” tab in the document. Whenever we encountered something new or weird during the migration, we added a bullet point to that tab in real time. We reviewed what we learned a day or two after each migration, and we used those lessons to refine the template for the next migration. This refinement feedback loop allowed us to do some really crucial things that greatly reduced the process’s uncertainty and created strong learning opportunities for us as we executed each one.\n\nFirst, we defined very clear roles and responsibilities, and we optimized how our team coordinated execution. Running a migration resembled running an incident: We coordinated in real time on Zoom; we had a migration lead and a communication lead; and we assigned key runbook responsibilities to other people. But early migrations were also massive, multi-team efforts. The original migration required coordination across seven teams. Because we had multiple migrations to do, we didn’t want all seven teams to have to be present for every migration. So over time, our team practiced and gradually took ownership of running other teams’ runbooks for later migrations. Eventually, our team was the only team required to run the migration. We built our confidence by having each person on our team rotate what they did each time. All of us got firsthand experience running every critical piece of a complex and choreographed process.\n\nSecondly, it created opportunities to surface confusing or ambiguous things or invalid assumptions about the procedure. We gained valuable experience documenting these things, and we refined our processes well enough to take our migration executions from four to five hours down to executions of two to three hours.\n\nFinally, it allowed us to identify and define what telemetry we needed out of Kafka and Kubernetes to make sure we could explore how Kafka was behaving in real time. We created and deployed a telemetry pipeline consisting of OpenTelemetry Collectors deployed to the EKS clusters running Kafka, which scraped Prometheus JMX metrics, extracted information through the Kafka Admin API, and gathered Kubernetes node metrics and events. We sent all of that directly to Honeycomb. We built out tactical Honeycomb Boards that centered on key signals we needed to verify during the migration. We used these visualizations as checkpoints to continue or pause if something didn’t look right.\n\nAll of us gained confidence along the way, and none of us had to play hero when we had to troubleshoot things. We saw no clearer evidence of the growth of our team’s confidence and expertise when the team executed a full Kafka migration while I was on PTO.\n\nMy team saw their growth for themselves\n\nI took a few days off a week before we did the production migrations. We had one remaining non-production migration to do. I considered pushing my PTO back to be there for the migration just as I had for all of the others, but my manager pushed back against this temptation and made me remember 1) I should prioritize my own care and 2) having the team do the last non-production migration without me in the room was a perfect opportunity for the team to see for themselves how far they had come.\n\nBefore this project, I was the de facto “Kafka expert” on the team. Throughout the course of the project, I had seen my team grow in confidence, in knowledge, and in comfort by virtue of them being directly involved with each migration’s design and execution. I am still there and available to answer deep Kafka questions, but the rest of my team can meaningfully do this too.\n\nI arranged for the team to execute the last non-production migration while I was on PTO. I had every confidence they could do this migration without me there. Do you want to know how that migration went? They executed it flawlessly, with no emergent issues to troubleshoot whatsoever, and they set a record for the fastest turn-up. I was so immensely proud of the team for achieving that. It gave us the confidence that we were going to succeed when we executed the production migrations.\n\nThe full impact of generalizing migration procedures\n\nDesigning the migration processes for repeatability and generalizability were both important components of this migration. We now have the ability to use our migration procedure in the future for any number of migration modalities: self-hosted to managed, EKS-to-EKS cluster, evacuation and disaster recovery, etc. The overarching simplicity of the designs that make them generalizable come with some important tradeoffs worth weighing. We accept some reductions in consume availability for that conceptual simplicity, and that’s a deliberate choice because it is informed by what our services and systems tolerate.\n\nI said earlier that we uncovered a new migration pathway during the December Kafka incident. Refining that evacuation procedure made under duress took a lot of time and effort to guarantee data safety and continuity for future migrations. The shape of the process’s design was dictated by what our services and systems could tolerate, and in our case, that meant the tolerances of services dependent on offset preservation. By cutting over the producers first, letting the consumers finish reading from the old cluster, followed by cutting over the consumers and resetting their checkpointed offsets, we end up creating a window of downtime between the producer cutover and the consumer cutover. We haven’t interrupted produce requests or lost any of our customers’ data, but fresh data won’t be seen by the consumers during that window and, in turn, customers will see that gap.\n\nGuaranteeing data safety and continuity as well as accepting a window of downtime to achieve that has a material effect on what success looks like. A migration procedure that has been mechanically executed well does not guarantee a successful migration sociotechnically. As we mentioned at the beginning, how effective we are in communicating scope of impact and expectations to our colleagues and customers matters just as much as smooth mechanical execution. Succeeding in one does not guarantee success in other areas of impact.\n\nYour mixture of sociotechnical system tolerances combined with what tradeoffs you’re willing to accept will likely differ. Projects of this scale need to account for as many of these impacts as possible.\n\nYou can do difficult things\n\nLearning from your experiences, both historical and present, is essential to build on when you undertake a project of this magnitude. If Kafka is as vitally important to your architecture as it is ours, you have to build in rollback and safety, and you have to explicitly exercise those procedures to help your migration teams gain the required confidence when you have to adapt and respond to unforeseen situations.\n\nIf the Kafka knowledge of your organization lives in one or two people’s heads, Kafka migration projects are a great opportunity to start to build those foundations of learning that need to scale to others. Your teams need the agency and the confidence that wisdom, knowledge, and experience will give them. Find and build on those sources if you need to undertake something like this.\n\nSuccess is not guaranteed, and your circumstances and experiences will vary from ours. But one thing I can say is that we can still do difficult things, and you can too. Kafka can be intimidating to dig into because it often serves as the beating heart of critical data streams. But if you are thoughtful about your migration designs, and your team is eager to learn and participate, you can bring them along and show them that they can do this."])</script><script>self.__next_f.push([1,"5a:T1b9f,"])</script><script>self.__next_f.push([1,"The world is especially hard right now. The future of the software engineering profession looks more uncertain than ever. Execs are under heavy pressure to turn AI into magic results, and teams are fighting product competition and AI-induced burnout on one side, melting mental models and hellish oncall on the other side.\n\nObservability was supposed to be a solved problem by now. But we heard over and over and over from staff+ engineers, managers, and executives that it continues to be one of the biggest pain points:\n\n“We spent six months evaluating and choosing a tool, and got overruled behind our back.”\n\n“It takes 15 minutes to recover from an outage if the principal engineer is on call, and 45 minutes if he isn’t. Nothing we seem to buy or do or try seems to change this.”\n\n“I’m pretty sure the competitive research is all faked.”\n\nWe weren’t planning to write a whole book-within-a-book to speak to technical decision-makers from the top down, but that’s what happened. The first five parts of Observability Engineering are written for software engineers and the people who need to understand their code. The sixth is written for technical decision-makers.\n\nWe start with an open letter to CTOs, explaining why all their grand ambitions and goals with AI are blocked behind their organization’s’ ability to learn. Then we cover software delivery and observability from a systems perspective—no technical terminology, just systems thinking. We then talk about how to quantify the case for observability as a cost center or an investment, how to drive change in your organization, how to make good buy-vs-build decisions, how to partner with vendors, and how to approach instrumentation and security from a top-down perspective.\n\nThe chapters are loosely organized in order of hierarchy from the top down. We start with the CTO letter, then move down to things every principal engineer, director, and VP should have straight, then staff+ engineers and managers.\n\nThe first chapter of part 6 closes with this guest chapter from Darragh Curran, CTO and head of engineering of Fin, formerly Intercom.\n\nToo many engineering leaders right now seem to be acting like AI is magic, and engineering rigor is no longer needed. But AI is an amplifier: it amplifies whatever you already have, both good and bad. If there’s anyone who knows that for truth it’s Darragh, who was one of the very first engineering leaders to lead an org through a radical AI-first transformation—and come out the other side alive and better than ever.\n\nWe are honored and delighted to print his letter—in our book, and now here.\n\nA Letter from a CTO\n\nHow Intercom Engineering (Now Fin) Optimizes for Learning, by Darragh Curran\n\nThe thing that sparked Intercom into existence was an unignorable itch to make business online a little less awful. To put an end to: “Dear valued customer,” “you are ticket number 123,” “do not reply to this email.” Instead, to make business online personal and human. Like you’d expect in a store you love: a friendly welcome, personalised service, and real care if something goes wrong.\n\nTo do this, we made Intercom. It didn’t magically make your business better, but for people who cared, it gave them the right tools. And many did care. They realised good service was good for business.\n\nThese tools didn’t exist yet. The shape and surface area weren’t figured out. And figuring out the shape of a product—then evolving and refining it—benefits hugely from fast feedback loops:\n\nDo a thing. Learn something. Do the next thing.\n\nThat is the core function of a software team. Do it well, pair it with product vision and judgment, and you can build great products, fast.\n\nDoing a thing means putting software in customers’ hands. Until you ship, your software creates no value. If shipping is sluggish, risky, or error-prone, you’ll do it infrequently—and sluggishness infects your entire company and culture. If shipping is fast, reliable, and high-confidence, you’ll do it often. Frequent shipping means frequent learning, better decisions, and faster progress in the right direction.\n\nWe wrote this down 13 years ago as “Shipping is your company’s heartbeat.” It rings true now more than ever.\n\nAnd then came the AI wave.\n\nTimes of change force you to ask: what really matters? What do you keep? What do you change?\n\nFor us, the focus on enabling incredible customer service stayed constant. But we saw a clear line of sight to a future where AI could actually do the work of customer service—and do it faster and better than humans. That led to the birth of Fin, the best AI Agent for Customer Service. We pivoted our entire R\u0026D team to building it, and shifted our culture to be AI-first. Fin is now on a trajectory to be far more successful than our original product ever could have been.\n\nOnce again, we’re in uncharted product territory: a huge amount of software to build, uncertain shape, fast-evolving technology. But that plays to our strength—shipping and iterating at speed. And AI itself has given us new tools and agents to move faster than ever before.\n\nBut it’s also made me appreciate the most essential skill of software engineers, especially in an era where AI threatens to eat the job of writing code: the ability to understand what’s really going on in the messy, wonderful systems we create. Without fast understanding, you lose confidence and precision. You’re either guessing, or wasting endless time trying to figure things out.\n\nTo be a great engineer, you need to be great at:\n\nUnderstanding your customers – how they use your product, what’s working, what’s not.\n\nUnderstanding your production systems – why something is slow, why something’s broken, where to fix it.\n\nUnderstanding how your software is built and deployed – why it’s brittle or slow in places, and what it would take to improve it.\n\nEach of these gets harder in the AI era, which only increases the importance of this core skill:\n\nProducts are more complex. Instead of deterministic behavior, AI is probabilistic. It will surprise you. It won’t just work because it worked on your machine.\n\nProduction systems now depend on costly, slow, unreliable (but magical) LLMs.\n\nDevelopment environments are cohabited by AI agents prolific at producing “sort-of working” code. Your job is to harness the upside and contain the downside—while moving at speed.\n\nThe complexity ratchets up, but the truth becomes clearer: the bottleneck isn’t shipping (we’ve largely optimised that), and it isn’t even writing code (easier than ever). The bottleneck is understanding. Developing the depth and speed to know exactly what to do next to make your product or system better.\n\nIf shipping is your heartbeat, then understanding is your breathing. Thankfully, we can use AI tooling for faster and sharper understanding. The deeper and more effective your breathing, the more oxygen you pull in. In turn, that fuels sharper decisions, faster fixes, and better products.\n\n\n"])</script><script>self.__next_f.push([1,"5b:T1b9f,"])</script><script>self.__next_f.push([1,"The world is especially hard right now. The future of the software engineering profession looks more uncertain than ever. Execs are under heavy pressure to turn AI into magic results, and teams are fighting product competition and AI-induced burnout on one side, melting mental models and hellish oncall on the other side.\n\nObservability was supposed to be a solved problem by now. But we heard over and over and over from staff+ engineers, managers, and executives that it continues to be one of the biggest pain points:\n\n“We spent six months evaluating and choosing a tool, and got overruled behind our back.”\n\n“It takes 15 minutes to recover from an outage if the principal engineer is on call, and 45 minutes if he isn’t. Nothing we seem to buy or do or try seems to change this.”\n\n“I’m pretty sure the competitive research is all faked.”\n\nWe weren’t planning to write a whole book-within-a-book to speak to technical decision-makers from the top down, but that’s what happened. The first five parts of Observability Engineering are written for software engineers and the people who need to understand their code. The sixth is written for technical decision-makers.\n\nWe start with an open letter to CTOs, explaining why all their grand ambitions and goals with AI are blocked behind their organization’s’ ability to learn. Then we cover software delivery and observability from a systems perspective—no technical terminology, just systems thinking. We then talk about how to quantify the case for observability as a cost center or an investment, how to drive change in your organization, how to make good buy-vs-build decisions, how to partner with vendors, and how to approach instrumentation and security from a top-down perspective.\n\nThe chapters are loosely organized in order of hierarchy from the top down. We start with the CTO letter, then move down to things every principal engineer, director, and VP should have straight, then staff+ engineers and managers.\n\nThe first chapter of part 6 closes with this guest chapter from Darragh Curran, CTO and head of engineering of Fin, formerly Intercom.\n\nToo many engineering leaders right now seem to be acting like AI is magic, and engineering rigor is no longer needed. But AI is an amplifier: it amplifies whatever you already have, both good and bad. If there’s anyone who knows that for truth it’s Darragh, who was one of the very first engineering leaders to lead an org through a radical AI-first transformation—and come out the other side alive and better than ever.\n\nWe are honored and delighted to print his letter—in our book, and now here.\n\nA Letter from a CTO\n\nHow Intercom Engineering (Now Fin) Optimizes for Learning, by Darragh Curran\n\nThe thing that sparked Intercom into existence was an unignorable itch to make business online a little less awful. To put an end to: “Dear valued customer,” “you are ticket number 123,” “do not reply to this email.” Instead, to make business online personal and human. Like you’d expect in a store you love: a friendly welcome, personalised service, and real care if something goes wrong.\n\nTo do this, we made Intercom. It didn’t magically make your business better, but for people who cared, it gave them the right tools. And many did care. They realised good service was good for business.\n\nThese tools didn’t exist yet. The shape and surface area weren’t figured out. And figuring out the shape of a product—then evolving and refining it—benefits hugely from fast feedback loops:\n\nDo a thing. Learn something. Do the next thing.\n\nThat is the core function of a software team. Do it well, pair it with product vision and judgment, and you can build great products, fast.\n\nDoing a thing means putting software in customers’ hands. Until you ship, your software creates no value. If shipping is sluggish, risky, or error-prone, you’ll do it infrequently—and sluggishness infects your entire company and culture. If shipping is fast, reliable, and high-confidence, you’ll do it often. Frequent shipping means frequent learning, better decisions, and faster progress in the right direction.\n\nWe wrote this down 13 years ago as “Shipping is your company’s heartbeat.” It rings true now more than ever.\n\nAnd then came the AI wave.\n\nTimes of change force you to ask: what really matters? What do you keep? What do you change?\n\nFor us, the focus on enabling incredible customer service stayed constant. But we saw a clear line of sight to a future where AI could actually do the work of customer service—and do it faster and better than humans. That led to the birth of Fin, the best AI Agent for Customer Service. We pivoted our entire R\u0026D team to building it, and shifted our culture to be AI-first. Fin is now on a trajectory to be far more successful than our original product ever could have been.\n\nOnce again, we’re in uncharted product territory: a huge amount of software to build, uncertain shape, fast-evolving technology. But that plays to our strength—shipping and iterating at speed. And AI itself has given us new tools and agents to move faster than ever before.\n\nBut it’s also made me appreciate the most essential skill of software engineers, especially in an era where AI threatens to eat the job of writing code: the ability to understand what’s really going on in the messy, wonderful systems we create. Without fast understanding, you lose confidence and precision. You’re either guessing, or wasting endless time trying to figure things out.\n\nTo be a great engineer, you need to be great at:\n\nUnderstanding your customers – how they use your product, what’s working, what’s not.\n\nUnderstanding your production systems – why something is slow, why something’s broken, where to fix it.\n\nUnderstanding how your software is built and deployed – why it’s brittle or slow in places, and what it would take to improve it.\n\nEach of these gets harder in the AI era, which only increases the importance of this core skill:\n\nProducts are more complex. Instead of deterministic behavior, AI is probabilistic. It will surprise you. It won’t just work because it worked on your machine.\n\nProduction systems now depend on costly, slow, unreliable (but magical) LLMs.\n\nDevelopment environments are cohabited by AI agents prolific at producing “sort-of working” code. Your job is to harness the upside and contain the downside—while moving at speed.\n\nThe complexity ratchets up, but the truth becomes clearer: the bottleneck isn’t shipping (we’ve largely optimised that), and it isn’t even writing code (easier than ever). The bottleneck is understanding. Developing the depth and speed to know exactly what to do next to make your product or system better.\n\nIf shipping is your heartbeat, then understanding is your breathing. Thankfully, we can use AI tooling for faster and sharper understanding. The deeper and more effective your breathing, the more oxygen you pull in. In turn, that fuels sharper decisions, faster fixes, and better products.\n\n\n"])</script><script>self.__next_f.push([1,"2e:[\"$\",\"div\",null,{\"className\":\"bg-hc-gray-50\",\"children\":[\"$\",\"$L33\",null,{\"filterGroups\":[{\"id\":\"topics\",\"label\":\"Topic\",\"items\":[{\"id\":\"Observability\",\"label\":\"Observability\"},{\"id\":\"Software Engineering\",\"label\":\"Software Engineering\"},{\"id\":\"OpenTelemetry\",\"label\":\"OpenTelemetry\"},{\"id\":\"AI \u0026 LLMs\",\"label\":\"AI \u0026 LLMs\"},{\"id\":\"Product Updates\",\"label\":\"Product Updates\"},{\"id\":\"Dogfooding\",\"label\":\"Dogfooding\"},{\"id\":\"News \u0026 Announcements\",\"label\":\"News \u0026 Announcements\"},{\"id\":\"Instrumentation\",\"label\":\"Instrumentation\"},{\"id\":\"Teams \u0026 Collaboration\",\"label\":\"Teams \u0026 Collaboration\"},{\"id\":\"Tracing\",\"label\":\"Tracing\"},{\"id\":\"Culture\",\"label\":\"Culture\"},{\"id\":\"Ask Miss O11y\",\"label\":\"Ask Miss O11y\"},{\"id\":\"Debugging\",\"label\":\"Debugging\"},{\"id\":\"Frontend\",\"label\":\"Frontend\"},{\"id\":\"In the News\",\"label\":\"In the News\"},{\"id\":\"Connectors \u0026 Integrations\",\"label\":\"Connectors \u0026 Integrations\"},{\"id\":\"Featured\",\"label\":\"Featured\"},{\"id\":\"Operations\",\"label\":\"Operations\"},{\"id\":\"Sampling\",\"label\":\"Sampling\"},{\"id\":\"Metrics\",\"label\":\"Metrics\"},{\"id\":\"Incident Response\",\"label\":\"Incident Response\"},{\"id\":\"Logging\",\"label\":\"Logging\"},{\"id\":\"Service Level Objectives\",\"label\":\"Service Level Objectives\"},{\"id\":\"Best Practices\",\"label\":\"Best Practices\"},{\"id\":\"Databases\",\"label\":\"Databases\"},{\"id\":\"Conferences \u0026 Meetups\",\"label\":\"Conferences \u0026 Meetups\"},{\"id\":\"Monitoring\",\"label\":\"Monitoring\"},{\"id\":\"Technical Deep Dives\",\"label\":\"Technical Deep Dives\"},{\"id\":\"Events\",\"label\":\"Events\"},{\"id\":\"Tutorials\",\"label\":\"Tutorials\"},{\"id\":\"Honeycomb Events\",\"label\":\"Honeycomb Events\"},{\"id\":\"Innovation Week\",\"label\":\"Innovation Week\"},{\"id\":\"HoneyBytes\",\"label\":\"HoneyBytes\"},{\"id\":\"Customer Stories\",\"label\":\"Customer Stories\"},{\"id\":\"Security\",\"label\":\"Security\"},{\"id\":\"Engineering Best Practices\",\"label\":\"Engineering Best Practices\"},{\"id\":\"Guests\",\"label\":\"Guests\"},{\"id\":\"Migrations\",\"label\":\"Migrations\"},{\"id\":\"O11yCon\",\"label\":\"O11yCon\"}]}],\"blogPosts\":[{\"body\":\"$34\",\"publishedAtUnix\":1788958800000,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Charity Majors\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Charity Majors\",\"asset\":{\"_ref\":\"image-6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092-png\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"charity\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"AI Norms \u0026 Values, Part 3 of 3: Things We Hold True\",\"asset\":{\"_ref\":\"image-ff1c82783367c2a69702c80f1248dc907313059e-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"AI Norms \u0026 Values, Part 3 of 3: Things We Hold True\",\"asset\":{\"_ref\":\"image-ff1c82783367c2a69702c80f1248dc907313059e-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-09-09T13:00:00.000Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-norms-values-part-3-things-we-hold-true\"},\"summary\":\"The final part of Honeycomb's AI Norms \u0026 Values series: the principles the company holds true about AI as a tool, ownership of work, and rising standards; how it actually uses AI day to day; usage patterns for respecting each other's time; and where it stands on AI's ethical externalities like energy use, IP, bias, and wages.\",\"title\":\"AI Norms \u0026 Values, Part 3 of 3: Things We Hold True\",\"topics\":[{\"_id\":\"topic-1269\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-llms\"},\"title\":\"AI \u0026 LLMs\"},{\"_id\":\"topic-227\",\"slug\":{\"_type\":\"slug\",\"current\":\"culture\"},\"title\":\"Culture\"}],\"updatedAt\":null,\"objectID\":\"3746ba22-5a61-4265-ac97-0682397499e9\",\"_highlightResult\":{\"body\":{\"value\":\"$35\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Charity Majors\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"AI Norms \u0026 Values, Part 3 of 3: Things We Hold True\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"AI \u0026 LLMs\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Culture\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$36\",\"publishedAtUnix\":1788872400000,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Nick Travaglini\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Nick Travaglini\",\"asset\":{\"_ref\":\"image-b5f38a9b0b7fbe587c1b0ff1a88b88ce22a30a58-180x200-jpg\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"nickt\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Illustration comparing an open box of data cards with three data visualization pillars.\",\"asset\":{\"_ref\":\"image-2f5169f0014bd57114e40e9c6b911bf986e9dd74-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Wide Events vs. Three Pillars: AI Observability Costs\",\"asset\":{\"_ref\":\"image-2f5169f0014bd57114e40e9c6b911bf986e9dd74-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-09-08T13:00:00.000Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"wide-events-vs-three-pillars-ai-observability-costs\"},\"summary\":\"AI agents make telemetry costs harder to predict. This post compares the three pillars against the wide event model, and explains why wide events keep AI observability costs predictable without sacrificing the context engineers need.\",\"title\":\"Wide Events vs. Three Pillars: AI Observability Costs\",\"topics\":[{\"_id\":\"topic-11\",\"slug\":{\"_type\":\"slug\",\"current\":\"observability\"},\"title\":\"Observability\"},{\"_id\":\"topic-1244\",\"slug\":{\"_type\":\"slug\",\"current\":\"llms\"},\"title\":\"AI \u0026 LLMs\"},{\"_id\":\"topic-1235\",\"slug\":{\"_type\":\"slug\",\"current\":\"engineering-best-practices\"},\"title\":\"Engineering Best Practices\"}],\"updatedAt\":null,\"objectID\":\"d5aae535-909b-4dd5-9302-74fd81edbbc2\",\"_highlightResult\":{\"body\":{\"value\":\"$37\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Nick Travaglini\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"Wide Events vs. Three Pillars: AI Observability Costs\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"Observability\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"AI \u0026 LLMs\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Engineering Best Practices\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$38\",\"publishedAtUnix\":1788786000000,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Ken Rimple\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Ken Rimple\",\"asset\":{\"_ref\":\"image-70ff19725bb74795b106cac1113ed276442bb3bc-1703x1714-png\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"kenr\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Relational Query Superpowers\",\"asset\":{\"_ref\":\"image-1007d98f384979ca99d321c46ed3e11f4c068f90-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Relational Query Superpowers\",\"asset\":{\"_ref\":\"image-1007d98f384979ca99d321c46ed3e11f4c068f90-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-09-07T13:00:00.000Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"relational-query-superpowers\"},\"summary\":\"See how Honeycomb's relational query keywords—root, parent, child, any, any2, any3, and none—let you pull attributes from anywhere in a single trace into one query, walked through with a real checkout-error investigation.\",\"title\":\"Relational Query Superpowers\",\"topics\":[{\"_id\":\"topic-51\",\"slug\":{\"_type\":\"slug\",\"current\":\"tracing-blog\"},\"title\":\"Tracing\"},{\"_id\":\"topic-176\",\"slug\":{\"_type\":\"slug\",\"current\":\"tutorials\"},\"title\":\"Tutorials\"},{\"_id\":\"topic-11\",\"slug\":{\"_type\":\"slug\",\"current\":\"observability\"},\"title\":\"Observability\"}],\"updatedAt\":null,\"objectID\":\"2824c0ac-96b9-4244-a48b-35c169a694bb\",\"_highlightResult\":{\"body\":{\"value\":\"$39\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Ken Rimple\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"Relational Query Superpowers\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"Tracing\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Tutorials\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Observability\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$3a\",\"publishedAtUnix\":1788354000000,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Charity Majors\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Charity Majors\",\"asset\":{\"_ref\":\"image-6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092-png\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"charity\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Split illustration of two head profiles wearing VR headsets: a blue side with an upward trend and checkmark, and a red side with a downward trend and X-mark.\",\"asset\":{\"_ref\":\"image-636c5f52ce744d20378443e4eb803189a1df02d4-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"A split illustration contrasting a blue head wearing a VR headset with rising graphs and a checkmark, against a red head with a VR headset with falling graphs and an X-mark.\",\"asset\":{\"_ref\":\"image-636c5f52ce744d20378443e4eb803189a1df02d4-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-09-02T13:00:00.000Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-norms-values-part-2-ai-honeycomb-engineering\"},\"summary\":\"Charity Majors shares a note from Emily Nakashima, SVP of Engineering, on why Honeycomb's engineering org is going all in on AI, the north star it's aiming for, and an honest FAQ about what that means day to day.\",\"title\":\"AI Norms \u0026 Values, Part 2 of 3: AI for Honeycomb Engineering\",\"topics\":[{\"_id\":\"topic-1269\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-llms\"},\"title\":\"AI \u0026 LLMs\"},{\"_id\":\"topic-227\",\"slug\":{\"_type\":\"slug\",\"current\":\"culture\"},\"title\":\"Culture\"}],\"updatedAt\":null,\"objectID\":\"3aaf9f40-029c-4588-9cdf-6bec9359050f\",\"_highlightResult\":{\"body\":{\"value\":\"$3b\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Charity Majors\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"AI Norms \u0026 Values, Part 2 of 3: AI for Honeycomb Engineering\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"AI \u0026 LLMs\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Culture\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$3c\",\"publishedAtUnix\":1788267600000,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Mike Goldsmith\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Mike Goldsmith\",\"asset\":{\"_ref\":\"image-657bd02b8f3d7988efd68dd3d742fadd95597c9c-180x200-png\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"mike\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Bringing the Most Advanced Sampling to the OpenTelemetry Collector\",\"asset\":{\"_ref\":\"image-6019821b62699e57a45c743922f26176f607a520-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Bringing the Most Advanced Sampling to the OpenTelemetry Collector\",\"asset\":{\"_ref\":\"image-6019821b62699e57a45c743922f26176f607a520-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-09-01T13:00:00.000Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"bringing-most-advanced-sampling-opentelemetry-collector\"},\"summary\":\"Honeycomb is donating its adaptive tail sampling processor, built on years of Refinery experience, to the OpenTelemetry Collector. See how adaptive sampling, trace fingerprinting, and sample rate attribution work, and how to try it today with the Honeycomb Collector Distribution.\",\"title\":\"Bringing the Most Advanced Sampling to the OpenTelemetry Collector\",\"topics\":[{\"_id\":\"topic-27\",\"slug\":{\"_type\":\"slug\",\"current\":\"sampling\"},\"title\":\"Sampling\"},{\"_id\":\"topic-11\",\"slug\":{\"_type\":\"slug\",\"current\":\"observability\"},\"title\":\"Observability\"},{\"_id\":\"topic-1074\",\"slug\":{\"_type\":\"slug\",\"current\":\"opentelemetry\"},\"title\":\"OpenTelemetry\"}],\"updatedAt\":null,\"objectID\":\"0e7350a7-1c0a-489b-93a3-952d4ad2416f\",\"_highlightResult\":{\"body\":{\"value\":\"$3d\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Mike Goldsmith\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"Bringing the Most Advanced Sampling to the OpenTelemetry Collector\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"Sampling\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Observability\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"OpenTelemetry\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$3e\",\"publishedAtUnix\":1788181200000,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Rox Williams\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Rox Williams\",\"asset\":{\"_ref\":\"image-fb0dadab9def700cd5661ade34b9557c7d1b18f8-180x200-jpg\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"rox-williams\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Leading With Observability: Fin's CTO on Building Great Engineering Organizations in the AI Era\",\"asset\":{\"_ref\":\"image-4fedda12c7801612e4511ec3998a7985fe954c94-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Leading With Observability: Fin's CTO on Building Great Engineering Organizations in the AI Era\",\"asset\":{\"_ref\":\"image-4fedda12c7801612e4511ec3998a7985fe954c94-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-08-31T13:00:00.000Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"fin-cto-building-great-engineering-organizations-ai-era\"},\"summary\":\"Fin (formerly Intercom) CTO Darragh Curran set a public goal to double engineering productivity—and nearly tripled it. In the first episode of Leading With Observability, he talks with Charity Majors about AI-driven PR review, hands-on leadership through the transition, and why observability is the trust mechanism that makes it all work.\",\"title\":\"Fin's CTO on Building Great Engineering Organizations in the AI Era\",\"topics\":[{\"_id\":\"topic-1244\",\"slug\":{\"_type\":\"slug\",\"current\":\"llms\"},\"title\":\"AI \u0026 LLMs\"},{\"_id\":\"topic-11\",\"slug\":{\"_type\":\"slug\",\"current\":\"observability\"},\"title\":\"Observability\"},{\"_id\":\"topic-22\",\"slug\":{\"_type\":\"slug\",\"current\":\"software-engineering\"},\"title\":\"Software Engineering\"}],\"updatedAt\":null,\"objectID\":\"fb1e1691-b9a0-4dd1-b561-1e83b4633e48\",\"_highlightResult\":{\"body\":{\"value\":\"$3f\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Rox Williams\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"Fin's CTO on Building Great Engineering Organizations in the AI Era\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"AI \u0026 LLMs\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Observability\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Software Engineering\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$40\",\"publishedAtUnix\":1787774460000,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Kale Bogdanovs\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Kale Bogdanovs\",\"asset\":{\"_ref\":\"image-a85aba826c3692ea82c1ae6e324da5262dcee117-225x300-jpg\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"kale-bogdanovs\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"7 Best Datadog Alternatives for AI and Agent Observability\",\"asset\":{\"_ref\":\"image-baf13252eea10b081f0ed9d22673d734a271226c-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"7 Best Datadog Alternatives for AI and Agent Observability\",\"asset\":{\"_ref\":\"image-baf13252eea10b081f0ed9d22673d734a271226c-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-08-26T20:01:00.000Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"datadog-alternatives\"},\"summary\":\"Comparing Datadog alternatives for AI and agent observability? See how Honeycomb, New Relic, Dynatrace, Grafana Cloud, Phoenix, Langfuse, and SigNoz stack up on cost, investigation, and OpenTelemetry support.\",\"title\":\"7 Best Datadog Alternatives for AI and Agent Observability\",\"topics\":[{\"_id\":\"topic-1269\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-llms\"},\"title\":\"AI \u0026 LLMs\"},{\"_id\":\"topic-11\",\"slug\":{\"_type\":\"slug\",\"current\":\"observability\"},\"title\":\"Observability\"}],\"updatedAt\":null,\"objectID\":\"af9704a3-048f-4e0d-83d3-ddbde24f4a6e\",\"_highlightResult\":{\"body\":{\"value\":\"$41\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Kale Bogdanovs\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"7 Best Datadog Alternatives for AI and Agent Observability\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"AI \u0026 LLMs\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Observability\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$42\",\"publishedAtUnix\":1787237439251,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Charity Majors\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Charity Majors\",\"asset\":{\"_ref\":\"image-6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092-png\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"charity\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"AI Norms \u0026 Values, Part 1 of 3: How We Do Business at Honeycomb\",\"asset\":{\"_ref\":\"image-d021ecaa62a5011dea08612b6041e4f81224b861-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"AI Norms \u0026 Values, Part 1 of 3: How We Do Business at Honeycomb\",\"asset\":{\"_ref\":\"image-d021ecaa62a5011dea08612b6041e4f81224b861-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-08-20T14:50:39.251Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-norms-values-part-1-how-we-do-business-at-honeycomb\"},\"summary\":\"It's been a year since Honeycomb issued its AI mandate. Charity reflects on what that produced, why AI isn't special (it just amplifies what's already there), and shares the first of three new documents on Honeycomb's AI norms and values: how we do business.\",\"title\":\"AI Norms \u0026 Values, Part 1 of 3: How We Do Business at Honeycomb\",\"topics\":[{\"_id\":\"topic-1269\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-llms\"},\"title\":\"AI \u0026 LLMs\"},{\"_id\":\"topic-227\",\"slug\":{\"_type\":\"slug\",\"current\":\"culture\"},\"title\":\"Culture\"}],\"updatedAt\":null,\"objectID\":\"ef77bd15-8764-4ada-8d06-96acb019cfe6\",\"_highlightResult\":{\"body\":{\"value\":\"$43\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Charity Majors\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"AI Norms \u0026 Values, Part 1 of 3: How We Do Business at Honeycomb\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"AI \u0026 LLMs\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Culture\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$44\",\"publishedAtUnix\":1786971600000,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Ileanell Perez\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Ileanell Perez\",\"asset\":{\"_ref\":\"image-52b736a649fa6442c12250b94d09c59f72fd19d0-180x200-jpg\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"ileanell-perez\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"How I Support Humans in the AI Era\",\"asset\":{\"_ref\":\"image-66d0e7dbe0ea8f5501f64a175eccbab8a3d35a85-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"How I Support Humans in the AI Era\",\"asset\":{\"_ref\":\"image-66d0e7dbe0ea8f5501f64a175eccbab8a3d35a85-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-08-17T13:00:00.000Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"how-i-support-humans-in-the-ai-era\"},\"summary\":\"A remote engineering manager on why she didn't write a new AI policy for her team. Instead, she created space: for connection, for collaboration, and for discussion.\",\"title\":\"How I Support Humans in the AI Era\",\"topics\":[{\"_id\":\"topic-1269\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-llms\"},\"title\":\"AI \u0026 LLMs\"},{\"_id\":\"topic-175\",\"slug\":{\"_type\":\"slug\",\"current\":\"teams-and-collaboration\"},\"title\":\"Teams \u0026 Collaboration\"},{\"_id\":\"topic-227\",\"slug\":{\"_type\":\"slug\",\"current\":\"culture\"},\"title\":\"Culture\"}],\"updatedAt\":null,\"objectID\":\"f551b216-9104-4774-b2b7-eaf8ba1192ea\",\"_highlightResult\":{\"body\":{\"value\":\"$45\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Ileanell Perez\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"How I Support Humans in the AI Era\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"AI \u0026 LLMs\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Teams \u0026 Collaboration\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Culture\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$46\",\"publishedAtUnix\":1786366800000,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Dan Juengst\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"advanced\":{\"highPriority\":false},\"alt\":\"Dan Juengst headshot\",\"asset\":{\"_ref\":\"image-9a49fe3f0c44d40c477e20e33ac76ea2608f2bdf-600x600-png\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"dan-juengst\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"AI Model Drift: How to Keep Models Reliable\",\"asset\":{\"_ref\":\"image-e40375dd42c11ee2ab56187a5b1de28bc85c6853-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"AI Model Drift: How to Keep Models Reliable\",\"asset\":{\"_ref\":\"image-e40375dd42c11ee2ab56187a5b1de28bc85c6853-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-08-10T13:00:00.000Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-model-drift\"},\"summary\":\"Learn what AI model drift is, why it happens, and how production teams detect changes in model quality, inputs, prompts, and behavior.\",\"title\":\"AI Model Drift: How to Keep Models Reliable\",\"topics\":[{\"_id\":\"topic-1269\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-llms\"},\"title\":\"AI \u0026 LLMs\"}],\"updatedAt\":null,\"objectID\":\"7e859728-2e6a-44e6-8ad3-962d8dedfddf\",\"_highlightResult\":{\"body\":{\"value\":\"$47\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Dan Juengst\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"AI Model Drift: How to Keep Models Reliable\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"AI \u0026 LLMs\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$48\",\"publishedAtUnix\":1785934800000,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Kale Bogdanovs\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Kale Bogdanovs\",\"asset\":{\"_ref\":\"image-a85aba826c3692ea82c1ae6e324da5262dcee117-225x300-jpg\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"kale-bogdanovs\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Introducing AI BubbleUp\",\"asset\":{\"_ref\":\"image-8afe3c1ed60b3bc3bee1aaabff66375cf142d095-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Introducing AI BubbleUp\",\"asset\":{\"_ref\":\"image-8afe3c1ed60b3bc3bee1aaabff66375cf142d095-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-08-05T13:00:00.000Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"introducing-ai-bubbleup\"},\"summary\":\"Every BubbleUp query now surfaces significant correlations based on relevance, not just statistical analysis. Available today to all Honeycomb customers who have enabled Honeycomb Intelligence.\",\"title\":\"Introducing AI BubbleUp\",\"topics\":[{\"_id\":\"topic-1269\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-llms\"},\"title\":\"AI \u0026 LLMs\"},{\"_id\":\"topic-57\",\"slug\":{\"_type\":\"slug\",\"current\":\"product-updates\"},\"title\":\"Product Updates\"}],\"updatedAt\":null,\"objectID\":\"de625d70-6a0b-4198-94eb-488121a02fdc\",\"_highlightResult\":{\"body\":{\"value\":\"$49\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Kale Bogdanovs\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"Introducing AI BubbleUp\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"AI \u0026 LLMs\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Product Updates\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$4a\",\"publishedAtUnix\":1785857396600,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Rox Williams\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Rox Williams\",\"asset\":{\"_ref\":\"image-fb0dadab9def700cd5661ade34b9557c7d1b18f8-180x200-jpg\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"rox-williams\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"AMA: More Answers From the Observability Engineering Authors\",\"asset\":{\"_ref\":\"image-2756994c4483897f91816d9364132b01ba4cc2d0-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"AMA: More Answers From the Observability Engineering Authors\",\"asset\":{\"_ref\":\"image-2756994c4483897f91816d9364132b01ba4cc2d0-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-08-04T15:29:56.600Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"ama-recap-observability-engineering-authors-more-answers\"},\"summary\":\"We couldn't get through every question during our live AMA with the authors of Observability Engineering, so Charity, Liz, George, and Austin stuck around to answer more on AI, telemetry, and what still needs a human in the loop.\",\"title\":\"AMA Recap: More Answers From the Observability Engineering Authors\",\"topics\":[{\"_id\":\"topic-1269\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-llms\"},\"title\":\"AI \u0026 LLMs\"},{\"_id\":\"topic-11\",\"slug\":{\"_type\":\"slug\",\"current\":\"observability\"},\"title\":\"Observability\"}],\"updatedAt\":null,\"objectID\":\"0e5d0291-c8f3-46e1-b038-6cded965a9de\",\"_highlightResult\":{\"body\":{\"value\":\"$4b\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Rox Williams\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"AMA Recap: More Answers From the Observability Engineering Authors\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"AI \u0026 LLMs\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Observability\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$4c\",\"publishedAtUnix\":1785762000000,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Douglas Soo\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Douglas Soo\",\"asset\":{\"_ref\":\"image-14f4a72c04d74eab745c26f731ece5189274e6b4-180x200-png\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"doug\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Spend More Time Talking to Humans\",\"asset\":{\"_ref\":\"image-cffd9ef004452eb3744bfec81c30220785fc6ea8-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Spend More Time Talking to Humans\",\"asset\":{\"_ref\":\"image-cffd9ef004452eb3744bfec81c30220785fc6ea8-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-08-03T13:00:00.000Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"spend-more-time-talking-to-humans\"},\"summary\":\"LLMs have reshaped the day-to-day work of software engineering, leaving senior engineers exhausted by context-switching and junior engineers unsure how to grow. The fix isn’t a better prompt — it’s spending more time talking to humans: reducing context churn, pairing across seniority levels, and communicating more across teams.\",\"title\":\"Spend More Time Talking to Humans\",\"topics\":[{\"_id\":\"topic-1269\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-llms\"},\"title\":\"AI \u0026 LLMs\"},{\"_id\":\"topic-175\",\"slug\":{\"_type\":\"slug\",\"current\":\"teams-and-collaboration\"},\"title\":\"Teams \u0026 Collaboration\"}],\"updatedAt\":null,\"objectID\":\"7b943e94-c2b4-444e-a24d-0b4f51a5038a\",\"_highlightResult\":{\"body\":{\"value\":\"$4d\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Douglas Soo\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"Spend More Time Talking to Humans\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"AI \u0026 LLMs\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Teams \u0026 Collaboration\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$4e\",\"publishedAtUnix\":1785330000000,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Shabih Syed\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Shabih Syed\",\"asset\":{\"_ref\":\"image-45de15053db3321b1c2e8fbb963688ab67a310b7-271x300-jpg\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"shabih-syed\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Honeycomb Named a Visionary in the 2026 Gartner® Magic Quadrant™ for Observability Platforms\",\"asset\":{\"_ref\":\"image-0dc73b52e47cba09bbbe9d43eee242edfaa03fe3-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Honeycomb Named a Visionary in the 2026 Gartner® Magic Quadrant™ for Observability Platforms\",\"asset\":{\"_ref\":\"image-0dc73b52e47cba09bbbe9d43eee242edfaa03fe3-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-07-29T13:00:00.000Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"honeycomb-named-visionary-2026-gartner-magic-quadrant-observability-platforms\"},\"summary\":\"For the third consecutive year, Honeycomb has been named a Visionary in the Gartner® Magic Quadrant™ for Observability Platforms. The recognition reflects Honeycomb's vision for fast, flexible, high-cardinality querying, agent-era observability with Agent Timeline and Canvas, and predictable event-based pricing at trillions of events.\",\"title\":\"Honeycomb Named a Visionary in the 2026 Gartner® Magic Quadrant™ for Observability Platforms\",\"topics\":[{\"_id\":\"topic-56\",\"slug\":{\"_type\":\"slug\",\"current\":\"news-and-announcements\"},\"title\":\"News \u0026 Announcements\"},{\"_id\":\"topic-11\",\"slug\":{\"_type\":\"slug\",\"current\":\"observability\"},\"title\":\"Observability\"},{\"_id\":\"topic-1269\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-llms\"},\"title\":\"AI \u0026 LLMs\"}],\"updatedAt\":null,\"objectID\":\"b337eff9-6a31-4d64-a9f6-cdc1f3347396\",\"_highlightResult\":{\"body\":{\"value\":\"$4f\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Shabih Syed\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"Honeycomb Named a Visionary in the 2026 Gartner® Magic Quadrant™ for Observability Platforms\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"News \u0026 Announcements\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Observability\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"AI \u0026 LLMs\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$50\",\"publishedAtUnix\":1784732400000,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Fred Hebert\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Fred Hebert\",\"asset\":{\"_ref\":\"image-7b06f417ac780bd2e4f02707bab2ec76cfd56665-180x200-png\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"fred-hebert\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"advanced\":{\"highPriority\":false},\"alt\":\"Embracing the Code Review Bottleneck\",\"asset\":{\"_ref\":\"image-f8e9e31a0ddf45434c3780b50ee6f69887015c98-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"advanced\":{\"highPriority\":false},\"alt\":\"Embracing the Code Review Bottleneck\",\"asset\":{\"_ref\":\"image-f8e9e31a0ddf45434c3780b50ee6f69887015c98-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-07-22T15:00:00.000Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"embracing-code-review-bottleneck\"},\"summary\":\"Faced with an endless stream of AI-generated code reviews, our team made the counterintuitive choice to lean into the bottleneck rather than reduce it. Surprisingly, velocity held up, knowledge sharing improved, and we developed a collective system ownership that stuck.\",\"title\":\"Embracing the Code Review Bottleneck\",\"topics\":[{\"_id\":\"topic-22\",\"slug\":{\"_type\":\"slug\",\"current\":\"software-engineering\"},\"title\":\"Software Engineering\"},{\"_id\":\"topic-1269\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-llms\"},\"title\":\"AI \u0026 LLMs\"}],\"updatedAt\":null,\"objectID\":\"42155581-49bc-4dc7-8cc8-2384627801c2\",\"_highlightResult\":{\"body\":{\"value\":\"$51\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Fred Hebert\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"Embracing the Code Review Bottleneck\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"Software Engineering\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"AI \u0026 LLMs\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$52\",\"publishedAtUnix\":1784559600000,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Austin Parker\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Austin Parker\",\"asset\":{\"_ref\":\"image-2a1050e83bac34eea79bd9f2d5bf7c3fc106550f-600x600-jpg\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"austin\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"advanced\":{\"highPriority\":false},\"alt\":\"What Comes After Observability?\",\"asset\":{\"_ref\":\"image-e074790a74ac795de3c41ddaceb84ff80f8393e3-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"advanced\":{\"highPriority\":false},\"alt\":\"What Comes After Observability?\",\"asset\":{\"_ref\":\"image-e074790a74ac795de3c41ddaceb84ff80f8393e3-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-07-20T15:00:00.000Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"what-comes-after-observability\"},\"summary\":\"A year ago, I predicted ways in which AI was about to fundamentally change observability as we knew it. Here's what we've seen happen since—both at Honeycomb and with our customers—and what we're building for the future.\",\"title\":\"What Comes After Observability?\",\"topics\":[{\"_id\":\"topic-11\",\"slug\":{\"_type\":\"slug\",\"current\":\"observability\"},\"title\":\"Observability\"},{\"_id\":\"topic-1269\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-llms\"},\"title\":\"AI \u0026 LLMs\"}],\"updatedAt\":null,\"objectID\":\"449a3b52-6570-4c05-9597-b7d94983b821\",\"_highlightResult\":{\"body\":{\"value\":\"$53\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Austin Parker\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"What Comes After Observability?\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"Observability\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"AI \u0026 LLMs\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$54\",\"publishedAtUnix\":1784214000000,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Liz Fong-Jones\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Liz Fong-Jones\",\"asset\":{\"_ref\":\"image-f6f77e2c3753d50fc961f3d1b48b28b3ba91008b-3146x3146-jpg\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"lizf\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"advanced\":{\"highPriority\":false},\"alt\":\"30 to 70 PRs a Day: How We Managed to Not Wreck Our Systems\",\"asset\":{\"_ref\":\"image-5e261bbd627f0eede01281d7766cc21a4245155b-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"advanced\":{\"highPriority\":false},\"alt\":\"30 to 70 PRs a Day: How We Managed to Not Wreck Our Systems\",\"asset\":{\"_ref\":\"image-5e261bbd627f0eede01281d7766cc21a4245155b-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-07-16T15:00:00.000Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"30-70-prs-day-how-we-managed-not-wreck-systems\"},\"summary\":\"The Honeycomb engineering team set out to double our productivity in a year. This is how we did it, what we did to keep things stable, what it cost us, and what we’re still figuring out.\",\"title\":\"30 to 70 PRs a Day: How We Managed to Not Wreck Our Systems\",\"topics\":[{\"_id\":\"topic-1269\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-llms\"},\"title\":\"AI \u0026 LLMs\"},{\"_id\":\"topic-22\",\"slug\":{\"_type\":\"slug\",\"current\":\"software-engineering\"},\"title\":\"Software Engineering\"}],\"updatedAt\":null,\"objectID\":\"9fa36f95-2f6b-4c3f-a7c1-126edf225c2c\",\"_highlightResult\":{\"body\":{\"value\":\"$55\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Liz Fong-Jones\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"30 to 70 PRs a Day: How We Managed to Not Wreck Our Systems\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"AI \u0026 LLMs\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Software Engineering\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$56\",\"publishedAtUnix\":1784214000000,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Liz Fong-Jones\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Liz Fong-Jones\",\"asset\":{\"_ref\":\"image-f6f77e2c3753d50fc961f3d1b48b28b3ba91008b-3146x3146-jpg\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"lizf\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"advanced\":{\"highPriority\":false},\"alt\":\"AI Amplifies Your Existing Practices: Lessons from Our Shift to an AI-First Strategy\",\"asset\":{\"_ref\":\"image-d79aa05cd396ba3f92b7f9b4df294c138b62f347-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"advanced\":{\"highPriority\":false},\"alt\":\"AI Amplifies Your Existing Practices: Lessons from Our Shift to an AI-First Strategy\",\"asset\":{\"_ref\":\"image-d79aa05cd396ba3f92b7f9b4df294c138b62f347-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-07-16T15:00:00.000Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-amplifies-existing-practices-lessons-ai-first-strategy\"},\"summary\":\"As the Honeycomb engineering team worked to double our productivity, we learned a lot. The most important takeaway? Nothing anyone tells you about AI will land if your starting substrate is unhealthy.\",\"title\":\"AI Amplifies Your Existing Practices: Lessons from Our Shift to an AI-First Strategy\",\"topics\":[{\"_id\":\"topic-1269\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-llms\"},\"title\":\"AI \u0026 LLMs\"},{\"_id\":\"topic-22\",\"slug\":{\"_type\":\"slug\",\"current\":\"software-engineering\"},\"title\":\"Software Engineering\"}],\"updatedAt\":null,\"objectID\":\"7cd370a0-26b2-4a56-9956-cca1ac9c1005\",\"_highlightResult\":{\"body\":{\"value\":\"$57\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Liz Fong-Jones\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"AI Amplifies Your Existing Practices: Lessons from Our Shift to an AI-First Strategy\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"AI \u0026 LLMs\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Software Engineering\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$58\",\"publishedAtUnix\":1784120400000,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Josh Parsons\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Josh Parsons\",\"asset\":{\"_ref\":\"image-1fc7eb47fcf3289e675d70eec7f1c82f15cd629c-180x200-jpg\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"josh-parsons\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"advanced\":{\"highPriority\":false},\"alt\":\"How we run Kafka at Honeycomb\",\"asset\":{\"_ref\":\"image-9a3a884b5eb123975dbb6815fd396be69cdee058-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"advanced\":{\"highPriority\":false},\"alt\":\"How we run Kafka at Honeycomb\",\"asset\":{\"_ref\":\"image-9a3a884b5eb123975dbb6815fd396be69cdee058-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-07-15T13:00:00.000Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"transforming-how-we-run-kafka-honeycomb\"},\"summary\":\"We just completed a large-scale, multi-month Kafka migration project. We couldn't have done it without learning from past mistakes, prioritizing rollback safety, and building shared knowledge across the team through repeated migration practice.\",\"title\":\"Transforming How We Run Kafka at Honeycomb\",\"topics\":[{\"_id\":\"topic-1237\",\"slug\":{\"_type\":\"slug\",\"current\":\"migrations\"},\"title\":\"Migrations\"},{\"_id\":\"topic-947\",\"slug\":{\"_type\":\"slug\",\"current\":\"best-practices\"},\"title\":\"Best Practices\"}],\"updatedAt\":null,\"objectID\":\"212acc4a-1091-4467-bddb-574245e38ae7\",\"_highlightResult\":{\"body\":{\"value\":\"$59\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Josh Parsons\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"Transforming How We Run Kafka at Honeycomb\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"Migrations\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Best Practices\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}},{\"body\":\"$5a\",\"publishedAtUnix\":1784041200000,\"_type\":\"blogArticle\",\"author\":{\"fullName\":\"Charity Majors\",\"profileImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"alt\":\"Charity Majors\",\"asset\":{\"_ref\":\"image-6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092-png\",\"_type\":\"reference\"}}},\"slug\":{\"_type\":\"slug\",\"current\":\"charity\"}},\"featuredImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"advanced\":{\"highPriority\":false},\"alt\":\"Shipping Is Your Company's Heartbeat: A Letter from a CTO\",\"asset\":{\"_ref\":\"image-3164e7a63d6badbcd48f49cd26a3fa1e5930c7df-3840x2160-png\",\"_type\":\"reference\"}}},\"mainImage\":{\"_type\":\"assetImage\",\"image\":{\"_type\":\"image\",\"advanced\":{\"highPriority\":false},\"alt\":\"Shipping Is Your Company's Heartbeat: A Letter from a CTO\",\"asset\":{\"_ref\":\"image-3164e7a63d6badbcd48f49cd26a3fa1e5930c7df-3840x2160-png\",\"_type\":\"reference\"}}},\"publishedAt\":\"2026-07-14T15:00:00.000Z\",\"slug\":{\"_type\":\"slug\",\"current\":\"shipping-is-your-companys-heartbeat-letter-from-cto\"},\"summary\":\"In an open letter to engineering leaders everywhere, Fin CTO Darragh Curran explains that AI isn't a magic wand but rather an amplifier—of the good and the bad—of your engineering practices. And engineering rigor is more important than ever.\",\"title\":\"Shipping Is Your Company's Heartbeat: A Letter from a CTO\",\"topics\":[{\"_id\":\"topic-1269\",\"slug\":{\"_type\":\"slug\",\"current\":\"ai-llms\"},\"title\":\"AI \u0026 LLMs\"},{\"_id\":\"topic-11\",\"slug\":{\"_type\":\"slug\",\"current\":\"observability\"},\"title\":\"Observability\"},{\"_id\":\"topic-22\",\"slug\":{\"_type\":\"slug\",\"current\":\"software-engineering\"},\"title\":\"Software Engineering\"}],\"updatedAt\":null,\"objectID\":\"78db78fd-cb76-4444-bc4a-450ef789c88d\",\"_highlightResult\":{\"body\":{\"value\":\"$5b\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"author\":{\"fullName\":{\"value\":\"Charity Majors\",\"matchLevel\":\"none\",\"matchedWords\":[]}},\"title\":{\"value\":\"Shipping Is Your Company's Heartbeat: A Letter from a CTO\",\"matchLevel\":\"none\",\"matchedWords\":[]},\"topics\":[{\"title\":{\"value\":\"AI \u0026 LLMs\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Observability\",\"matchLevel\":\"none\",\"matchedWords\":[]}},{\"title\":{\"value\":\"Software Engineering\",\"matchLevel\":\"none\",\"matchedWords\":[]}}]}}],\"pagination\":{\"currentPage\":1,\"totalPages\":32,\"totalItems\":626,\"pageSize\":20},\"activeTopic\":\"$undefined\",\"activeSearchTerm\":\"$undefined\",\"banner\":\"$L5c\"}]}]\n"])</script><script>self.__next_f.push([1,"32:[\"$\",\"div\",null,{\"className\":\"bg-hc-gray-50 flex w-full shrink-0 flex-col gap-5 rounded-[20px] p-6 lg:w-[375px]\",\"children\":[[\"$\",\"h2\",null,{\"className\":\"text-h6\",\"children\":\"Featured\"}],[\"$\",\"div\",null,{\"className\":\"divide-hc-gray-200 flex flex-col gap-5 divide-y\",\"children\":[[\"$\",\"div\",\"3aaf9f40-029c-4588-9cdf-6bec9359050f\",{\"className\":\"flex flex-col gap-2 pb-5\",\"children\":[[\"$\",\"div\",null,{\"className\":\"flex items-center gap-3\",\"children\":[[\"$\",\"span\",null,{\"className\":\"text-hc-slate/70 font-roboto text-xs/relaxed font-medium\",\"children\":[\"$\",\"span\",null,{\"children\":\"September 2, 2026\"}]}],[\"$\",\"span\",null,{\"className\":\"font-extralight opacity-30 block\",\"children\":\" | \"}],[\"$\",\"div\",null,{\"className\":\"flex items-center gap-[6px]\",\"children\":[[\"$\",\"$L31\",null,{\"src\":\"https://cdn.sanity.io/images/927dxq0h/production/6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png?w=80\u0026h=80\",\"width\":80,\"height\":80,\"alt\":\"Charity Majors\",\"className\":\"bg-hc-gray-50 size-6 rounded-full\"}],[\"$\",\"p\",null,{\"className\":\"text-hc-slate text-sm\",\"children\":[\"$\",\"$L24\",null,{\"href\":\"/author/charity\",\"className\":\"text-hc-cobalt underline hover:no-underline\",\"children\":\"Charity Majors\"}]}]]}]]}],[\"$\",\"$L24\",null,{\"href\":\"/blog/ai-norms-values-part-2-ai-honeycomb-engineering\",\"className\":\"font-roboto text-hc-slate line-clamp-2 text-base/snug font-medium\",\"children\":\"AI Norms \u0026 Values, Part 2 of 3: AI for Honeycomb Engineering\"}],[\"$\",\"div\",null,{\"className\":\"flex flex-wrap gap-3\",\"children\":[[\"$\",\"$L24\",\"AI \u0026 LLMs,AI \u0026 LLMs\",{\"href\":\"/blog/category/ai-llms\",\"children\":[\"$\",\"div\",null,{\"className\":\"font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate\",\"children\":\"AI \u0026 LLMs\"}]}],[\"$\",\"$L24\",\"Culture,Culture\",{\"href\":\"/blog/category/culture\",\"children\":[\"$\",\"div\",null,{\"className\":\"font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate\",\"children\":\"Culture\"}]}]]}]]}],[\"$\",\"div\",\"fb1e1691-b9a0-4dd1-b561-1e83b4633e48\",{\"className\":\"flex flex-col gap-2 pb-5\",\"children\":[[\"$\",\"div\",null,{\"className\":\"flex items-center gap-3\",\"children\":[[\"$\",\"span\",null,{\"className\":\"text-hc-slate/70 font-roboto text-xs/relaxed font-medium\",\"children\":[\"$\",\"span\",null,{\"children\":\"August 31, 2026\"}]}],[\"$\",\"span\",null,{\"className\":\"font-extralight opacity-30 block\",\"children\":\" | \"}],[\"$\",\"div\",null,{\"className\":\"flex items-center gap-[6px]\",\"children\":[[\"$\",\"$L31\",null,{\"src\":\"https://cdn.sanity.io/images/927dxq0h/production/fb0dadab9def700cd5661ade34b9557c7d1b18f8-180x200.jpg?rect=0,10,180,180\u0026w=80\u0026h=80\",\"width\":80,\"height\":80,\"alt\":\"Rox Williams\",\"className\":\"bg-hc-gray-50 size-6 rounded-full\"}],[\"$\",\"p\",null,{\"className\":\"text-hc-slate text-sm\",\"children\":[\"$\",\"$L24\",null,{\"href\":\"/author/rox-williams\",\"className\":\"text-hc-cobalt underline hover:no-underline\",\"children\":\"Rox Williams\"}]}]]}]]}],[\"$\",\"$L24\",null,{\"href\":\"/blog/fin-cto-building-great-engineering-organizations-ai-era\",\"className\":\"font-roboto text-hc-slate line-clamp-2 text-base/snug font-medium\",\"children\":\"Fin's CTO on Building Great Engineering Organizations in the AI Era\"}],[\"$\",\"div\",null,{\"className\":\"flex flex-wrap gap-3\",\"children\":[[\"$\",\"$L24\",\"AI \u0026 LLMs,AI \u0026 LLMs\",{\"href\":\"/blog/category/llms\",\"children\":[\"$\",\"div\",null,{\"className\":\"font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate\",\"children\":\"AI \u0026 LLMs\"}]}],[\"$\",\"$L24\",\"Observability,Observability\",{\"href\":\"/blog/category/observability\",\"children\":[\"$\",\"div\",null,{\"className\":\"font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate\",\"children\":\"Observability\"}]}],\"$L5d\"]}]]}],\"$L5e\",\"$L5f\"]}]]}]\n"])</script><script>self.__next_f.push([1,"5c:[\"$\",\"section\",null,{\"className\":\"col-span-full py-10\",\"children\":[\"$\",\"div\",null,{\"className\":\"newsletter-cta-banner bg-hc-slate relative flex flex-col gap-6 overflow-hidden rounded-2xl p-5 text-white md:flex-row md:items-center md:gap-10 md:p-7 lg:p-10 xl:items-end xl:gap-32\",\"children\":[[\"$\",\"div\",null,{\"className\":\"flex flex-col gap-1 md:max-w-[340px] xl:w-[585px] xl:max-w-none xl:py-6\",\"children\":[[\"$\",\"h3\",null,{\"className\":\"font-poppins tracking-heading text-xl leading-tight font-bold md:text-3xl md:tracking-tighter xl:text-4xl\",\"children\":\"Love our content?\"}],[\"$\",\"p\",null,{\"className\":\"font-poppins text-hc-sky-300 tracking-heading text-xl leading-tight font-bold md:text-3xl md:tracking-tighter xl:text-4xl\",\"children\":\"Get it delivered straight to your inbox.\"}]]}],[\"$\",\"div\",null,{\"className\":\"flex grow flex-col gap-2\",\"children\":[[\"$\",\"$L30\",null,{\"targetId\":\"blog-grid-newsletter-form\",\"className\":\"hubspot-form\"}],[\"$\",\"p\",null,{\"className\":\"text-hc-gray-200 text-xs leading-[150%]\",\"children\":[\"By subscribing to our newsletter, you agree to Honeycomb’s\",[\" \",[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/terms\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"4042940388e7\",\"_type\":\"link\",\"className\":\"text-hc-sky-300 underline hover:text-white\",\"children\":[\"Terms of Service\",\"$undefined\"]}]],\" and\",[\" \",[\"$\",\"$L24\",null,{\"ref\":\"$undefined\",\"href\":\"/privacy\",\"target\":\"_self\",\"rel\":\"$undefined\",\"onClick\":\"$undefined\",\"_key\":\"de1418f17f9f\",\"_type\":\"link\",\"className\":\"text-hc-sky-300 underline hover:text-white\",\"children\":[\"Privacy Notice\",\"$undefined\"]}]],\".\"]}]]}]]}]}]\n"])</script><script>self.__next_f.push([1,"5d:[\"$\",\"$L24\",\"Software Engineering,Software Engineering\",{\"href\":\"/blog/category/software-engineering\",\"children\":[\"$\",\"div\",null,{\"className\":\"font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate\",\"children\":\"Software Engineering\"}]}]\n"])</script><script>self.__next_f.push([1,"5e:[\"$\",\"div\",\"ef77bd15-8764-4ada-8d06-96acb019cfe6\",{\"className\":\"flex flex-col gap-2 pb-5\",\"children\":[[\"$\",\"div\",null,{\"className\":\"flex items-center gap-3\",\"children\":[[\"$\",\"span\",null,{\"className\":\"text-hc-slate/70 font-roboto text-xs/relaxed font-medium\",\"children\":[\"$\",\"span\",null,{\"children\":\"August 20, 2026\"}]}],[\"$\",\"span\",null,{\"className\":\"font-extralight opacity-30 block\",\"children\":\" | \"}],[\"$\",\"div\",null,{\"className\":\"flex items-center gap-[6px]\",\"children\":[[\"$\",\"$L31\",null,{\"src\":\"https://cdn.sanity.io/images/927dxq0h/production/6c9e651a4b8db4eed6db22230b68cf4bba1ce0dd-1092x1092.png?w=80\u0026h=80\",\"width\":80,\"height\":80,\"alt\":\"Charity Majors\",\"className\":\"bg-hc-gray-50 size-6 rounded-full\"}],[\"$\",\"p\",null,{\"className\":\"text-hc-slate text-sm\",\"children\":[\"$\",\"$L24\",null,{\"href\":\"/author/charity\",\"className\":\"text-hc-cobalt underline hover:no-underline\",\"children\":\"Charity Majors\"}]}]]}]]}],[\"$\",\"$L24\",null,{\"href\":\"/blog/ai-norms-values-part-1-how-we-do-business-at-honeycomb\",\"className\":\"font-roboto text-hc-slate line-clamp-2 text-base/snug font-medium\",\"children\":\"AI Norms \u0026 Values, Part 1 of 3: How We Do Business at Honeycomb\"}],[\"$\",\"div\",null,{\"className\":\"flex flex-wrap gap-3\",\"children\":[[\"$\",\"$L24\",\"AI \u0026 LLMs,AI \u0026 LLMs\",{\"href\":\"/blog/category/ai-llms\",\"children\":[\"$\",\"div\",null,{\"className\":\"font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate\",\"children\":\"AI \u0026 LLMs\"}]}],[\"$\",\"$L24\",\"Culture,Culture\",{\"href\":\"/blog/category/culture\",\"children\":[\"$\",\"div\",null,{\"className\":\"font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate\",\"children\":\"Culture\"}]}]]}]]}]\n"])</script><script>self.__next_f.push([1,"5f:[\"$\",\"div\",\"449a3b52-6570-4c05-9597-b7d94983b821\",{\"className\":\"flex flex-col gap-2 pb-5\",\"children\":[[\"$\",\"div\",null,{\"className\":\"flex items-center gap-3\",\"children\":[[\"$\",\"span\",null,{\"className\":\"text-hc-slate/70 font-roboto text-xs/relaxed font-medium\",\"children\":[\"$\",\"span\",null,{\"children\":\"July 20, 2026\"}]}],[\"$\",\"span\",null,{\"className\":\"font-extralight opacity-30 block\",\"children\":\" | \"}],[\"$\",\"div\",null,{\"className\":\"flex items-center gap-[6px]\",\"children\":[[\"$\",\"$L31\",null,{\"src\":\"https://cdn.sanity.io/images/927dxq0h/production/2a1050e83bac34eea79bd9f2d5bf7c3fc106550f-600x600.jpg?w=80\u0026h=80\",\"width\":80,\"height\":80,\"alt\":\"Austin Parker\",\"className\":\"bg-hc-gray-50 size-6 rounded-full\"}],[\"$\",\"p\",null,{\"className\":\"text-hc-slate text-sm\",\"children\":[\"$\",\"$L24\",null,{\"href\":\"/author/austin\",\"className\":\"text-hc-cobalt underline hover:no-underline\",\"children\":\"Austin Parker\"}]}]]}]]}],[\"$\",\"$L24\",null,{\"href\":\"/blog/what-comes-after-observability\",\"className\":\"font-roboto text-hc-slate line-clamp-2 text-base/snug font-medium\",\"children\":\"What Comes After Observability?\"}],[\"$\",\"div\",null,{\"className\":\"flex flex-wrap gap-3\",\"children\":[[\"$\",\"$L24\",\"Observability,Observability\",{\"href\":\"/blog/category/observability\",\"children\":[\"$\",\"div\",null,{\"className\":\"font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate\",\"children\":\"Observability\"}]}],[\"$\",\"$L24\",\"AI \u0026 LLMs,AI \u0026 LLMs\",{\"href\":\"/blog/category/ai-llms\",\"children\":[\"$\",\"div\",null,{\"className\":\"font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate\",\"children\":\"AI \u0026 LLMs\"}]}]]}]]}]\n"])</script><script>self.__next_f.push([1,"23:[\"$\",\"main\",null,{\"className\":\"\",\"children\":[false,\"$L60\"]}]\n"])</script><script>self.__next_f.push([1,"60:[\"$L61\",\"$L62\"]\n"])</script><script>self.__next_f.push([1,"63:I[519455,[\"/_next/static/chunks/14_mcc2-.c1ee.js\",\"/_next/static/chunks/019vi3l~x0zoc.js\",\"/_next/static/chunks/0ku~nn_l8-fol.js\",\"/_next/static/chunks/039u5_5hlemld.js\",\"/_next/static/chunks/189hrhe.fk4af.js\",\"/_next/static/chunks/0oz-qxk30w~qw.js\",\"/_next/static/chunks/0vx_phl8cla2s.js\",\"/_next/static/chunks/0xywjwd04osrr.js\",\"/_next/static/chunks/0t1~yeqvn891r.js\",\"/_next/static/chunks/0ks4m351.jbv2.js\",\"/_next/static/chunks/01gy5f4286e6a.js\",\"/_next/static/chunks/09mg9tc2w3ag6.js\",\"/_next/static/chunks/0~-xo~ilf3e0r.js\"],\"Button\"]\n"])</script><script>self.__next_f.push([1,"61:[\"$\",\"section\",\"ced8bdaf0197\",{\"id\":\"ced8bdaf0197\",\"data-anchor\":\"$undefined\",\"className\":\"bg-hc-gray-50\",\"style\":{\"backgroundColor\":\"var(--color-hc-gray-50)\"},\"children\":[\"$\",\"div\",null,{\"className\":\"relative mx-auto max-w-screen-xl overflow-hidden pt-8 md:pt-14 lg:h-[695px] lg:pt-0 xl:h-[795px]\",\"children\":[\"$\",\"div\",null,{\"className\":\"md:flex md:flex-col md:items-center lg:h-full lg:flex-1 lg:flex-row lg:justify-between\",\"children\":[[\"$\",\"div\",null,{\"className\":\"mx-6 mb-8 md:mx-12 md:mb-0 md:max-w-[681px] lg:max-w-[457px] lg:min-w-[457px] lg:pb-16 xl:mr-0 xl:max-w-[603px] xl:min-w-[552px] xl:pb-0\",\"children\":[\"$\",\"div\",null,{\"className\":\"z-20 flex flex-col gap-6 mb-0 w-full items-center justify-start space-y-6 text-center md:gap-6 md:space-y-0 lg:mb-0 lg:h-full lg:w-full lg:items-start lg:justify-center lg:gap-8 lg:text-left\",\"children\":[[\"$\",\"span\",null,{\"className\":\"font-roboto text-hc-slate text-sm font-medium tracking-[0.28px] xl:text-base\",\"children\":\"ERROR 404\"}],[\"$\",\"h1\",null,{\"_type\":\"title\",\"className\":\"font-display font-medium text-pretty max-md:max-w-[282px]\",\"children\":[[\"$\",\"span\",\"217aaeafb8bc\",{\"className\":\"title-hero-heading text-4xl tracking-tighter lg:text-6xl\",\"children\":[\"This page could not\u2028 be found\"]}]]}],[\"$\",\"div\",null,{\"className\":\"prose-sm lg:prose-base prose-p:leading-normal prose-p:my-0 prose-ul:pl-0 prose-li:pl-0 prose-li:my-0 w-full items-center justify-center max-w-[488px]\",\"children\":[[\"$\",\"p\",\"c20010b4e260\",{\"children\":[\"Oops! Our bees flew off to pollinate somewhere else.\"]}]]}],[\"$\",\"div\",null,{\"className\":\"flex gap-6 flex-col w-full md:w-auto md:flex-row\",\"children\":[[\"$\",\"$L63\",\"0\",{\"variant\":\"solid\",\"link\":{\"_type\":\"link\",\"anchorLink\":\"/\",\"enableDownloadFunctionality\":false,\"internalLink\":null,\"target\":\"_self\",\"text\":\"Go Home\"},\"icon\":\"$undefined\",\"modalVideo\":{\"_type\":\"videoPlayer\",\"uploadedVideo\":null,\"videoSource\":\"upload\"},\"modalForm\":null}]]}]]}]}],[\"$\",\"div\",null,{\"className\":\"relative w-full shrink-1 lg:h-full lg:w-auto lg:max-w-[840px]\",\"children\":[[\"$\",\"div\",null,{\"className\":\"relative hidden h-full items-center justify-end md:flex\",\"children\":[\"$\",\"div\",null,{\"className\":\"animate-fadeIn relative w-full\",\"children\":[\"$\",\"$L31\",null,{\"src\":\"https://cdn.sanity.io/images/927dxq0h/production/6c706e9e99a2517c10e0addd89dcfcfedb72b1e4-1325x737.png\",\"alt\":\"Error 404\",\"width\":1325,\"height\":737,\"className\":\"h-auto w-auto max-w-full\",\"priority\":true}]}]}],[\"$\",\"div\",null,{\"className\":\"relative flex justify-end md:hidden\",\"children\":[\"$\",\"div\",null,{\"className\":\"animate-fadeIn relative w-full\",\"children\":null}]}]]}]]}]}]}]\n"])</script><script>self.__next_f.push([1,"62:[\"$\",\"aside\",\"1d7d38c74938\",{\"id\":\"1d7d38c74938\",\"className\":\"col-span-full py-12 lg:py-24 container\",\"children\":[[\"$\",\"div\",null,{\"className\":\"z-20 flex flex-col items-center lg:w-1/2 lg:gap-8 mx-auto mb-0 gap-8 text-center lg:mb-0\",\"children\":[null,[\"$\",\"h2\",null,{\"_type\":\"title\",\"className\":\"font-medium text-pretty font-poppins text-center text-4xl lg:text-5xl\",\"children\":[[\"$\",\"span\",\"018ecf8d4fec\",{\"className\":\"title-heading-2 tracking-tightest text-4xl lg:text-5xl\",\"children\":[\"Dive deeper\"]}]]}],[\"$\",\"div\",null,{\"className\":\"prose-sm lg:prose-base prose-p:leading-normal prose-p:my-0 prose-ul:pl-0 prose-li:pl-0 prose-li:my-0 w-full items-center justify-center\",\"children\":[[\"$\",\"p\",\"6b5338c3d254\",{\"children\":[\"Learn more about the power and possibilities of Honeycomb.\"]}]]}],null]}],[\"$\",\"div\",null,{\"className\":\"gap-4 py-10 lg:py-16 xl:flex xl:gap-6\",\"children\":[[\"$\",\"div\",null,{\"className\":\"full flex flex-col gap-4 md:flex-row lg:flex-col xl:w-[831px] xl:gap-6\",\"children\":[[\"$\",\"$L24\",\"179a5d4c-2a78-4d1f-a242-22bb1d9b4d3a\",{\"className\":\"flex-1 lg:h-[245px]\",\"href\":\"/resources/podcasts/ep-93-adaptive-sampling-strategies-with-mike-goldsmith\",\"children\":[\"$\",\"div\",null,{\"className\":\"bg-hc-gray-50 flex h-full flex-col gap-6 rounded-4xl p-2.5 lg:flex-row\",\"children\":[[\"$\",\"div\",null,{\"className\":\"relative h-[172px] w-auto md:h-[177px] lg:h-[225px] lg:w-[396px] xl:flex-1\",\"children\":[\"$\",\"$L31\",null,{\"src\":\"https://cdn.sanity.io/images/927dxq0h/production/98d12fa7a1c626c805c2de91f5e19249b843b096-1080x1080.png\",\"fill\":true,\"alt\":\"O11yCast podcast logo: a dark background with a radiating orange, blue, green, and yellow circular pattern above the white and orange text '011Y_Cast(((' and 'Everything Observability'.\",\"className\":\"aspect-video rounded-4xl object-cover\",\"sizes\":\"(max-width: 768px) 100vw, 396px\"}]}],[\"$\",\"div\",null,{\"className\":\"flex flex-1 flex-col gap-4 max-lg:px-2.5 lg:pt-4\",\"children\":[[\"$\",\"div\",null,{\"className\":\"flex items-center gap-4\",\"children\":[[\"$\",\"div\",null,{\"className\":\"font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-sky-500 text-sky-50\",\"children\":\"Podcasts\"}],[[\"$\",\"span\",null,{\"className\":\"h-3.5 border-r border-r-black/30\"}],[\"$\",\"span\",null,{\"className\":\"font-medium font-roboto text-hc-slate/70 text-xs\",\"children\":[null,[\"$\",\"span\",null,{\"children\":\"September 3, 2026\"}]]}]]]}],[\"$\",\"h3\",null,{\"className\":\"font-roboto line-clamp-2 text-base font-medium\",\"children\":\"Ep. #93, Adaptive Sampling Strategies with Mike Goldsmith\"}],[\"$\",\"p\",null,{\"className\":\"font-roboto text-hc-slate/70 line-clamp-3 text-sm font-normal max-lg:hidden\",\"children\":\"On episode 93 of O11ycast, Mike Goldsmith talks to Martin Thwaites and Ken Rimple discuss Honeycomb's contribution to the OpenTelemetry Collector, the Adaptive Tail Sampling Processor. This processor was created based on years of experience building Honeycomb's custom, industry leading tail sampler, Refinery.\\n\\n\"}]]}]]}]}],[\"$\",\"$L24\",\"a435bd91-9998-4e2e-af39-89315db18bd0\",{\"className\":\"flex-1 lg:h-[245px]\",\"href\":\"/resources/leading-with-observability/leading-with-observability-scaling-fin-to-2x-engineering-productivity\",\"children\":[\"$\",\"div\",null,{\"className\":\"bg-hc-gray-50 flex h-full flex-col gap-6 rounded-4xl p-2.5 lg:flex-row\",\"children\":[[\"$\",\"div\",null,{\"className\":\"relative h-[172px] w-auto md:h-[177px] lg:h-[225px] lg:w-[396px] xl:flex-1\",\"children\":[\"$\",\"$L31\",null,{\"src\":\"https://cdn.sanity.io/images/927dxq0h/production/ca5665e8cba53cfd097fff94757ec1479ad2bf31-1920x1080.jpg\",\"fill\":true,\"alt\":\"Title slide for the series \\\"Leading With Observability,\\\" Episode 1: \\\"Scaling Fin to 2x Engineering Productivity,\\\" featuring Darragh Curran (CTO, Fin) and Charity Majors (CTO, Honeycomb).\",\"className\":\"aspect-video rounded-4xl object-cover\",\"sizes\":\"(max-width: 768px) 100vw, 396px\"}]}],\"$L64\"]}]}]]}],\"$L65\"]}],\"$L66\"]}]\n"])</script><script>self.__next_f.push([1,"64:[\"$\",\"div\",null,{\"className\":\"flex flex-1 flex-col gap-4 max-lg:px-2.5 lg:pt-4\",\"children\":[[\"$\",\"div\",null,{\"className\":\"flex items-center gap-4\",\"children\":[[\"$\",\"div\",null,{\"className\":\"font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gray-200 text-hc-slate\",\"children\":\"Leading With Observability\"}],[[\"$\",\"span\",null,{\"className\":\"h-3.5 border-r border-r-black/30\"}],[\"$\",\"span\",null,{\"className\":\"font-medium font-roboto text-hc-slate/70 text-xs\",\"children\":[null,[\"$\",\"span\",null,{\"children\":\"August 27, 2026\"}]]}]]]}],[\"$\",\"h3\",null,{\"className\":\"font-roboto line-clamp-2 text-base font-medium\",\"children\":\"Leading With Observability: Scaling Fin to 2x Engineering Productivity\"}],[\"$\",\"p\",null,{\"className\":\"font-roboto text-hc-slate/70 line-clamp-3 text-sm font-normal max-lg:hidden\",\"children\":\"Darragh Curran, CTO at Fin (formerly Intercom), set out to double engineering productivity—and nearly tripled it instead, using AI-driven code, an AI-powered PR review system, observability as a trust mechanism, and much more hands-on leadership. In the first episode of Leading With Observability, Charity gets into the messy bits behind that transformation, not just the highlight reel.\"}]]}]\n"])</script><script>self.__next_f.push([1,"65:[\"$\",\"div\",null,{\"className\":\"full flex flex-col gap-4 max-xl:mt-4 md:flex-col lg:flex-row xl:flex-1 xl:flex-col xl:gap-6\",\"children\":[[\"$\",\"$L24\",\"aws-honeycomb-workshop-ai-investigators\",{\"href\":\"/resources/webinars/aws-honeycomb-workshop-ai-investigators\",\"className\":\"flex-1 lg:h-[130px]\",\"children\":[\"$\",\"div\",null,{\"className\":\"bg-hc-gray-50 flex h-full gap-4 rounded-3xl p-4 xl:gap-6 xl:rounded-4xl xl:p-2.5\",\"children\":[[\"$\",\"div\",null,{\"className\":\"relative h-[84px] w-[84px] self-start xl:h-[135px] xl:w-[135px]\",\"children\":[\"$\",\"div\",null,{\"className\":\"aspect-square h-full w-full overflow-hidden rounded-2xl bg-white xl:rounded-3xl\",\"children\":[\"$\",\"svg\",null,{\"xmlns\":\"http://www.w3.org/2000/svg\",\"viewBox\":\"0 0 542 542\",\"fill\":\"none\",\"className\":\"h-full w-full\",\"children\":[[\"$\",\"path\",null,{\"fill\":\"#FBEDF0\",\"d\":\"M0 0h542v542H0z\"}],[\"$\",\"path\",null,{\"fill\":\"#F7D2D7\",\"d\":\"M460.213 394.786c38.019-55.443 16.608-179.375-78.922-214.08-56.823-20.676-114.265-101.902-218.578-66.827a195.6 195.6 0 0 0-8.51 3.138 160.962 160.962 0 0 0-8.235 3.692C38.36 174.244 36.576 301.622 141.37 345.065c89.764 37.168 248.431 152.484 318.843 49.721Z\"}],[\"$\",\"rect\",null,{\"width\":318,\"height\":202,\"x\":107,\"y\":166,\"fill\":\"#fff\",\"rx\":5}],[\"$\",\"rect\",null,{\"width\":318,\"height\":202,\"x\":107,\"y\":166,\"stroke\":\"#E4A3A5\",\"strokeWidth\":10,\"rx\":5}],[\"$\",\"circle\",null,{\"cx\":198,\"cy\":243,\"r\":23,\"fill\":\"#E65B53\"}],[\"$\",\"path\",null,{\"fill\":\"#E65B53\",\"d\":\"M155 314a43.001 43.001 0 0 1 73.406-30.406A43.001 43.001 0 0 1 241 314h-86Z\"}],[\"$\",\"g\",null,{\"clipPath\":\"url(#a)\",\"children\":[[\"$\",\"path\",null,{\"fill\":\"#FBEDF0\",\"d\":\"M301 187h47.472v47.472H301z\"}],[\"$\",\"circle\",null,{\"cx\":324.737,\"cy\":202.844,\"r\":7.053,\"fill\":\"#E65B53\"}],[\"$\",\"path\",null,{\"fill\":\"#E65B53\",\"d\":\"M311.55 224.618a13.19 13.19 0 0 1 13.187-13.187 13.188 13.188 0 0 1 13.187 13.187H311.55Z\"}]]}],[\"$\",\"g\",null,{\"clipPath\":\"url(#b)\",\"children\":[[\"$\",\"path\",null,{\"fill\":\"#FBEDF0\",\"d\":\"M301 243.264h47.472v47.472H301z\"}],[\"$\",\"circle\",null,{\"cx\":324.737,\"cy\":259.108,\"r\":7.053,\"fill\":\"#E65B53\"}],[\"$\",\"path\",null,{\"fill\":\"#E65B53\",\"d\":\"M311.55 280.882a13.188 13.188 0 0 1 26.374 0H311.55Z\"}]]}],[\"$\",\"g\",null,{\"clipPath\":\"url(#c)\",\"children\":[[\"$\",\"path\",null,{\"fill\":\"#FBEDF0\",\"d\":\"M301 299.527h47.472v47.472H301z\"}],[\"$\",\"circle\",null,{\"cx\":324.737,\"cy\":315.372,\"r\":7.053,\"fill\":\"#E65B53\"}],[\"$\",\"path\",null,{\"fill\":\"#E65B53\",\"d\":\"M311.55 337.145a13.187 13.187 0 0 1 26.374 0H311.55Z\"}]]}],[\"$\",\"g\",null,{\"clipPath\":\"url(#d)\",\"children\":[[\"$\",\"path\",null,{\"fill\":\"#FBEDF0\",\"d\":\"M357.264 187h47.472v47.472h-47.472z\"}],[\"$\",\"circle\",null,{\"cx\":381.001,\"cy\":202.844,\"r\":7.053,\"fill\":\"#E65B53\"}],[\"$\",\"path\",null,{\"fill\":\"#E65B53\",\"d\":\"M367.814 224.618a13.188 13.188 0 0 1 13.187-13.187 13.186 13.186 0 0 1 13.187 13.187h-26.374Z\"}]]}],[\"$\",\"g\",null,{\"clipPath\":\"url(#e)\",\"children\":[[\"$\",\"path\",null,{\"fill\":\"#FBEDF0\",\"d\":\"M357.264 243.264h47.472v47.472h-47.472z\"}],[\"$\",\"circle\",null,{\"cx\":381.001,\"cy\":259.108,\"r\":7.053,\"fill\":\"#E65B53\"}],[\"$\",\"path\",null,{\"fill\":\"#E65B53\",\"d\":\"M367.814 280.882a13.187 13.187 0 1 1 26.374 0h-26.374Z\"}]]}],[\"$\",\"g\",null,{\"clipPath\":\"url(#f)\",\"children\":[[\"$\",\"path\",null,{\"fill\":\"#FBEDF0\",\"d\":\"M357.264 299.527h47.472v47.472h-47.472z\"}],[\"$\",\"circle\",null,{\"cx\":381.001,\"cy\":315.372,\"r\":7.053,\"fill\":\"#E65B53\"}],[\"$\",\"path\",null,{\"fill\":\"#E65B53\",\"d\":\"M367.814 337.145a13.186 13.186 0 1 1 26.374 0h-26.374Z\"}]]}],[\"$\",\"circle\",null,{\"cx\":412.5,\"cy\":188.5,\"r\":53.5,\"fill\":\"#E65B53\"}],[\"$\",\"path\",null,{\"fill\":\"#fff\",\"d\":\"M434.842 186.768c1.333.77 1.333 2.695 0 3.464l-32.013 18.483c-1.334.77-3-.192-3-1.732v-36.965c0-1.54 1.666-2.502 3-1.733l32.013 18.483Z\"}],[\"$\",\"path\",null,{\"fill\":\"#D75450\",\"d\":\"M238 373h55v27h-55z\"}],[\"$\",\"rect\",null,{\"width\":168,\"height\":27,\"x\":182,\"y\":400,\"fill\":\"#E4A3A5\",\"rx\":13.5}],[\"$\",\"path\",null,{\"stroke\":\"#D75450\",\"strokeLinecap\":\"round\",\"strokeWidth\":5,\"d\":\"M87.805 426.408c5.565 2.626 19.049 5.505 28.461-3.987 9.412-9.491 8.73-19.101 2.011-24.32-5.871-4.135-17.918-1.146-17.026 10.748 1.116 14.868 23.483 16.543 40.084 5.253\"}],[\"$\",\"defs\",null,{\"children\":[[\"$\",\"clipPath\",null,{\"id\":\"a\",\"children\":[\"$\",\"path\",null,{\"fill\":\"#fff\",\"d\":\"M301 187h47.472v47.472H301z\"}]}],[\"$\",\"clipPath\",null,{\"id\":\"b\",\"children\":[\"$\",\"path\",null,{\"fill\":\"#fff\",\"d\":\"M301 243.264h47.472v47.472H301z\"}]}],[\"$\",\"clipPath\",null,{\"id\":\"c\",\"children\":[\"$\",\"path\",null,{\"fill\":\"#fff\",\"d\":\"M301 299.527h47.472v47.472H301z\"}]}],[\"$\",\"clipPath\",null,{\"id\":\"d\",\"children\":[\"$\",\"path\",null,{\"fill\":\"#fff\",\"d\":\"M357.264 187h47.472v47.472h-47.472z\"}]}],[\"$\",\"clipPath\",null,{\"id\":\"e\",\"children\":[\"$\",\"path\",null,{\"fill\":\"#fff\",\"d\":\"M357.264 243.264h47.472v47.472h-47.472z\"}]}],\"$L67\"]}]]}]}]}],\"$L68\"]}]}],\"$L69\",\"$L6a\"]}]\n"])</script><script>self.__next_f.push([1,"66:[\"$\",\"div\",null,{\"className\":\"flex w-full justify-center\",\"children\":[\"$\",\"$L63\",null,{\"variant\":\"solid\",\"link\":{\"_type\":\"link\",\"anchorLink\":\"/resources/\",\"enableDownloadFunctionality\":false,\"internalLink\":null,\"target\":\"_self\",\"text\":\"See All Resources\"},\"modalVideo\":{\"_type\":\"videoPlayer\",\"uploadedVideo\":null,\"videoSource\":\"upload\"},\"modalForm\":null}]}]\n"])</script><script>self.__next_f.push([1,"67:[\"$\",\"clipPath\",null,{\"id\":\"f\",\"children\":[\"$\",\"path\",null,{\"fill\":\"#fff\",\"d\":\"M357.264 299.527h47.472v47.472h-47.472z\"}]}]\n68:[\"$\",\"div\",null,{\"className\":\"flex flex-1 flex-col items-start gap-3 xl:pt-[6px]\",\"children\":[[\"$\",\"div\",null,{\"className\":\"font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-purple-100 text-purple-800\",\"children\":\"Webinars\"}],[\"$\",\"h4\",null,{\"className\":\"font-roboto line-clamp-3 text-sm font-medium xl:text-base\",\"children\":\"How Observability Makes Better AI and Human Investigators\"}]]}]\n"])</script><script>self.__next_f.push([1,"69:[\"$\",\"$L24\",\"6dd1ee72-dedf-4b16-b7f1-a5b6f4651390\",{\"href\":\"/resources/getting-started/what-is-contextual-observability\",\"className\":\"flex-1 lg:h-[130px]\",\"children\":[\"$\",\"div\",null,{\"className\":\"bg-hc-gray-50 flex h-full gap-4 rounded-3xl p-4 xl:gap-6 xl:rounded-4xl xl:p-2.5\",\"children\":[[\"$\",\"div\",null,{\"className\":\"relative h-[84px] w-[84px] self-start xl:h-[135px] xl:w-[135px]\",\"children\":[\"$\",\"div\",null,{\"className\":\"aspect-square h-full w-full overflow-hidden rounded-2xl bg-white xl:rounded-3xl\",\"children\":[\"$\",\"$L31\",null,{\"src\":\"https://cdn.sanity.io/images/927dxq0h/production/a01b9544c925d87885e1c978bdee5fc2fae3250b-3840x2160.png\",\"fill\":true,\"alt\":\"What Is Contextual Observability? A Practitioner's Guide for Modern Engineering Teams\",\"className\":\"aspect-square rounded-[14px] object-cover xl:rounded-4xl\",\"sizes\":\"(max-width: 768px) 25vw, 135px\"}]}]}],[\"$\",\"div\",null,{\"className\":\"flex flex-1 flex-col items-start gap-3 xl:pt-[6px]\",\"children\":[[\"$\",\"div\",null,{\"className\":\"font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-green-800 text-hc-green-50\",\"children\":\"Getting Started\"}],[\"$\",\"h4\",null,{\"className\":\"font-roboto line-clamp-3 text-sm font-medium xl:text-base\",\"children\":\"What Is Contextual Observability? A Practitioner's Guide for Modern Engineering Teams\"}]]}]]}]}]\n"])</script><script>self.__next_f.push([1,"6a:[\"$\",\"$L24\",\"c81456fb-93ee-4ae9-a4b9-9d3633bb10f2\",{\"href\":\"/resources/conference-talks/socratic-ai-integrating-observability-through-interactive-dialogue-o11ycon-2026\",\"className\":\"flex-1 lg:h-[130px]\",\"children\":[\"$\",\"div\",null,{\"className\":\"bg-hc-gray-50 flex h-full gap-4 rounded-3xl p-4 xl:gap-6 xl:rounded-4xl xl:p-2.5\",\"children\":[[\"$\",\"div\",null,{\"className\":\"relative h-[84px] w-[84px] self-start xl:h-[135px] xl:w-[135px]\",\"children\":[\"$\",\"div\",null,{\"className\":\"aspect-square h-full w-full overflow-hidden rounded-2xl bg-white xl:rounded-3xl\",\"children\":[\"$\",\"$L31\",null,{\"src\":\"https://cdn.sanity.io/images/927dxq0h/production/8566ea5ab858dce76a0029af4067db3e6eccdd84-1920x1080.png\",\"fill\":true,\"alt\":\"Socratic AI: Integrating Observability Through Interactive Dialogue - O11yCon 2026\",\"className\":\"aspect-square rounded-[14px] object-cover xl:rounded-4xl\",\"sizes\":\"(max-width: 768px) 25vw, 135px\"}]}]}],[\"$\",\"div\",null,{\"className\":\"flex flex-1 flex-col items-start gap-3 xl:pt-[6px]\",\"children\":[[\"$\",\"div\",null,{\"className\":\"font-roboto focus:ring-ring inline-flex items-center rounded-lg font-medium transition-colors focus:ring-2 focus:ring-offset-2 focus:outline-none px-2 py-1 text-xs leading-normal bg-hc-gold-300 text-gold-1000\",\"children\":\"Conference Talks\"}],[\"$\",\"h4\",null,{\"className\":\"font-roboto line-clamp-3 text-sm font-medium xl:text-base\",\"children\":\"Socratic AI: Integrating Observability Through Interactive Dialogue - O11yCon 2026\"}]]}]]}]}]\n"])</script></body></html>