Azure Monitor Data Collector API Support Ends September 14, 2026

Azure Monitor’s legacy HTTP Data Collector API reaches end of support on September 14, 2026, but the urgent task is not upgrading the Azure Monitor Agent. It is finding every PowerShell script, scheduled task, IIS application, SQL job, Windows service, and line-of-business executable that still posts directly to Log Analytics with a workspace ID and shared key.
Microsoft Learn now clarifies that TLS 1.2-compliant senders are not scheduled to stop ingesting on September 14. Existing ingestion continues, but the API becomes an unsupported operational dependency receiving only critical security fixes. Clients unable to negotiate TLS 1.2 or later have faced the harder deadline already: the endpoint began rejecting legacy TLS on March 1, 2026.

Hunt for the Request Pattern, Not an Installed Agent​

The Data Collector API can be buried in ordinary Windows automation with no recognizable monitoring agent to inventory. A script copied into C:\Scripts, an IIS-hosted internal application, a SQL Server Agent PowerShell step, or a vendor executable may construct and sign its own HTTPS request.
Start by searching likely script and configuration locations for the legacy endpoint, headers, and signing vocabulary. This PowerShell example scans text-based files while avoiding access errors:

$Roots = @(
    'C:\Scripts',
    'C:\ProgramData',
    'C:\inetpub',
    'C:\Windows\System32\Tasks'
)

$Patterns = @(
    'ods\.opinsights\.azure\.com',
    'api/logs',
    'Log-Type',
    'x-ms-date',
    'Authorization:\s*SharedKey',
    'SharedKey',
    'HMAC',
    'workspaceId',
    'workspaceKey'
)

Get-ChildItem -Path $Roots -Recurse -File -ErrorAction SilentlyContinue |
    Where-Object {
        $_.Extension -in '.ps1', '.psm1', '.psd1', '.config',
                         '.json', '.xml', '.cmd', '.bat',
                         '.cs', '.vb', '.js'
    } |
    Select-String -Pattern $Patterns -AllMatches -ErrorAction SilentlyContinue |
    Select-Object Path, LineNumber, Line

Treat those patterns as discovery indicators, not proof by themselves. HMAC or SharedKey can appear in unrelated authentication code, while an obfuscated or compiled integration may contain none of the obvious strings in a searchable configuration file.
Next, enumerate scheduled tasks and inspect their actions rather than searching only task names:

Get-ScheduledTask | ForEach-Object {
    $Task = $_

    foreach ($Action in $Task.Actions) {
        [pscustomobject]@{
            TaskPath  = $Task.TaskPath
            TaskName  = $Task.TaskName
            Execute   = $Action.Execute
            Arguments = $Action.Arguments
        }
    }
} | Where-Object {
    $_.Execute -match 'powershell|pwsh|cmd|cscript|wscript' -or
    $_.Arguments -match 'ps1|opinsights|api/logs|SharedKey'
}

A task may invoke a generic wrapper whose Azure Monitor logic sits several files away. Follow every script path, module import, configuration argument, and network utility referenced by the task action.
Windows services deserve the same treatment. The service executable may be a custom collector, or its command line may point to an application directory containing the real configuration:

Get-CimInstance Win32_Service |
    Select-Object Name, DisplayName, State, StartName, PathName |
    Where-Object {
        $_.PathName -match 'powershell|pwsh|cmd|script|collector|monitor|log'
    }

Do not limit the review to matches returned by that filter. Use the complete service inventory to identify unfamiliar in-house and third-party programs, then inspect their installation folders for endpoint strings, workspace identifiers, and shared-key configuration.

IIS and SQL Can Hide the Last Legacy Senders​

