diff --git a/.config/dotnet-tools.json b/.config/dotnet-tools.json
new file mode 100644
index 00000000000..5f56247a879
--- /dev/null
+++ b/.config/dotnet-tools.json
@@ -0,0 +1,12 @@
+{
+  "version": 1,
+  "isRoot": true,
+  "tools": {
+    "microsoft.dotnet.helix.jobmonitor": {
+      "version": "11.0.0-beta.26458.103",
+      "commands": [
+        "dotnet-helix-job-monitor"
+      ]
+    }
+  }
+}
diff --git a/azure-pipelines.yml b/azure-pipelines.yml
index 4cd188a6a74..9a4cdcf2bac 100644
--- a/azure-pipelines.yml
+++ b/azure-pipelines.yml
@@ -12,6 +12,18 @@ parameters:
   type: boolean
   default: false
 
+variables:
+  # This entrypoint has one implicit stage. Keep asynchronous sends paired with its monitor.
+  - name: EnableHelixJobMonitor
+    value: true
+  # Matrix legs share a phase and queue. Keep their monitor identities distinct across channels.
+  - name: TestRunNamePrefix
+    value: '$(Agent.JobName)_'
+  - template: /eng/common/templates/variables/pool-providers.yml
+  - ${{ if eq(variables['System.TeamProject'], 'internal') }}:
+    # The standalone monitor does not inherit the submitter jobs' variable groups.
+    - group: DotNet-HelixApi-Access
+
 resources:
   containers:
     - container: ubuntu_x64_build_container
@@ -67,3 +79,9 @@ jobs:
       jobParameters:
         ${{ if parameters.onlySanityCheck }}:
           onlySanityCheck: true
+
+  - template: /eng/common/core-templates/job/helix-job-monitor.yml
+    parameters:
+      timeoutInMinutes: 360
+      helixAccessToken: $(HelixApiAccessToken)
+      allowNoHelixJobs: false
diff --git a/docs/sdk-scenarios.md b/docs/sdk-scenarios.md
index 12e2c952289..c09f165f198 100644
--- a/docs/sdk-scenarios.md
+++ b/docs/sdk-scenarios.md
@@ -4,6 +4,49 @@ An introduction of how to run scenario tests can be found in [Scenarios Tests Gu
 
 - [SDK Build Throughput Scenario](#sdk-build-throughput-scenario)
 
+## SDK performance pipeline
+
+The repository's [azure-pipelines.yml](../azure-pipelines.yml) entrypoint uses
+[sdk-perf-jobs.yml](../eng/pipelines/sdk-perf-jobs.yml) for SDK-based scenario and
+benchmark jobs. It backs the internal `dotnet-performance` pipeline (definition 306)
+and the public `performance-ci` pipeline (definition 38).
+
+The entrypoint always enables asynchronous submission and includes the standalone
+Helix Job Monitor, its pool provider, and its parameters, including on public and PR
+runs. The monitor runs alongside submitters in the same implicit stage, waits for
+their Helix work items, and reports failures to Azure DevOps. The existing manual
+job-selection parameters and schedules are unchanged: public runs always select
+correctness jobs. Internal manual runs must select workloads; leaving all three
+job-selection flags false still includes the monitor and fails because no Helix jobs
+were submitted (`allowNoHelixJobs: false`). Submitter and work-item failures also
+continue to fail the run.
+
+The monitor job has a six-hour timeout (355 minutes for the tool, leaving five minutes
+for it to exit). Existing 320-minute submitter limits and Helix work-item timeouts are
+unchanged. These limits start when the respective job runs; they are not a whole-run
+wall-clock deadline that includes time waiting for agents.
+
+Internal runs, including internal PR runs, import `DotNet-HelixApi-Access`. The
+monitor forwards `$(HelixApiAccessToken)` directly, matching the shared pipeline
+convention. Internal runs use the imported credential. Public runs, including public
+PR runs, do not import that group and use public Helix access. Direct forwarding
+does not change how Azure DevOps expands variables or how the SDK handles tokens.
+Azure DevOps timeline access and result reporting still use the job's
+`System.AccessToken`. The tool is restored from
+`.config/dotnet-tools.json` in its own checkout; `eng/Version.Details.xml` tracks that
+pin alongside the Helix SDK.
+
+Monitor test-run names include the matrix-expanded job display name. This keeps
+different channels in the same phase and Helix queue independent while preserving a
+stable identity when the same leg is retried.
+
+Submitter build logs still use the existing `Logs_*` pipeline artifacts. Benchmark
+results and diagnostics are still uploaded from the Helix work items to PerfLab and
+Helix, respectively. The monitor reports test results and links to Helix consoles; it
+does not download arbitrary Helix uploads into pipeline artifacts. Asynchronous sends
+skip the submitter's `artifacts/helix-results` downloads, which were not published by
+this pipeline. Local `--send-to-helix` runs still wait and download performance reports.
+
 ## SDK Build Throughput Scenario
 
 **SDK Build Throughput** is a scenario test that measures the throughput of SDK build process. To be more specific, our test *implicitly calls*
diff --git a/eng/Version.Details.xml b/eng/Version.Details.xml
index 37c4f335c2a..40f2fd8843c 100644
--- a/eng/Version.Details.xml
+++ b/eng/Version.Details.xml
@@ -35,6 +35,10 @@
       <Uri>https://github.com/dotnet/dotnet</Uri>
       <Sha>bcd0a2de8927de44b65f3ad41bef8820ee2b3d0b</Sha>
     </Dependency>
+    <Dependency Name="Microsoft.DotNet.Helix.JobMonitor" Version="11.0.0-beta.26458.103">
+      <Uri>https://github.com/dotnet/dotnet</Uri>
+      <Sha>bcd0a2de8927de44b65f3ad41bef8820ee2b3d0b</Sha>
+    </Dependency>
     <Dependency Name="Microsoft.DotNet.XHarness.CLI" Version="11.0.0-prerelease.26458.2">
       <Uri>https://github.com/dotnet/xharness</Uri>
       <Sha>1665037768fd7eec44e046d94fd07b8c6407c966</Sha>
diff --git a/eng/common/dotnet.sh b/eng/common/dotnet.sh
old mode 100644
new mode 100755