Fix Azure Playwright Testing Setup & Config Errors
Why This Is Happening
I've watched a lot of developers hit a wall with Azure Playwright Testing , and the frustration is real. You've got a working local Playwright test suite, you spin up a workspace in the Azure portal, paste in a service endpoint, and suddenly nothing connects. Or your CI pipeline that ran fine last week throws a cryptic auth error. Or you're burning through your free trial minutes faster than expected because parallelization isn't configured correctly. Sound familiar?
Here's the core thing you need to know right now, before anything else: Microsoft Playwright Testing Preview is being retired on March 8, 2026. If you're reading this and haven't migrated yet, that's almost certainly why things aren't working, the old workspace endpoints are either already shut down or in wind-down mode. Microsoft has moved the service to Azure App Testing, which is now generally available. The migration path exists, but it's not automatic. You have to create a new workspace there manually.
But even before the retirement deadline, Azure Playwright Testing gave developers grief in four main areas. First, workspace provisioning, getting the right Azure subscription roles assigned and the workspace correctly configured in the right region. Second, access tokens, the service uses its own token system for authenticating your test runner against the cloud browsers, separate from your Azure AD credentials, and mixing these up causes silent failures. Third, service endpoint misconfiguration, pointing your playwright.config.ts at the wrong URL or using a stale endpoint after workspace recreation. Fourth, CI/CD integration, GitHub Actions and Azure Pipelines both need specific environment variable patterns to pick up the service endpoint correctly, and small typos here produce errors that look completely unrelated to Playwright.
Microsoft's error messages in this space are, let's be honest, not great. A failed connection attempt during test execution often just surfaces as a generic timeout or a "browser not launched" Playwright error, nothing that points you back to the service configuration. The Azure portal doesn't always surface workspace health status clearly either. That disconnect between where the problem actually is and where the error appears is what makes Azure Playwright Testing issues so maddening to debug.
The fixes are all very doable. You don't need to rewrite your tests. You just need to know which layer is broken, authentication, workspace, endpoint, or CI environment, and address that layer specifically. This guide walks through each one. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If your Azure Playwright Testing setup stopped working recently and you haven't changed anything, the retirement is almost certainly the culprit. The fastest path forward is migrating to Azure App Testing. Here's what you do.
Open the Azure portal and search for "App Testing" in the top search bar. Select App Testing from the results, this is the generally available replacement service. Click Create and walk through the workspace creation wizard. You'll need to select a subscription, resource group, workspace name, and region. Pick the Azure region geographically closest to where your developers and CI agents are running, this matters for latency more than people expect.
Once the new workspace is provisioned, navigate to it and find the Settings > Workspace section. Copy the new service endpoint URL. It will look different from the old Microsoft Playwright Testing endpoint, don't reuse the old one.
Back in your project, open your playwright.config.ts and update the service endpoint. If you previously installed the @azure/microsoft-playwright-testing package, check whether the Azure App Testing workspace requires an updated package version, the service package and the endpoint go together. Run a single test locally first to verify the connection before wiring it into your CI pipeline:
npx playwright test --project=chromium tests/smoke.spec.tsIf you see the test connect to remote browsers and execute, you're done. Go update your CI environment variables with the new endpoint. If you still see auth errors, jump to the Step-by-Step section below, you likely need to regenerate your access token against the new workspace.
For users who are not hitting the retirement issue, say, you're setting up Azure Playwright Testing for the first time on a new account, the most common quick fix is verifying your Azure account role. The service requires your account to have Owner, Contributor, or one of the classic administrator roles on the subscription. Reader access is not enough. Go to Azure Portal > Subscriptions > [your subscription] > Access control (IAM) and confirm your role assignment there before anything else.
Before touching any Playwright config or service packages, get your Azure access sorted. Azure Playwright Testing, and its successor, Azure App Testing, won't provision a workspace at all if you don't have the right role, and the error shown in the portal is often just a generic "something went wrong" message that doesn't tell you the role is the problem.
Navigate to the Azure Portal, click on Subscriptions in the left sidebar, select your target subscription, then click Access control (IAM). Click the View my access button. You're looking for a role of Owner, Contributor, or a classic administrator role. If your account only has Reader or a custom role that doesn't include resource write permissions, workspace creation will fail.
If you're in an enterprise environment and you don't see the right roles, you'll need to contact your Azure administrator. Request Contributor access to the specific resource group where you want to create the testing workspace, you don't need subscription-wide Contributor if your admin prefers tighter scoping.
Once you've confirmed or corrected your role, go to the Azure portal search bar and search for the testing service. Create a new workspace, selecting the appropriate subscription, a resource group (create a new one like rg-playwright-testing if needed), a workspace name, and your target region. After the workspace provisions, usually takes under two minutes, you should see it in a healthy state in your resource list. That's how you know the access issue is resolved.
This step trips up even experienced Azure developers because the access token system for Azure Playwright Testing is separate from your Azure Active Directory credentials. Your Azure login doesn't automatically authenticate your Playwright test runner against the cloud browsers, you need a dedicated workspace access token.
Inside your workspace in the Azure portal, look for Settings > Access tokens in the left navigation pane. Click Generate new token. Give it a descriptive name like ci-github-actions-token or local-dev-token so you can track which systems are using which token. Set an expiration that makes sense for your team, 90 days is a reasonable default for CI tokens, shorter for tokens used in local development.
Copy the token value immediately. It will not be shown again. Store it securely, for local development, add it to a .env file that is listed in your .gitignore. For CI systems, store it as an encrypted secret in GitHub Actions (Settings > Secrets and variables > Actions) or as a secret variable in your Azure Pipeline library.
The environment variable name that the service package looks for is typically PLAYWRIGHT_SERVICE_ACCESS_TOKEN. Set it alongside your workspace endpoint:
PLAYWRIGHT_SERVICE_URL=https://[workspace-id].api.playwright.microsoft.com/accounts/[account-id]/browsers
PLAYWRIGHT_SERVICE_ACCESS_TOKEN=[your-token-here]After setting these, run one test locally to confirm the token works before committing anything to CI. A successful connection will show "Connecting to remote browser..." in your Playwright output rather than a local browser launch.
One of the genuinely nice things about Azure Playwright Testing is that it doesn't ask you to rewrite your test code. Your existing .spec.ts files stay exactly as they are. What changes is your configuration layer, you install the service package and update playwright.config.ts to point at the cloud infrastructure instead of local browsers.
First, install the service package into your project:
npm install @azure/microsoft-playwright-testing --save-devNow open your playwright.config.ts. At the top, import the service configuration helper:
import { defineConfig } from '@playwright/test';
import { getServiceConfig, ServiceOS } from '@azure/microsoft-playwright-testing';
const config = defineConfig({
testDir: './tests',
use: {
baseURL: 'https://your-app-url.com',
},
projects: [
{ name: 'chromium', use: { browserName: 'chromium' } },
{ name: 'firefox', use: { browserName: 'firefox' } },
],
});
export default process.env.PLAYWRIGHT_SERVICE_URL
? getServiceConfig(config)
: config;This pattern is clean, when PLAYWRIGHT_SERVICE_URL is set (in CI or when testing the cloud service locally), the service config activates. When it's not set, your tests run normally against local browsers. You get the best of both worlds without maintaining two separate config files.
Run npx playwright test with the environment variables set. Watch the output for "remote browser" confirmation. If you see your tests starting against local browsers despite the env vars being set, double-check for typos in the variable name, PLAYWRIGHT_SERVICE_URL, not PLAYWRIGHT_SERVICE_ENDPOINT or variations.
Getting Azure Playwright Testing working locally is satisfying. Getting it working in CI is what actually matters. The integration differs slightly between GitHub Actions and Azure Pipelines, and each has its own failure patterns.
For GitHub Actions, your workflow YAML needs the secrets exposed as environment variables in the step that runs Playwright. Here's a minimal working example:
- name: Run Playwright Tests
env:
PLAYWRIGHT_SERVICE_URL: ${{ secrets.PLAYWRIGHT_SERVICE_URL }}
PLAYWRIGHT_SERVICE_ACCESS_TOKEN: ${{ secrets.PLAYWRIGHT_SERVICE_ACCESS_TOKEN }}
run: npx playwright test --reporter=listMake sure both secrets are added to your repository under Settings > Secrets and variables > Actions. A common mistake here is adding them at the organization level but not inheriting them down to the repository, check that your repository-level settings allow inherited secrets if you've set them org-wide.
For Azure Pipelines, store both values in a variable group in the Azure DevOps library, then reference the group in your pipeline YAML:
variables:
- group: playwright-service-secrets
steps:
- script: npx playwright test
displayName: 'Run Playwright Tests'
env:
PLAYWRIGHT_SERVICE_URL: $(PLAYWRIGHT_SERVICE_URL)
PLAYWRIGHT_SERVICE_ACCESS_TOKEN: $(PLAYWRIGHT_SERVICE_ACCESS_TOKEN)After your first successful CI run, check the test results section in your Azure workspace portal. Results and artifacts, screenshots, trace files, video recordings from failed tests, should be available there for review without needing to download artifacts from the CI runner. If results aren't appearing in the portal, verify that the test run is configured to publish results to the service, not just output them locally.
If your tests are connected and running but slower than expected, the configuration for parallel execution and regional affinity is likely the culprit. This is where Azure Playwright Testing delivers its biggest value, running tests across many parallel cloud browsers simultaneously, but it requires deliberate configuration to activate.
By default, Playwright runs tests with a limited worker count based on local CPU cores. When connected to the cloud service, you can dramatically increase this. In your playwright.config.ts, set the worker count explicitly:
export default getServiceConfig(config, {
os: ServiceOS.LINUX,
workers: 20,
});Twenty workers is a reasonable starting point for most mid-sized test suites. The service's cloud infrastructure handles the actual browser instances, so you're not limited by your CI agent's processing power, that's the whole point. Experiment with worker counts up to what your workspace tier allows and watch the total suite completion time drop significantly.
For regional latency, the rule is simple: your workspace should be in the Azure region closest to the majority of your CI agents or developer machines. If your team is in Western Europe and your workspace is in East US, you're adding unnecessary latency on every browser command. The service documentation notes that regional affinity transfers metadata from the cloud-hosted browser region to the workspace region securely, but starting with workspace and browsers in the same region is still faster.
When selecting your operating system for remote browsers, ServiceOS.LINUX is generally faster to spin up and is appropriate for most web application testing. Use ServiceOS.WINDOWS only if your tests specifically validate Windows-only rendering or behavior. For mobile emulation, testing Google Chrome for Android or Mobile Safari behavior, the service supports this through Playwright's built-in device emulation without needing a separate mobile OS configuration.
After adjusting parallelization settings, compare your test suite completion times before and after. You should see a substantial reduction proportional to the increase in workers.
Advanced Troubleshooting
When the standard fixes don't resolve your Azure Playwright Testing issues, you need to go deeper. Here's what I look at when the surface-level fixes have been exhausted.
Workspace region and data residency conflicts. Azure Playwright Testing enforces strict in-region data residency. All data, workspace details, test run metadata including start/end times, test minutes consumed, who ran the test, and test results and artifacts, stays in the region where you created the workspace. If your organization has data residency policies that conflict with where your workspace is provisioned, you'll hit access errors or workspace creation failures that look like permission issues but are actually policy blocks. Check your Azure Policy assignments at the subscription or management group level for any deny effects on resource creation in specific regions.
Free trial limit exhaustion. The Microsoft Playwright Testing free trial allows 100 total test minutes and 1,000 total test results over a 30-day period. These are cumulative limits, not monthly resets. If you've burned through either limit, which happens fast if you're running a large parallel test suite, your tests will fail with quota-related errors. Check your workspace usage dashboard in the Azure portal under Settings > Usage to see where you stand. Once the trial limits are hit, you need to upgrade to a paid plan to continue.
Access token expiration in CI. Tokens have expiration dates set at creation time. If your CI pipeline worked for months and then suddenly started throwing authentication errors, the first thing to check is whether your access token has expired. Go to Settings > Access tokens in your workspace, look at the expiration date on the token your CI uses, and generate a new one if needed. Update the secret in your CI system and re-run.
Service package version mismatches. Microsoft Playwright Testing and Azure App Testing have specific supported Playwright versions. Running an unsupported Playwright version, either too old or bleeding-edge, can cause compatibility errors where the service package can't properly negotiate with the cloud browser infrastructure. Check the service documentation for the current supported Playwright version matrix and pin your @playwright/test version accordingly in package.json.
Network-level endpoint access. One of the stated advantages of Azure Playwright Testing is that it can test privately hosted applications without opening inbound firewall connections, the cloud browsers make outbound connections to your app, not inbound. However, the client machine (your developer workstation or CI agent) needs outbound access to the service endpoint on port 443. In corporate environments with egress filtering, the service endpoint domain may be blocked. Work with your network team to allowlist the Azure Playwright Testing endpoint domain.
Trace file and artifact publishing failures. After test runs, results and trace files are published from the client machine to the service portal. If your CI agent doesn't have the right outbound connectivity, or if the publish step is timing out due to large artifact sizes, you'll see test results in your local run output but nothing in the portal. Check CI runner logs for any errors after the test execution step, artifact publishing happens as a separate operation and its failures are logged separately from test failures.
Prevention & Best Practices
Most Azure Playwright Testing headaches are avoidable with the right habits from the start. Here's what separates teams that use this service smoothly from teams that fight it constantly.
Separate tokens per environment. Don't use a single access token everywhere. Generate one token for local developer use, a separate one for your staging CI pipeline, and a separate one for your production CI pipeline. Give each token a descriptive name when you create it. When something breaks, you can immediately see which environment is affected and rotate just that token without disrupting others. It also gives you a clean audit trail if a token is ever compromised.
Pin your Playwright version. Use an exact version in your package.json rather than a range, "@playwright/test": "1.44.0" rather than "^1.44.0". The Azure Playwright Testing service package maintains compatibility against specific Playwright versions. Automatic minor version bumps in Playwright can introduce API changes that break service package integration in subtle ways. Review the service's supported version list before upgrading and test the upgrade in a branch first.
Monitor your test minutes proactively. Set up a calendar reminder or Azure cost alert to check your workspace usage before you're likely to hit trial limits. If you're on a paid plan, configure Azure cost alerts for the Playwright Testing resource to catch any unexpected usage spikes, a misconfigured parallel worker count can consume test minutes at a surprising rate.
Test your CI pipeline on a feature branch first. Before adding Azure Playwright Testing to your main branch CI pipeline, run it on a feature branch. This lets you iterate on the environment variable configuration, service endpoint setup, and worker count without affecting your main branch's build status. Once you've confirmed a clean end-to-end run on the feature branch, merge the CI changes.
- Create your new Azure App Testing workspace before March 8, 2026 retirement deadline and migrate now, don't wait
- Store your service endpoint URL and access token as CI secrets from day one, never hardcoded in config files
- Use
ServiceOS.LINUXfor faster browser spin-up times unless you specifically need Windows browser behavior - Run a smoke test with a single spec file and a high worker count to verify parallelization is active before running your full suite
Frequently Asked Questions
What is Microsoft Playwright Testing and is it still available?
Microsoft Playwright Testing Preview is a fully managed cloud service for running Playwright end-to-end tests against parallel remote browsers across different operating systems and browser combinations. It was built on top of the open-source Playwright framework. However, the service is being retired on March 8, 2026. Microsoft has replaced it with Azure App Testing, which is now generally available. If you're currently using Microsoft Playwright Testing, you need to migrate your workspace to Azure App Testing before the retirement date, it is not an automatic migration.
How do I get the free trial for Azure Playwright Testing?
The Microsoft Playwright Testing Preview free trial gives you 30 days, 100 total test minutes, and 1,000 total test results, no credit card required beyond having an active Azure subscription. To start the trial, you need an Azure account with Owner, Contributor, or a classic administrator role on your subscription. Create a workspace in the Azure portal and the trial activates automatically. Keep in mind the 100 test minutes and 1,000 test results are lifetime limits for the trial period, not monthly allotments, they don't reset. Once you exhaust either limit, you'll need to upgrade to continue running tests.
Why are my Playwright tests failing to connect to the remote browser?
The three most common causes are: an expired or missing access token, a stale service endpoint URL (especially if you recreated your workspace), or the retirement of the old Microsoft Playwright Testing service if you haven't migrated to Azure App Testing yet. Start by checking your PLAYWRIGHT_SERVICE_URL and PLAYWRIGHT_SERVICE_ACCESS_TOKEN environment variables, confirm they're set and not truncated. Then go to your workspace in the Azure portal, check that the workspace is in a healthy state, and verify your access token hasn't expired under Settings > Access tokens. If the workspace itself is the old Microsoft Playwright Testing type, you need to create a new workspace in Azure App Testing instead.
Do I need to change my test code to use Azure Playwright Testing?
No, this is one of the genuinely well-designed aspects of the service. Your existing .spec.ts test files remain completely untouched. The only changes are in your configuration layer: you install the @azure/microsoft-playwright-testing service package and update your playwright.config.ts to call getServiceConfig() when the service environment variables are present. When those variables aren't set, like when a developer runs tests locally without the cloud service, the config automatically falls back to running against local browsers. Zero test code changes, clean separation between local and cloud execution.
How does Azure Playwright Testing handle data privacy and where is my test data stored?
Azure Playwright Testing enforces strict in-region data residency, no customer data is stored or processed outside the Azure region where you created your workspace. This includes workspace metadata, test run details like start and end times, test minutes consumed, who ran each test, and any test results and artifacts published to the service. All stored data is automatically encrypted using keys managed by Microsoft (service-managed keys). There is no customer-managed key option in the preview tier. If your organization has specific data sovereignty requirements, choose your workspace region carefully at creation time, you can't move a workspace to a different region after it's created.
How do I run tests against my local development server using Azure Playwright Testing?
Yes, this works, and it's one of the more useful features. The cloud-hosted remote browsers can test applications running on localhost on your developer workstation during the development phase. The service is designed to test both publicly and privately hosted applications without requiring you to open inbound firewall connections, because the test client (your machine) runs the Playwright code and drives the remote browser, rather than the remote browser reaching into your machine. In your test's baseURL, you can use your local dev server address. Just make sure the Playwright client on your machine has outbound access to the service endpoint, and the remote browser sessions are driven through that client connection.