# Azure's 30 September retirements: what stops working

More than ten Azure items retire on 30 September 2026, and the ones that fail silently are more dangerous than the ones that fail loudly: URL ping tests are deleted from your resources and the ContainerLog table stops receiving data, taking alert rules down with them. A triage guide with Resource Graph queries, Sweden Central cost math for standard web tests and Basic Logs, and a checklist for the Functions v3, Service Bus SBMP and 1 October AI service deadlines.

- Published: 2026-09-19 · Category: Azure & Cloud · Tags: Azure Retirements, Application Insights, Availability Tests, ContainerLogV2, Azure Functions, Service Bus, SBMP, Azure Monitor, NIS2, Sweden Central
- Author: Technspire AB, Stockholm (https://technspire.com)
- Canonical: https://technspire.com/en/blog/azure-30-september-retirements-what-stops-working

Ten Azure services, APIs and SDKs on Microsoft's 2026 lifecycle list reach their retirement date on Wednesday 30 September, Functions v3 apps on Linux Consumption stop running the same day, and three more AI services follow on 1 October. Two retirements already passed this month: support for the Azure Functions 1.x runtime ended on 14 September, and so did the Azure Monitor HTTP Data Collector API. Most teams have seen the emails. Fewer have sorted them by the question that matters for next Thursday morning: which of these break something you will notice, and which break something you won't?

That split is the whole point. A function app that stops running pages somebody within minutes. An availability test that quietly disappears from your Application Insights resource pages nobody, because the thing that would have paged them is the thing that disappeared. With eleven days left, the silent failures deserve your attention first.

## "Retired" means three different things

Microsoft uses the same word for very different outcomes. Reading the individual retirement notices rather than the summary list, the September items fall into three groups.

| Item | Date | What happens after | How you find out |
| --- | --- | --- | --- |
| Functions v3 apps on Linux Consumption | 30 Sep | Apps stop running | Loudly, if you monitor the app |
| Service Bus SBMP protocol | 30 Sep | Protocol can no longer be used | Loudly, as connection errors |
| Azure Virtual Desktop (classic) | 30 Sep | Service retired | Loudly, from users |
| Azure API for FHIR | 30 Sep | Service retired | Loudly, from integrations |
| URL ping tests in Application Insights | 30 Sep | Tests removed from your resources | **Silently** |
| ContainerLog table (Container insights) | 30 Sep | Table stops receiving data | **Silently** |
| Functions 1.x runtime | 14 Sep (passed) | Out of support | Not until something goes wrong |
| HTTP Data Collector API | 14 Sep (passed) | Ingestion continues, critical security fixes only | Not until something goes wrong |
| Legacy Service Bus SDKs over AMQP | 30 Sep | Keep working, no support or updates | Not until something goes wrong |
| Anomaly Detector, Metrics Advisor, Personalizer | 1 Oct | Services retired | Loudly, as API failures |

The remaining 30 September items (Azure FXT Edge Filer, the ACR 2017-03-01 API, older Azure Maps Web SDK versions, the Get AlertSummary API, old Service Bus control-plane API versions) are narrower. If you use one, you already know it. The rows that matter for most Swedish Azure estates follow, in the order we would work them.

## Silent failure 1: URL ping tests get deleted

The Application Insights documentation is blunt: "On September 30, 2026, URL ping tests in Application Insights will be retired. Existing URL ping tests are removed from your resources." Removed, not disabled. Any alert rule wired to those tests loses its signal, and a metric alert with no incoming data does not fire.

Ping tests are the kind of thing someone set up in 2019 for the public website and the customer portal, and nobody has looked at since because they never failed. That is exactly why they are dangerous to lose. Find them across every subscription with Azure Resource Graph. This is the query from Microsoft's migration guide, trimmed:

```
resources
| where ['type'] =~ "microsoft.insights/webtests"
| where tostring(properties.Kind) =~ "ping"
| extend enabled = tobool(properties.Enabled)
| project subscriptionId, resourceGroup, name, enabled, properties.Locations
```

Microsoft's guide includes a PowerShell script that reads each ping test and creates an equivalent standard test with the same URL, locations, frequency, timeout and content match. Two things it deliberately does not do: it leaves the ping test in place, and it does not move alert rules. Create the standard test, confirm it reports, repoint the alert rules, then delete the ping test. Doing the alert cutover last means you are never unmonitored in between.

### The cost you did not have before

URL ping tests carried no per-execution charge. Standard tests are billed per execution, and the documentation warns that migrated tests "incur charges when enabled." The Azure Retail Prices API lists Standard Web Test Execution at USD 0.000645 per execution in Sweden Central. The arithmetic for one test:

| Frequency | Locations | Executions per 30 days | USD per test per month |
| --- | --- | --- | --- |
| 5 min | 5 | 43,200 | 27.86 |
| 15 min | 5 | 14,400 | 9.29 |
| 5 min | 16 | 138,240 | 89.16 |

Retries on failure add executions on top, so treat these as floors. Microsoft recommends at least five locations so you can tell your outage from a network blip, which rules out saving money by dropping to one or two. A team with 20 ping tests at the default 5-minute, 5-location setting is looking at roughly USD 560 a month it was not paying in August. That is a budget line someone has to approve, and approvals take longer than eleven days in most organisations. Decide per test whether 5-minute granularity is needed; for an internal admin page, 15 minutes is plenty.

Standard tests do more for the money. They check TLS certificate validity and can fail the test a set number of days before a certificate expires. Turn that on during the migration rather than as a follow-up ticket.

## Silent failure 2: ContainerLog stops filling

For AKS clusters on Container insights, the documentation says support for the ContainerLog table retires on 30 September and "after that date, the legacy table stops receiving data." Your clusters keep logging. The logs just land somewhere your queries, workbooks and alert rules don't look.

Newer clusters are probably fine: ContainerLogV2 is the default for clusters onboarded with CLI 2.54.0 or later and for anyone using managed identity authentication. The risk sits in older clusters onboarded with the legacy agent, and in the alert rules that were written against ContainerLog years ago and copied into every new cluster since. Microsoft's guide ships a Resource Graph query that lists enabled scheduled query rules whose definition mentions ContainerLog. Run it before you flip anything. Note that the string match also catches rules already on ContainerLogV2, so read the results rather than bulk-editing them.

Switching is a setting, either in the cluster's log profile or in the ConfigMap. The documentation is careful to say this setting "does not control whether data is collected or not. It only specifies which table the data is sent to." The query rewrite is the real work, because the schemas differ. The log line lives in `LogMessage` in V2, and V2 adds `PodName`, `PodNamespace`, `ContainerName` and a `LogLevel` column directly, which removes most of the joins against inventory tables that V1 queries needed:

```
// ContainerLogV2: errors per namespace, no inventory join needed
ContainerLogV2
| where TimeGenerated > ago(1h)
| where LogLevel in ("CRITICAL", "ERROR")
| summarize errors = count() by PodNamespace, PodName
| order by errors desc
```

Microsoft notes that `LogLevel` is inferred by keyword matching when the message isn't JSON with a `level` key, and "might result in some misclassifications." Test your error alerts against a known-bad deployment before trusting them.

### A migration that can cut your bill

ContainerLog only works with full-priced Analytics logs. ContainerLogV2 also supports the Basic Logs plan. In Sweden Central the retail prices are USD 2.99 per GB for Analytics ingestion against USD 0.645 per GB for Basic. For a cluster estate writing 100 GB of container logs a month, that is about USD 299 versus USD 65 before free allowances and commitment tiers. Basic Logs has real trade-offs: you pay per GB scanned when you query, retention and query features are more limited, and the Kubernetes metadata Grafana dashboard does not support it. For high-volume application chatter that is read only during incidents, those trade-offs are usually worth it. Keep security-relevant logs on Analytics.

## The loud ones: fix these this week

### Functions v3 on Linux Consumption

The Functions runtime documentation states that apps "still running the end-of-life v3 runtime on Linux in a Consumption plan stop running after September 30, 2026." This is the only runtime retirement this month that actually switches apps off. Version 2.x and 3.x apps on other plans keep running without support, and so do 1.x apps after the 14 September end of support. The runtime version is an app setting, so list it across your apps:

```
az functionapp list --query "[].{name:name, rg:resourceGroup, kind:kind}" -o tsv |
while IFS=$'\t' read -r name rg kind; do
  ver=$(az functionapp config appsettings list -n "$name" -g "$rg" \
    --query "[?name=='FUNCTIONS_EXTENSION_VERSION'].value" -o tsv)
  echo -e "$ver\t$kind\t$rg/$name"
done | sort
```

Anything showing `~3` with `linux` in the kind needs its hosting plan checked, and if the plan is Consumption, it needs the v4 migration now. Don't just change the setting: Microsoft's guidance is explicit that other settings and code often have to change too. For .NET apps, note a second deadline stacked behind this one. The in-process model ends support on 10 November 2026, the same day as .NET 8, so a v3 in-process app should go straight to v4 on the isolated worker model rather than migrating twice.

While you are in there: Linux Consumption itself is retiring on 30 September 2028 and gets no new language versions, and Microsoft points to Flex Consumption as the destination. If a v3 app has to be touched anyway, it is cheaper to land it on Flex once than to move it twice.

### Service Bus: SBMP and the legacy SDKs

Two things happen on 30 September. Microsoft retires the `WindowsAzure.ServiceBus`, `Microsoft.Azure.ServiceBus` and `com.microsoft.azure.servicebus` libraries, and it ends support for the SBMP protocol, "so you'll no longer be able to use this protocol after 30 September 2026." The libraries themselves keep working over AMQP, unsupported. SBMP is the hard stop.

The trap is `WindowsAzure.ServiceBus`, the old .NET Framework package, which can talk SBMP. Code that has run untouched on an on-premises server since 2017 is the most likely place to find it. Search for all three package names, and include transitive dependencies, because the legacy client can arrive inside an older internal library or integration component rather than as a direct reference:

```
# .NET SDK-style projects, direct and transitive
dotnet list package --include-transitive | grep -iE "WindowsAzure.ServiceBus|Microsoft.Azure.ServiceBus"

# Older projects and Java
grep -rIl --include=packages.config --include=*.csproj --include=pom.xml \
  -E "WindowsAzure.ServiceBus|Microsoft.Azure.ServiceBus|com.microsoft.azure.servicebus|azure-servicebus" .
```

The replacements are `Azure.Messaging.ServiceBus` for .NET and `com.azure:azure-messaging-servicebus` for Java. The API surface is different enough that this is a code change with tests, not a package bump. If you cannot migrate a component in time, at minimum make sure it is configured for AMQP rather than SBMP so it keeps running unsupported while you do.

### Azure Virtual Desktop (classic) and Azure API for FHIR

Both have been announced for years, and new deployments have been blocked for a long time (new AVD classic tenants since September 2023, new Azure API for FHIR deployments since April 2025). If you still have either, you already know the migration is large. What you need this week is a written fallback: which users or integrations lose service on 1 October, who tells them, and what the manual workaround is. For FHIR, the target is the Azure Health Data Services FHIR service, and Microsoft publishes migration strategies for it.

### 1 October: three AI services

Anomaly Detector, Metrics Advisor and Personalizer all retire on 1 October 2026. New Anomaly Detector resources could not be created after 20 September 2023, so anything still calling it is old code. Microsoft points Anomaly Detector users to anomaly detection in Microsoft Fabric Real-Time Intelligence or the open-source `microsoft/anomaly-detector` package. For Metrics Advisor and Personalizer, follow the retirement notices linked from the lifecycle page, and budget for a redesign rather than a lift-and-shift: neither has a drop-in successor named on that page.

## The two that already passed

The HTTP Data Collector API retired on 14 September, but ingestion continues for clients using TLS 1.2 or later, with only critical security fixes from now on. The endpoint stopped accepting older TLS on 1 March 2026, so if a custom log source went quiet in March, that is the likely reason. Microsoft's guide lists the column suffixes (`_s`, `_d`, `_t`) that mark tables created by the legacy API, and an `az monitor log-analytics workspace table list` filter for tables whose sub-type is Classic.

The replacement, the Logs Ingestion API, is better in every way that matters (Entra authentication, transformations, schema control) but plan for two behaviour changes. It accepts 1 MB per call where the old API took 30 MB, so batch senders need to split payloads. It also no longer adds columns automatically when the source schema changes, so a new field in your data is dropped until you update the table and the data collection rule. Microsoft Sentinel customers should check their connectors too: Microsoft is moving Sentinel connectors that used the Data Collector API to Codeless Connector Framework connectors, which can bring new table names that analytics rules and workbooks must follow.

Functions 1.x apps also keep running after the 14 September end of support. Nothing will stop them next week. They will simply receive no fixes, which matters most for the question in the next section.

## The Swedish and EU angle

For Swedish organisations in scope of NIS2 through the Swedish cybersecurity act (cybersäkerhetslagen), and for anyone processing personal data under GDPR Article 32, "unsupported but still running" is not a neutral state. Both frameworks expect appropriate technical measures, and running components that no longer receive security fixes is hard to defend as appropriate once you knew the date. The soft retirements belong on the risk register with an owner and a target date, even if nothing is switched off.

The silent failures matter more under NIS2, because its incident reporting runs on detection. An organisation that loses its availability tests or its container logs on 30 September has a shorter window to notice an incident and less evidence to report on afterwards. A gap in ContainerLog data during an incident is exactly the kind of thing that gets asked about later.

Two practical points for Swedish teams. First, 30 September falls on a Wednesday in week 40, the last day of Q3, when many finance and operations teams have change freezes around quarter close. If yours does, the effective deadline for production changes may be this coming week. Second, if procurement needs a quote in SEK, start from the Sweden Central rate above rather than US list prices: Central US is USD 0.00056 per execution, about 13 percent lower, and a quote built on it will undershoot.

For health-sector organisations still on Azure API for FHIR, including suppliers to the regions, confirm that the replacement FHIR service is deployed in the same EU region and that your data processing agreement covers the new resource before any data moves.

## The eleven-day checklist

1. **Today:** run the Resource Graph query for ping tests across all subscriptions and the one for alert rules referencing ContainerLog. These are the silent failures; know their size first.
2. **Get the budget approved** for standard web tests using the per-test table above. Cut frequency on low-value endpoints before asking.
3. **Migrate ping tests** with Microsoft's script, enable the TLS certificate check, repoint alert rules, then delete the ping tests.
4. **Switch older AKS clusters to ContainerLogV2** after rewriting the affected alert queries, and test them against a deliberately failing pod.
5. **List Functions runtime versions** with the loop above. Move any v3 app on Linux Consumption to v4 now, preferably onto Flex Consumption and the isolated worker model in one step.
6. **Search every repository** for the three legacy Service Bus package names, including transitive references. Anything using SBMP is an outage on 1 October.
7. **Check for Anomaly Detector, Metrics Advisor and Personalizer resources** and the code that calls them.
8. **Write a fallback note** for anything that will not make the date: who is affected, who tells them, what the workaround is.
9. **Put the soft retirements on the risk register** (Functions 1.x, Data Collector API, legacy Service Bus SDKs over AMQP) with an owner and a target quarter.
10. **Look ahead to 10 November**, when the Functions in-process model, .NET 8 and .NET 9 all reach end of support on the same day.

If you migrated off the Assistants API last month using our [Foundry Agents migration guide](/en/blog/assistants-api-is-gone-a-step-by-step-migration), the pattern here is the same: inventory first, migrate the things that fail silently before the things that fail loudly, and keep the old path alive until the new one has reported for a day.

## Sources

- [Microsoft Lifecycle: Ending support in 2026 (retirement dates for all items listed)](https://learn.microsoft.com/en-us/lifecycle/end-of-support/end-of-support-2026)
- [Microsoft Learn: Application Insights availability tests (URL ping test removal, migration script, standard test charges)](https://learn.microsoft.com/en-us/azure/azure-monitor/app/availability)
- [Microsoft Learn: Configure the ContainerLogV2 schema (ContainerLog retirement, Basic Logs support, alert rule query)](https://learn.microsoft.com/en-us/azure/azure-monitor/containers/container-insights-logs-schema)
- [Microsoft Learn: Azure Functions runtime versions (1.x end of support, v3 on Linux Consumption, in-process model date)](https://learn.microsoft.com/en-us/azure/azure-functions/functions-versions)
- [Microsoft Learn: Migrate apps from Azure Functions version 1.x to 4.x](https://learn.microsoft.com/en-us/azure/azure-functions/migrate-version-1-version-4)
- [Microsoft Learn: Azure Service Bus FAQ (legacy SDK and SBMP retirement statement)](https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-faq)
- [Microsoft Learn: Migrate from the HTTP Data Collector API to the Logs Ingestion API](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/custom-logs-migrate)
- [Microsoft Learn: Azure Virtual Desktop (classic) retirement](https://learn.microsoft.com/en-us/previous-versions/azure/virtual-desktop-classic/classic-retirement)
- [Microsoft Learn: What is Azure API for FHIR? (retirement notice and migration strategies)](https://learn.microsoft.com/en-us/azure/healthcare-apis/azure-api-for-fhir/overview)
- [Microsoft Learn: What is Anomaly Detector? (1 October 2026 retirement and alternatives)](https://learn.microsoft.com/en-us/azure/ai-services/anomaly-detector/overview)
- [Azure Retail Prices API: Standard Web Test Execution, Sweden Central](https://prices.azure.com/api/retail/prices?$filter=armRegionName%20eq%20)
- [Azure Retail Prices API: Log Analytics ingestion meters, Sweden Central](https://prices.azure.com/api/retail/prices?$filter=armRegionName%20eq%20)

---

Technspire AB builds AI agents, Azure OpenAI solutions, and production web platforms for Swedish and EU enterprises. Book a call: https://calendly.com/technspire · hello@technspire.com · More articles: https://technspire.com/en/blog · Site overview for agents: https://technspire.com/llms.txt