<?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: Ludde</title>
    <description>The latest articles on DEV Community by Ludde (@skglnd).</description>
    <link>https://dev.to/skglnd</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.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4230445%2Fed93b708-bd34-4f9e-982d-79558c50e40b.png</url>
      <title>DEV Community: Ludde</title>
      <link>https://dev.to/skglnd</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/skglnd"/>
    <language>en</language>
    <item>
      <title>Building a service status notifier with .NET and Cloudflare Workers</title>
      <dc:creator>Ludde</dc:creator>
      <pubDate>Fri, 06 Nov 2026 12:49:38 +0000</pubDate>
      <link>https://dev.to/skglnd/building-a-service-status-notifier-with-net-and-cloudflare-workers-22f9</link>
      <guid>https://dev.to/skglnd/building-a-service-status-notifier-with-net-and-cloudflare-workers-22f9</guid>
      <description>&lt;p&gt;I've been working on a small side project recently.&lt;/p&gt;

&lt;p&gt;Like most developers I depend on quite a few external services. GitHub, Cloudflare, OpenAI, and others.&lt;/p&gt;

&lt;p&gt;When something breaks, I usually end up checking their individual status pages to figure out what's going on.&lt;/p&gt;

&lt;p&gt;I wanted a simpler way to keep track of these incidents and get notified in Slack without having to configure every provider separately.&lt;/p&gt;

&lt;p&gt;So I started building &lt;strong&gt;&lt;a href="https://StatusRelay.dev" rel="noopener noreferrer"&gt;https://StatusRelay.dev&lt;/a&gt;&lt;/strong&gt;.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Why build another status monitoring tool?&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Of course, tools like this already exist, and they offer much more comprehensive solutions.&lt;/p&gt;

&lt;p&gt;I wasn't trying to reinvent everything they do. I just wanted something lightweight where I could select the services I care about, connect a Slack channel or webhook, and start receiving notifications.&lt;/p&gt;

&lt;p&gt;No accounts, no paid plans, and no complicated setup.&lt;/p&gt;

&lt;p&gt;It also seemed like a fun opportunity to experiment with event processing, background jobs, and reliable notification delivery.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;But how does it work?!&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;The idea is pretty straightforward:&lt;/p&gt;

&lt;p&gt;Poll official status APIs from different providers.&lt;/p&gt;

&lt;p&gt;Normalize their status and incident information.&lt;/p&gt;

&lt;p&gt;Store incidents and detect changes.&lt;/p&gt;

&lt;p&gt;Send notifications to Slack or custom webhooks.&lt;/p&gt;

&lt;p&gt;The backend uses .NET 10 with PostgreSQL. An Azure Container Apps job handles polling, while Cloudflare Workers handles subscriptions, the frontend and notification delivery.&lt;/p&gt;

&lt;p&gt;Currently, it supports ~36 providers.&lt;/p&gt;

&lt;p&gt;I initially thought fetching status information would be the easy part.&lt;/p&gt;

&lt;p&gt;But not every provider exposes incidents in the same way.&lt;/p&gt;

&lt;p&gt;Some use Atlassian Statuspage, others have completely different formats. Some feeds provide detailed incident updates, while others give you very little information.&lt;/p&gt;

&lt;p&gt;Another interesting problem is handling stale data and irrelevant updates.&lt;/p&gt;

&lt;p&gt;If a provider's status API stops responding, should the dashboard continue showing green based on the last successful check?&lt;/p&gt;

&lt;p&gt;I decided it shouldn't. Once the data gets too old, the status is marked as unavailable rather than assuming everything is operational.&lt;/p&gt;

&lt;p&gt;Notifications introduce their own challenges too. You dont want to send duplicate messages every time you poll an API. You need to track incident changes, handle delivery failures and avoid replaying old incidents to new subscribers.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;How far have I come?&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;The project is up and running, and I've been testing Slack and webhook notifications.&lt;/p&gt;

&lt;p&gt;It relies on official provider status feeds, so it's not an independent uptime monitor. That's an important limitation.&lt;/p&gt;

&lt;p&gt;There's still plenty to improve, particularly around how incident updates and notifications are handled.&lt;/p&gt;

&lt;p&gt;If you're curious, you can check it out here:&lt;/p&gt;

&lt;p&gt;&lt;a href="https://statusrelay.dev" rel="noopener noreferrer"&gt;https://statusrelay.dev&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;How do you monitor incidents across external services? Do you use a dedicated service, individual status subscriptions, or something you've built yourself?&lt;/p&gt;

</description>
      <category>dotnet</category>
      <category>serverless</category>
      <category>sideprojects</category>
      <category>showdev</category>
    </item>
  </channel>
</rss>
