<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Ebby Peter</title>
    <description>The latest articles on DEV Community by Ebby Peter (@ebbypeter).</description>
    <link>https://dev.to/ebbypeter</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F272082%2F980ad437-d177-47a4-af1b-cf86d698ed0f.jpeg</url>
      <title>DEV Community: Ebby Peter</title>
      <link>https://dev.to/ebbypeter</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/ebbypeter"/>
    <language>en</language>
    <item>
      <title>KQL for Adults: Writing Queries That Don't Lie to You</title>
      <dc:creator>Ebby Peter</dc:creator>
      <pubDate>Tue, 17 Mar 2026 00:00:00 +0000</pubDate>
      <link>https://dev.to/ebbypeter/kql-for-adults-writing-queries-that-dont-lie-to-you-415b</link>
      <guid>https://dev.to/ebbypeter/kql-for-adults-writing-queries-that-dont-lie-to-you-415b</guid>
      <description>&lt;p&gt;Most KQL running in production is subtly wrong. Wrong operators, unscoped subqueries, and alert rules that silently miss events due to ingestion latency. Here’s how to write queries you can actually defend.&lt;/p&gt;

&lt;p&gt;&lt;a href="http://blog.ebbypeter.com/2026/03/kql-for-adults-writing-queries-that-dont-lie-to-you/" rel="noopener noreferrer"&gt;More &amp;gt;&amp;gt;&lt;/a&gt;&lt;/p&gt;

</description>
      <category>analytics</category>
      <category>azure</category>
      <category>data</category>
      <category>monitoring</category>
    </item>
    <item>
      <title>Why Your Application Gateway Logs Don't Tell the Whole Story (Until You Correlate Them)</title>
      <dc:creator>Ebby Peter</dc:creator>
      <pubDate>Tue, 10 Mar 2026 00:00:00 +0000</pubDate>
      <link>https://dev.to/ebbypeter/why-your-application-gateway-logs-dont-tell-the-whole-story-until-you-correlate-them-2mfk</link>
      <guid>https://dev.to/ebbypeter/why-your-application-gateway-logs-dont-tell-the-whole-story-until-you-correlate-them-2mfk</guid>
      <description>&lt;p&gt;Access logs, firewall logs, backend health, and metrics each tell a partial truth about what Application Gateway is doing. Here’s how they mislead you in isolation, and the KQL that fixes that.&lt;/p&gt;

&lt;p&gt;&lt;a href="http://blog.ebbypeter.com/2026/03/why-your-application-gateway-logs-dont-tell-the-whole-story-until-you-correlate-them/" rel="noopener noreferrer"&gt;More...&lt;/a&gt;&lt;/p&gt;