IIS applications are especially easy to miss because the sending code may run under an application pool identity and look like normal outbound HTTPS traffic. Search application directories under C:\inetpub, deployment folders outside the default web root, and configuration files associated with each site and application.
Compiled applications require more than a text search. Check adjacent .config, JSON, XML, environment, and deployment files first. If the endpoint or key is embedded in a binary, application ownership records and outbound network observations may be more useful than repeatedly scanning source extensions that are not present on the server.
SQL Server also creates several hiding places: SQL Server Agent jobs, PowerShell steps, command-line steps, integration packages, and stored procedures that invoke external code. Export or inspect job definitions and search their commands for the same endpoint, header, and signing patterns.
The distinction matters because replacing Microsoft Monitoring Agent-era collection is not the same project as replacing custom HTTP posts. Microsoft says tables shown as Custom table (classic) can include both Data Collector API destinations and tables populated through the legacy Log Analytics agent. Administrators must identify which sender actually writes to each table before converting it, or they risk treating two migration paths as one.

---

Map Shared-Key Code to the DCR Ingestion Model​

Legacy code commonly follows a recognizable sequence: serialize JSON, calculate content length, create an x-ms-date value, build a string to sign, calculate an HMAC using the workspace shared key, and send an Authorization: SharedKey header to a workspace-specific ods.opinsights.azure.com URL containing api/logs. A Log-Type header selects the destination custom log type.
The Logs Ingestion API changes that contract rather than merely changing the hostname. The replacement request uses a DCR or DCE ingestion endpoint, the DCR’s immutable ID, and a stream name. Authentication uses a Microsoft Entra bearer token instead of a Log Analytics workspace shared key and custom HMAC calculation.
That creates a practical code-review map:

• Remove storage and retrieval of the workspace shared key.
• Remove the custom HMAC string-to-sign and signature-generation functions.
• Replace the legacy workspace endpoint and api/logs URI construction.
• Obtain a Microsoft Entra token and send it as bearer-token authorization.
• Address the correct DCR immutable ID and stream name through the configured ingestion endpoint.
• Ensure the JSON payload conforms to the input schema expected by the DCR.
• Move required filtering, routing, or reshaping into the DCR transformation where appropriate.

This is why an Azure Monitor Agent deployment report cannot prove that the estate is ready. The agent may be current on every server while a five-year-old scheduled task continues to sign Data Collector API requests independently.

Dual-Write Before Removing the Old Path​

Migration validation should measure data behavior, not settle for a successful HTTP response. Where the sender can support it safely, run the legacy and Logs Ingestion paths in parallel long enough to compare representative operating conditions.
Use a separate destination during testing when that makes query comparison and rollback clearer. Microsoft’s migration guidance presents side-by-side implementation as the preferred option when changes to an existing table may be needed, while warning that direct conversion of a table is not reversible.
Validation should cover:

1. Compare record counts and expected fields over matching time windows.
2. Check timestamp handling and confirm events arrive in the intended table.
3. Exercise large and bursty payloads rather than testing only one sample record.
4. Review transformation results for dropped, empty, or incorrectly typed fields.
5. Compare alerts, workbooks, dashboards, and queries that depend on the data.
6. Monitor ingestion volume and cost during dual-write so duplicated telemetry does not become an unnoticed permanent expense.
7. Retain a controlled rollback path until the new sender remains stable through normal and peak workloads.

Schema behavior needs particular attention. The DCR defines the incoming stream and can transform it for the destination table; it is not simply a new transport for every assumption embedded in the old script. A request can authenticate correctly yet still produce missing or unusable fields if its payload and stream definition do not align.
WindowsForum’s previous coverage of Azure Monitor Agent and DCR logging changes has emphasized the risk of cloud visibility shifting underneath SOC detections. This retirement creates a related failure mode: a legacy sender can remain operational today while its ownership, authentication model, and recovery path quietly decay after support ends.

---

September 14 Is a Support Boundary, Not Permission to Wait​

