Azure retirements in September 2026 need more than one source to track

Late September is when a lot of Azure retirements land. Every year another batch of services and APIs quietly goes away, and the real question is which of those deadlines hit your own subscriptions. I run into the same problem in project after project. Global announcements are easy to find, but nothing gives you a single view of what actually affects your own Azure resources. September 2026 is getting close (the HTTP Data Collector API retirement is a prominent example, and I've covered it in my post on migrating to the Logs Ingestion API), so this is a good moment to look again at how to keep track of Azure retirements before they turn into last-minute work.

Microsoft spreads retirement news across several channels

Retirement news from Microsoft shows up in Service Health advisories in the portal, in Azure Advisor recommendations and workbooks, on the public Azure Updates site and sometimes deep in the documentation. You never get one current list tailored to your tenant. That's exactly why so many admins get caught off guard. Email digests and newsletters don't cover it, and neither does hoping that global changes will somehow surface in your tenant on their own. What works in practice is combining several sources and checking them regularly or, better still, having notifications sent automatically.

Service Health advisories show the retirements that affect your resources

Start in the Azure portal under "Service Health" → "Health advisories" (Reader permissions on a subscription are enough). This is your personal feed of active and past advisories for your subscriptions and resources. Retirement advisories appear here as soon as Microsoft flags one of your resources as impacted. I filter or search for keywords like "retirement", "deprecated" or "service change", but I always open the details, because the subject line rarely tells the whole story. For something like the HTTP Data Collector API retirement, this is where you'll find the migration timing and the specific resources that are affected.

The Advisor retirement workbook gives you a tenant-wide view

Many people overlook the "Service upgrade and retirement" workbook in Azure Advisor (Azure portal → Advisor → Recommendations → Workbook). For core Azure services, it's the only way to see at a glance, across the whole tenant, what is scheduled for retirement. It lists affected resources, deadline estimates and actionable steps. Marketplace offerings and niche APIs can still slip through, but for mainstream services it saves a lot of headaches.

Tip: If you filter the Advisor retirement workbook regularly, you'll catch most critical deadlines long before an email or a generic news post reaches you. It's especially handy for backend services or resources you rarely open in the portal.

The public Azure Updates page shows what is coming globally

The Azure Updates page is the public feed, and you can filter it for "Retirement". It isn't tenant-specific, but it's the best place to see what's on the way, even before anything appears in Service Health or Advisor. Regional details and resource-specific information are often missing, so cross-check entries against your own advisories. If your organization runs multiple tenants or subscriptions, keep this page bookmarked. I go through it once a month and compare the entries with the tenant advisories. Microsoft's official guidance on migration planning for Azure retirements is also a good read for best practices and workflow tips.

Service Health alerts warn you before a deadline catches you off guard

Checking manually only gets you so far, so set up Service Health alerts in the Azure portal (this requires Contributor permissions on each subscription). You can configure alerts for new advisories, retirements included, and send them by email or SMS, or route them through Logic Apps or Teams. In the portal, open "Service Health", select "Alerts" and create a new rule. Choose "Service issues" and set the event type filter to "Health advisories". I also add a text filter for terms like "retirement", "deprecate" or "end of support".

A typical JSON example for such a rule:

{
  "eventType": "Health Advisory",
  "searchText": "retirement"
}

Test that the alerts actually arrive and keep the notification group current. Critical notices ending up in a mailbox nobody reads is a classic mistake.

A simple diagram shows how the sources fit together

This diagram shows how the different information sources for Azure retirements September 2026 connect. None of them replaces the others:

flowchart TD
    AzureUpdates["Azure Updates page"] --> Admin["Admin reviews retirements"]
    ServiceHealth["Service Health (Advisories)"] --> Admin
    AdvisorWorkbook["Advisor retirement workbook"] --> Admin
    HealthAlerts["Service Health alerts"] --> Admin

Figure: Azure retirement info sources. You only get full coverage by combining them.

A steady process works better than last-minute panic

Relying on a single channel for Azure retirements September 2026 is wishful thinking. In my projects I always combine three things. I follow public announcements early, I check the tenant's advisories and Advisor workbooks regularly, and I set up Service Health alerts as a safety net. That's how a deadline like the HTTP Data Collector API retirement becomes a routine migration project instead of an emergency. If you haven't set up the workbook and alerts yet, do it now, because another retirement wave is always coming. For official deadlines and tenant-specific details, I always refer to what the Azure portal and Azure Service Health currently show.