</description>
    </item>
    <item>
      <title>Detection Is Not Protection: What Azure WAF Detection Mode Actually Does (and Doesn't)</title>
      <dc:creator>Ebby Peter</dc:creator>
      <pubDate>Tue, 03 Mar 2026 00:00:00 +0000</pubDate>
      <link>https://dev.to/ebbypeter/detection-is-not-protection-what-azure-waf-detection-mode-actually-does-and-doesnt-5fb2</link>
      <guid>https://dev.to/ebbypeter/detection-is-not-protection-what-azure-waf-detection-mode-actually-does-and-doesnt-5fb2</guid>
      <description>&lt;p&gt;Most teams think a WAF in Detection mode is partially protecting them. It isn’t. Here’s what actually happens to requests, why the logs actively mislead, and how organisations end up stuck in Detection mode indefinitely without noticing.&lt;/p&gt;

&lt;p&gt;&lt;a href="http://blog.ebbypeter.com/2026/03/detection-is-not-protection-what-azure-waf-detection-mode-actually-does-and-doesnt/" rel="noopener noreferrer"&gt;More...&lt;/a&gt;&lt;/p&gt;

</description>
      <category>azure</category>
      <category>cloud</category>
      <category>cybersecurity</category>
      <category>security</category>
    </item>
    <item>
      <title>The Hidden Cost of 'Just Turn On Logging' in Azure</title>
      <dc:creator>Ebby Peter</dc:creator>
      <pubDate>Sun, 01 Mar 2026 20:44:55 +0000</pubDate>
      <link>https://dev.to/ebbypeter/the-hidden-cost-of-just-turn-on-logging-in-azure-3kgi</link>
      <guid>https://dev.to/ebbypeter/the-hidden-cost-of-just-turn-on-logging-in-azure-3kgi</guid>
      <description>&lt;blockquote&gt;
&lt;p&gt;Why your Log Analytics bill is lying to you, and how to fix it before it compounds.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Your team enabled logging everywhere, a responsible move. Then the Azure bill arrived. This post traces exactly why Log Analytics costs spiral without warning, what the AzureDiagnostics table is quietly doing to your budget, and how resource-specific tables plus DCR transformations give you back control.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://blog.ebbypeter.com/2026/01/the-hidden-cost-of-just-turn-on-logging-in-azure/" rel="noopener noreferrer"&gt;More...&lt;/a&gt;&lt;/p&gt;

</description>
      <category>azure</category>
      <category>cloudengineering</category>
      <category>finops</category>
      <category>architecture</category>
    </item>
    <item>
      <title>Autoscaling Is Not a Recovery Strategy</title>
      <dc:creator>Ebby Peter</dc:creator>
      <pubDate>Thu, 26 Feb 2026 20:12:58 +0000</pubDate>
      <link>https://dev.to/ebbypeter/autoscaling-is-not-a-recovery-strategy-3l97</link>
      <guid>https://dev.to/ebbypeter/autoscaling-is-not-a-recovery-strategy-3l97</guid>
      <description>&lt;blockquote&gt;
&lt;p&gt;A guide for cloud engineers, SREs, and the engineering managers who ask "why is the system still down, didn’t we autoscale?"&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Autoscaling is not a recovery strategy. It’s an elasticity tool, and knowing the difference is what separates teams that survive incidents from teams that just watch their instance count go up while users experience the outage anyway.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://blog.ebbypeter.com/2026/01/autoscaling-is-not-a-recovery-strategy/" rel="noopener noreferrer"&gt;More...&lt;/a&gt;&lt;/p&gt;

</description>
      <category>sitereliabilityengineering</category>
      <category>azure</category>
      <category>architecture</category>
      <category>resilience</category>
    </item>
    <item>
      <title>dotLOG - Bringing Notepad's Best Kept Secret to VS Code</title>
      <dc:creator>Ebby Peter</dc:creator>
      <pubDate>Thu, 26 Feb 2026 00:23:09 +0000</pubDate>
      <link>https://dev.to/ebbypeter/dotlog-bringing-notepads-best-kept-secret-to-vs-code-g34</link>
      <guid>https://dev.to/ebbypeter/dotlog-bringing-notepads-best-kept-secret-to-vs-code-g34</guid>
      <description>&lt;p&gt;Windows Notepad has had a hidden logging trick since 1992 - type .LOG as the first line of a file and it automatically appends a timestamp every time you open it. I missed it when I moved to VS Code, so I built dotLOG to bring it back.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://marketplace.visualstudio.com/items?itemName=cloudfractal.dotlog" rel="noopener noreferrer"&gt;dotLOG in VSCode Marketplace&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href="https://blog.ebbypeter.com/2026/01/dotlog-bringing-notepads-best-kept-secret-to-vs-code/" rel="noopener noreferrer"&gt;More&lt;/a&gt;&lt;/p&gt;

</description>
      <category>vscode</category>
      <category>extensions</category>
    </item>
    <item>
      <title>Your Alerts Are a Product. They're Just a Bad One.</title>
      <dc:creator>Ebby Peter</dc:creator>
      <pubDate>Tue, 24 Feb 2026 00:00:00 +0000</pubDate>
      <link>https://dev.to/ebbypeter/your-alerts-are-a-product-theyre-just-a-bad-one-4ckk</link>
      <guid>https://dev.to/ebbypeter/your-alerts-are-a-product-theyre-just-a-bad-one-4ckk</guid>
      <description>&lt;p&gt;Alert fatigue isn’t a people problem, it’s a product design failure. Your on-call engineers are the users. Here’s why noisy alerts are biologically inevitable under bad design, and what treating alerting as a product actually looks like.&lt;/p&gt;

&lt;p&gt;&lt;a href="http://blog.ebbypeter.com/2026/02/your-alerts-are-a-product.-theyre-just-a-bad-one./" rel="noopener noreferrer"&gt;More...&lt;/a&gt;&lt;/p&gt;

</description>
      <category>devops</category>
      <category>monitoring</category>
      <category>sre</category>
      <category>ux</category>
    </item>
    <item>
      <title>Azure Will Stay Up. Your System Is a Different Story.</title>
      <dc:creator>Ebby Peter</dc:creator>
      <pubDate>Tue, 17 Feb 2026 00:00:00 +0000</pubDate>
      <link>https://dev.to/ebbypeter/azure-will-stay-up-your-system-is-a-different-story-5047</link>
      <guid>https://dev.to/ebbypeter/azure-will-stay-up-your-system-is-a-different-story-5047</guid>
      <description>&lt;blockquote&gt;
&lt;p&gt;The Azure status page is green. Your users are getting errors. Somewhere in the gap between those two facts is the outage nobody planned for.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Azure’s infrastructure is genuinely reliable. That’s exactly the problem. The more stable the platform, the easier it is to mistake platform health for system health, and that gap is where the expensive outages live. Availability is an architectural choice, not a SKU.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://blog.ebbypeter.com/2026/02/azure-will-stay-up.-your-system-is-a-different-story." rel="noopener noreferrer"&gt;More&lt;/a&gt;&lt;/p&gt;

</description>
      <category>architecture</category>
      <category>azure</category>
      <category>cloud</category>
      <category>sre</category>
    </item>
    <item>
      <title>Your DR Plan Has Never Been Tested</title>
      <dc:creator>Ebby Peter</dc:creator>
      <pubDate>Tue, 10 Feb 2026 00:00:00 +0000</pubDate>
      <link>https://dev.to/ebbypeter/your-dr-plan-has-never-been-tested-cln</link>
      <guid>https://dev.to/ebbypeter/your-dr-plan-has-never-been-tested-cln</guid>
      <description>&lt;blockquote&gt;
&lt;p&gt;Most DR tests prove the secondary came up. Not that your RTO is real, your data is intact, or your failback won’t destroy the incident window. Let’s fix that.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Most Azure DR tests confirm the secondary came up. They don’t confirm your RTO is real, your RPO commitment holds under load, or that failback won’t silently destroy the incident window. Here’s how to test DR honestly, with exit criteria that actually prove the plan works.&lt;/p&gt;

&lt;p&gt;&lt;a href="http://blog.ebbypeter.com/2026/02/your-dr-plan-has-never-been-tested/" rel="noopener noreferrer"&gt;More&lt;/a&gt;&lt;/p&gt;

</description>
      <category>azure</category>
      <category>devops</category>
      <category>sre</category>
      <category>testing</category>
    </item>
    <item>
      <title>The Hidden Cost of 'Retry Everything': How Naive Retry Logic Creates a Self-Inflicted DDoS</title>
      <dc:creator>Ebby Peter</dc:creator>
      <pubDate>Tue, 03 Feb 2026 00:00:00 +0000</pubDate>
      <link>https://dev.to/ebbypeter/the-hidden-cost-of-retry-everything-how-naive-retry-logic-creates-a-self-inflicted-ddos-5h4j</link>
      <guid>https://dev.to/ebbypeter/the-hidden-cost-of-retry-everything-how-naive-retry-logic-creates-a-self-inflicted-ddos-5h4j</guid>
      <description>&lt;p&gt;Retries are load, not safety. Without exponential backoff and jitter, your retry logic doesn’t protect against outages, it causes them. This post covers the mechanics of retry storms, five anti-patterns found in real production code, and what correct retry design actually looks like across layered Azure architectures.&lt;/p&gt;

&lt;p&gt;&lt;a href="https://blog.ebbypeter.com/2026/02/the-hidden-cost-of-retry-everything-how-naive-retry-logic-creates-a-self-inflicted-ddos/" rel="noopener noreferrer"&gt;More&lt;/a&gt;&lt;/p&gt;

</description>
      <category>azure</category>
      <category>distributedsystems</category>
      <category>sre</category>
      <category>systemdesign</category>
    </item>
  </channel>
</rss>