The revised timeline removes the assumption of a confirmed ingestion shutoff for compliant clients, but it does not make the dependency safe. After September 14, 2026, Microsoft promises only critical security fixes for the Data Collector API, leaving organizations exposed to future platform changes without normal support coverage.
The March 1 TLS cutoff also provides a useful diagnostic clue. If an expected custom table stopped receiving data around that date, investigate the sender’s TLS capabilities before blaming DCRs, Azure Monitor Agent, or table conversion. A client incapable of negotiating TLS 1.2 or later is already outside the functioning legacy path.
The inventory should therefore end with ownership, not just a spreadsheet of matches. Every discovered sender needs a responsible team, execution identity, source location, destination table, workspace-key dependency, migration status, and validation plan. Shared keys found in scripts or configuration also need to be treated as credentials, without copying their values into general-purpose discovery reports.
September 14 does not guarantee that a TLS 1.2 sender will suddenly go dark. It guarantees something operationally uncomfortable enough: any forgotten PowerShell script, IIS component, SQL job, or business application still using Authorization: SharedKey will be running on an API whose normal support lifecycle has ended.

---

References​

1. Primary source: learn.microsoft.com
   
   

   HTTP Data Collector API - Hard Stop or End Support - Microsoft Q&A

   I'm trying to clarify if the HTTP Data Collector API feature that is being deprecated will stop working completely on 14 September 2026, or if only support will end. The learn page says support ends:…

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Azure Monitor Agent DCR logging changes: SOC blind spots and detection updates | Windows Forum

   Vectra AI’s warning about Azure logging is more than another vendor alert; it is a reminder that cloud visibility can change when the platform underneath it...

   windowsforum.com

 

[ChatGPT]

Azure Monitor’s HTTP Data Collector API reaches end of support on September 14, 2026, but that date is not a confirmed hard ingestion cutoff for clients using TLS 1.2 or later, according to a Microsoft Q&A response attributed to the Azure Monitor backend team. It remains the support-end date, so critical workloads should be discovered, assigned, migrated, and validated before then rather than depending on an unsupported endpoint that happens to keep responding.
The immediate task is not an Azure Monitor Agent upgrade. As WindowsForum users have reported, the difficult part is finding every PowerShell script, scheduled task, IIS application, SQL Server Agent job, runbook, function, appliance, and custom application that sends records through the legacy API.
That distinction matters because Microsoft’s public wording has created understandable confusion. In the cited Microsoft Q&A discussion, a moderator relayed the backend team’s position that TLS 1.2 ingestion would continue and that September 14 would not be a hard stop. The same Q&A response—not Microsoft Learn migration documentation—said the retired API would lack post-retirement SLA coverage and would receive only critical security fixes.
Those statements provide some scheduling context, but they do not make continued production use safe. “Still responding” and “supported” are different operating states.

Treat This as Retirement Triage​

This article focuses on retirement triage: identifying the senders, establishing ownership, classifying Microsoft Sentinel integrations, and proving that replacement ingestion works before the old path is disabled. The exact implementation of a replacement depends on the source, destination, and connector model, so teams should use Microsoft’s current Logs Ingestion API setup documentation or the applicable Sentinel connector documentation when building the replacement.
Do not start by rewriting the first script someone happens to remember. First build a dependency register that shows the full scope of the retirement.
WindowsForum’s earlier Data Collector API report made the sender the center of the investigation. That remains the most useful operational model. Azure may present an affected workspace or service recommendation, but the migration unit is usually the script, application, job, connector, or product that constructs and submits the request.
This resembles the dependency-register approach WindowsForum users have applied to other Microsoft retirements, including Azure AD Graph, Microsoft 365 components, and Azure Anomaly Detector. A retirement date identifies urgency; it does not identify every hidden dependency or the team responsible for fixing it.

Start With Azure Advisor, but Do Not Stop There​

Open the Azure portal and go to Azure Advisor > Reliability > Service Upgrade and Retirement. Review the identified resources and export the results so they can be tracked outside the portal.
Microsoft says Service Upgrade and Retirement recommendations are available through Advisor and other Azure management surfaces. Its description also indicates that the recommendations form a broader set than retirement updates alone. That makes Advisor a useful starting point, but not a self-sufficient inventory.
Treating Advisor as incomplete is an operational inference rather than a claim that Microsoft documents a specific coverage gap. An Azure recommendation cannot be expected to identify every relevant script stored in source control, every scheduled task on an on-premises server, or every credential reference embedded in a customer-managed application. Those systems must be inspected directly.
For each resource exported from Advisor, identify the associated workspace, operational owner, application owner, and likely data sources. Then search beyond Azure.
Useful places to inspect include:

• PowerShell and other script repositories
• Windows Task Scheduler on known automation servers
• Azure Automation runbooks
• Azure Functions and application configuration
• IIS applications and services
• SQL Server Agent jobs
• Deployment packages and release pipelines
• Credential stores and configuration databases
• Monitoring appliances and third-party products
• On-premises servers that send logs to Azure
• Internal documentation for custom Log Analytics integrations

Search for references to the relevant workspace, ingestion destination, legacy request code, stored credentials, or internal wrapper libraries used to submit monitoring data. A shared library is especially important because one implementation may support several applications.
Do not limit the search to systems represented as Azure resources. WindowsForum user reports repeatedly highlight scheduled tasks, scripts, and locally hosted applications because these are precisely the dependencies that calendar-driven retirement projects tend to overlook.

Build a Sender-Level Dependency Register​

Create one record for every confirmed or suspected sender. At minimum, capture:

• Sender name and hosting location
• Technical owner and business owner
• Destination workspace and table
• Execution schedule or triggering event
• Business purpose
• Business impact if ingestion stops
• Whether the data supports security monitoring, audit, or compliance
• Downstream alerts, dashboards, queries, reports, and automations
• Current migration status
• Replacement documentation being followed
• Test evidence and planned cutover date

Record uncertainty rather than silently discarding it. An unknown owner, unexplained table, or inaccessible server is a migration risk that needs escalation.
Prioritize by consequence, not merely by implementation effort. Security detections, incident-response feeds, audit trails, and regulated records should be addressed first. Business-critical application telemetry should follow, particularly when alerts or operational decisions depend on timely arrival.
Shared automation also deserves early attention because one change may affect several teams. Low-value diagnostics can be scheduled later when they have a known owner and documented risk acceptance. Orphaned integrations should be investigated before migration; a retirement project should not reproduce an unused feed simply because it exists.

Classify Microsoft Sentinel Integrations by Ownership​

Microsoft Sentinel requires a separate review because not every data source is implemented or maintained by the customer.
Use the Microsoft Sentinel connector catalog and the documentation for the specific product to determine which supported path applies. Classify each source as one of the following:

• An out-of-box connector
• A documented Syslog, Common Event Format, or REST path
• A custom integration that the customer must redesign

Do not assume that a custom script should be migrated in the same way as a supported connector. Conversely, do not assume that enabling or updating an agent will repair customer-owned code that directly calls the retiring API.
The connector catalog is the appropriate source for determining connector ownership and the documented ingestion path. The classification should then be recorded in the dependency register, together with the team responsible for the change.
For Sentinel data, transport success is not enough. After implementing the documented replacement, validate that the expected events arrive and that the downstream security content still works. Check the analytics rules, hunting queries, workbooks, parsers, playbooks, and other processes that consume the data.
Avoid declaring success after seeing a single sample event. Security operations depend on usable records arriving consistently and being recognized by detections.

Validate Before Cutover​

Where practical, run the old and replacement paths in parallel for a controlled validation period. The duration should reflect the sender’s normal schedule. A job that runs once per day cannot be validated from a five-minute test.
Compare:

• Expected and observed record arrival
• Record counts over equivalent periods
• Required field population
• Event timestamps
• Query results
• Alert and detection behavior
• Dashboard and workbook output
• Downstream automation
• Failure and retry handling observed during testing

Keep evidence of the test. Screenshots alone are often insufficient; record the test window, sender version, destination, queries used, expected result, actual result, and approver.
Before disabling the old sender, obtain confirmation from both the technical owner and the owner of the consuming workload. A platform team may be able to prove that data arrived, but the security or application team must confirm that it remains operationally useful.
After cutover, continue monitoring actual data arrival. A successful submission response is not the same as proof that the required records reached their destination in a usable form.

September 14 Is a Risk Boundary​

The cited Microsoft Q&A/backend-team response means administrators should not present September 14, 2026, as a proven universal shutdown time for TLS 1.2 or later clients. That would overstate the available evidence.
It is equally misleading to treat the clarification as permission to postpone migration. The same response describes a post-retirement condition without normal SLA coverage and with only critical security fixes. Those are Q&A statements attributed to the backend team, not guarantees of indefinite operation.
For a critical workload, the practical deadline is therefore earlier than the point at which requests begin failing. Migration needs enough time for discovery, implementation under the applicable Microsoft documentation, parallel validation, downstream testing, approval, and rollback planning.
Waiting for failure lets future platform behavior choose the maintenance window. It also leaves less time to investigate silent data loss, which can be more damaging than an obvious outage.

Concise Action Checklist​

• Open Azure Advisor > Reliability > Service Upgrade and Retirement.
• Export the identified resources and place them in a tracked dependency register.
• Inspect every known sender outside Azure, including scripts, scheduled tasks, applications, jobs, appliances, and configuration stores.
• Use Microsoft Sentinel connector documentation to classify each source as an out-of-box connector, a documented Syslog/CEF/REST path, or a customer-owned custom integration.
• Assign a technical owner, business owner, and business-impact rating to every sender.
• Follow Microsoft’s current setup documentation for the applicable replacement path.
• Validate data arrival and downstream detections, queries, dashboards, and automations before cutover.
• Monitor actual record arrival after cutover before retiring the legacy sender.

Frequently Asked Questions​

Will the HTTP Data Collector API definitely stop ingesting data on September 14, 2026?​

That is not confirmed for clients using TLS 1.2 or later. A Microsoft Q&A moderator, citing the Azure Monitor backend team, said the date would not be a hard stop for that ingestion. September 14 remains the end-of-support date, however, so critical workloads should migrate before it.

Can we wait if our requests still succeed after the retirement date?​

That is a business-risk decision, not evidence that the API remains supported. The cited Q&A response says there is no post-retirement SLA coverage and that only critical security fixes continue. Successful requests should not be treated as a long-term operating guarantee.

Is upgrading Azure Monitor Agent the fix?​

Not for customer-owned code that directly submits requests through the HTTP Data Collector API. WindowsForum user reports emphasize that the urgent work is finding scripts, scheduled tasks, jobs, applications, and other senders. Each sender must be classified and moved through its applicable documented replacement path.

Is Azure Advisor a complete inventory?​

Use it as the first discovery step, but verify every known sender independently. The conclusion that Advisor cannot expose all off-Azure code and configuration is an operational inference: a portal recommendation does not inspect every on-premises scheduled task, private repository, or application configuration store.

How should we handle Microsoft Sentinel sources?​

Use the Sentinel connector catalog and the source-specific documentation to determine whether the integration uses an out-of-box connector, a documented Syslog/CEF/REST path, or customer-owned code requiring redesign. Then validate both record arrival and downstream detections before cutover.

What should be migrated first?​

Prioritize security, incident response, audit, compliance, and business-critical telemetry. Shared senders and poorly understood integrations should also be addressed early because they can expose multiple dependencies or require additional ownership work.

---

References​

1. Primary source: learn.microsoft.com
   
   

   HTTP Data Collector API - Hard Stop or End Support - Microsoft Q&A

   I'm trying to clarify if the HTTP Data Collector API feature that is being deprecated will stop working completely on 14 September 2026, or if only support will end. The learn page says support ends:…

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Azure Monitor Data Collector API Support Ends September 14, 2026 | Windows Forum

   Azure Monitor’s legacy HTTP Data Collector API reaches end of support on September 14, 2026, but the urgent task is not upgrading the Azure Monitor Agent...

   windowsforum.com