DEV Community: web4browser

Stop Playwright Before It Uses the Wrong Browser Profile

web4browser — Tue, 07 Jul 2026 02:03:25 +0000

A Playwright script can pass every local check and still run in the wrong browser environment.

The selector may be correct. The proxy may connect. The page may load. The cookie file may exist. But the task can still touch the wrong account, wrong region, wrong session, or a profile that another worker is already using.

That is why browser automation with real profiles needs a preflight gate.

This pattern is most useful when your automation does not run against disposable test users. It is for teams that run tasks across persistent browser profiles, shared accounts, regional proxies, or long-lived sessions.

Before a task opens the target page, it should verify that the browser profile, proxy, session, and account context match the task it is about to run. This is the same idea behind a broader browser workspace checklist: profile ownership, proxy binding, session state, task logs, review points, and handoff rules should be standardized before automation becomes routine.

Scope note: this article is about authorized automation in browser profiles your team owns or is allowed to operate. It is not about bypassing platform rules or hiding abusive activity. A preflight gate reduces operational mistakes. It does not make automation compliant by itself.

The bug was not in the selector

A common failure report sounds like this:

The Playwright task worked yesterday. Today it opened the right page but used the wrong account.

The first reaction is usually to debug the script.

Maybe the selector changed.

Maybe the login state expired.

Maybe the proxy was slow.

Maybe Chromium launched with the wrong option.

Maybe headless mode behaved differently.

All of those are possible. But in multi-account automation, the deeper question is often simpler:

Was this task allowed to start in this profile at all?

A browser profile is not just a local folder. It represents an account environment. It may include cookies, local storage, extensions, proxy expectations, timezone rules, language settings, previous task history, and team ownership.

If that context is wrong before launch, Playwright only automates the mistake faster.

What most scripts check too late

Many scripts validate the environment after the page is already open.

They launch the profile.

They visit the target URL.

They check whether the user is logged in.

They inspect the page.

They fail after something looks wrong.

That is better than no validation, but it is still late.

A preflight gate should run before the task touches the real business page. Its purpose is not to prove that the full workflow will succeed. Its purpose is to stop obviously mismatched runs before they create harder-to-debug side effects.

Think of it as a launch contract.

A task declares what it expects:

{
  "task_id": "task_2026_001",
  "profile_id": "profile_us_store_12",
  "expected_account": "store_12",
  "expected_proxy_region": "US",
  "expected_timezone": "America/New_York",
  "requires_logged_in_state": true,
  "allow_shared_profile": false
}

That manifest gives your runner something to check before Playwright opens the real target.

What the preflight gate should verify

A useful preflight gate does not need to be complex. It needs to answer a few boring but important questions.

Profile ownership: Is this profile assigned to the account and task that are about to use it?

Lock state: Is another worker already using the same persistent profile?

Proxy region: Does the proxy region match the expected task context?

Timezone: Does the browser timezone match the profile rule?

Session state: Is the logged-in session valid enough for this task?

Human review flag: Did the previous run leave this profile in a state that requires manual review?

If any of these checks fail, the task should stop before it opens the target page.

A small TypeScript model

Here is a simple version of the idea.

The helper functions in this article are placeholders. In a real system, they would connect to your own storage or orchestration layer.

type TaskManifest = {
  taskId: string;
  profileId: string;
  expectedAccount: string;
  expectedProxyRegion: string;
  expectedTimezone: string;
  requiresLoggedInState: boolean;
  allowSharedProfile: boolean;
};

type ProfileState = {
  profileId: string;
  accountId: string;
  proxyRegion: string;
  timezone: string;
  loggedIn: boolean;
  lockedBy?: string;
  humanReviewRequired: boolean;
  lastRunStatus: "passed" | "failed" | "review" | "unknown";
};

type PreflightResult = {
  ok: boolean;
  reason?: string;
  evidence: Record<string, unknown>;
};

The runner should load the current profile state from your own registry, database, file, or workspace service.

async function preflightCheck(
  manifest: TaskManifest,
  current: ProfileState
): Promise<PreflightResult> {
  if (current.profileId !== manifest.profileId) {
    return {
      ok: false,
      reason: "Profile ID mismatch",
      evidence: { manifest, current }
    };
  }

  if (current.accountId !== manifest.expectedAccount) {
    return {
      ok: false,
      reason: "Account context mismatch",
      evidence: { manifest, current }
    };
  }

  if (!manifest.allowSharedProfile && current.lockedBy) {
    return {
      ok: false,
      reason: "Profile is already locked",
      evidence: {
        profileId: current.profileId,
        lockedBy: current.lockedBy
      }
    };
  }

  if (current.proxyRegion !== manifest.expectedProxyRegion) {
    return {
      ok: false,
      reason: "Proxy region mismatch",
      evidence: {
        expected: manifest.expectedProxyRegion,
        actual: current.proxyRegion
      }
    };
  }

  if (current.timezone !== manifest.expectedTimezone) {
    return {
      ok: false,
      reason: "Timezone mismatch",
      evidence: {
        expected: manifest.expectedTimezone,
        actual: current.timezone
      }
    };
  }

  if (manifest.requiresLoggedInState && !current.loggedIn) {
    return {
      ok: false,
      reason: "Missing logged-in session",
      evidence: {
        profileId: current.profileId,
        loggedIn: current.loggedIn
      }
    };
  }

  if (current.humanReviewRequired || current.lastRunStatus === "review") {
    return {
      ok: false,
      reason: "Profile requires human review",
      evidence: {
        profileId: current.profileId,
        lastRunStatus: current.lastRunStatus
      }
    };
  }

  return {
    ok: true,
    evidence: {
      profileId: current.profileId,
      accountId: current.accountId,
      proxyRegion: current.proxyRegion,
      timezone: current.timezone
    }
  };
}

Only after this returns ok: true should the task launch the persistent browser context.

Connect the gate to Playwright

The Playwright side can stay simple. You can use launchPersistentContext when the task needs a persistent profile directory.

The lock matters because persistent profile directories should not be treated as safely shareable runtime state.

import { chromium } from "playwright";

async function runTask(manifest: TaskManifest) {
  const current = await readProfileState(manifest.profileId);
  const preflight = await preflightCheck(manifest, current);

  await writePreflightLog({
    taskId: manifest.taskId,
    profileId: manifest.profileId,
    status: preflight.ok ? "passed" : "failed",
    reason: preflight.reason,
    evidence: preflight.evidence,
    timestamp: new Date().toISOString()
  });

  if (!preflight.ok) {
    throw new Error(`Preflight failed: ${preflight.reason}`);
  }

  await lockProfile(manifest.profileId, manifest.taskId);

  const context = await chromium.launchPersistentContext(
    `/profiles/${manifest.profileId}`,
    {
      headless: false,
      timezoneId: manifest.expectedTimezone
    }
  );

  try {
    const page = await context.newPage();

    await page.goto("https://example.com/dashboard");

    // Run the actual task here.
  } finally {
    await context.close();
    await unlockProfile(manifest.profileId, manifest.taskId);
  }
}

The storage layer is up to your team. You can keep profile state in a JSON file, SQLite, Postgres, Redis, or an internal service.

The important sequence is:

Read the expected task context.
Read the current profile context.
Compare them.
Log the result.
Stop if the gate fails.
Launch Playwright only after the gate passes.

Save failed preflight evidence

A failed preflight is not noise. It is useful evidence.

Store it like a real automation artifact.

{
  "task_id": "task_2026_001",
  "profile_id": "profile_us_store_12",
  "preflight_status": "failed",
  "reason": "Proxy region mismatch",
  "expected_proxy_region": "US",
  "actual_proxy_region": "JP",
  "timestamp": "2026-07-06T10:00:00Z"
}

This gives the team a clean explanation.

The script did not fail because Playwright was unstable.

The task was stopped because the browser environment did not match the task contract.

That distinction matters.

It helps developers avoid random retries. It helps operators fix profile mapping. It helps managers see whether failures come from code, proxy assignment, profile ownership, or process drift.

Do not turn every failure into a retry

Retry logic is useful for network errors, temporary UI changes, and slow pages.

It is dangerous for context errors.

A retry will not fix the wrong account.

A retry will not fix a profile used by another worker.

A retry will not fix an unexpected region.

A retry will not fix a profile that needs human review.

A good preflight gate should turn some failures into stop conditions.

For example:

selector timeout: retry may be reasonable.
proxy region mismatch: stop.
profile locked: wait or stop.
logged out: stop or route to login recovery.
human review required: stop.
account mismatch: stop immediately.

This is where browser automation becomes more than script execution. It becomes workflow control.

A short checklist

Before a Playwright task uses a real browser profile, check that:

The task points to the expected profile.
The profile belongs to the expected account.
The profile is not locked by another worker.
The proxy region matches the task.
The timezone matches the profile rule.
The session is valid enough for this task.
The previous run does not require human review.
The preflight result is written to a log.
The profile is locked before launch.
The profile is unlocked after close.
The actual task does not start when preflight fails.

None of this replaces normal Playwright debugging. You still need screenshots, traces, console logs, network logs, and error handling.

But a preflight gate catches a different class of problem. It catches the cases where the browser should not have started the task in the first place.

Final thought

Playwright is good at controlling a browser. It is not, by itself, a system for deciding whether a browser profile is the right environment for a task.

For single-account tests, that may not matter much. For multi-account teams, profile context becomes part of the automation contract.

When profiles, proxies, cookies, task logs, and review steps are managed together, browser automation becomes easier to stop, explain, and hand off. The main lesson is simple: do not treat each Playwright run as an isolated script when the real risk sits in the account environment around it.

Playwright Browser Profile Drift: What to Check Before a Task Fails

web4browser — Thu, 02 Jul 2026 07:20:35 +0000

If a Playwright task worked yesterday and fails today, the first thing you may check is the selector.

Then the wait condition.

Then the proxy.

Then the retry count.

Those checks are useful, but they can miss a more basic problem: the browser profile may no longer be the same runtime environment.

That is profile drift.

A task can fail before your script logic is wrong. It can fail because the profile, login state, browser version, locale, timezone, extension state, proxy mapping, or account ownership changed since the last successful run.

This post gives you a practical preflight pattern for catching that drift before the task touches the real page.

The failure pattern

Profile drift usually shows up as small inconsistencies:

The task opens the right site, but the wrong account is signed in.
The dashboard asks for login even though the profile was logged in yesterday.
The same script passes locally but fails on another worker.
The account uses a different proxy route than expected.
A persistent context launches, but local storage is no longer valid.
Headless mode fails while a visible run looks fine.

None of these automatically mean “Playwright is broken.”

They often mean the script is running inside a browser state that no longer matches the account environment the task expects.

What profile drift means

A browser profile is not just a folder.

For automation, it is part of the account runtime.

It may contain cookies, local storage, extensions, browser preferences, language, timezone, and other state that affects how the target page behaves.

Profile drift happens when that runtime changes without the task knowing.

Common causes include:

the wrong userDataDir is used
the login session expired
cookies exist, but local storage changed
a proxy mapping was edited
timezone or locale no longer matches the account region
the browser version changed after an update
an extension was added, removed, or updated
another worker opened the same profile
a teammate copied the profile but not its metadata
the task moved from a local machine to CI with different assumptions

This is why “the profile exists” is not enough.

The task needs to prove it is using the expected profile state.

Keep a small runtime manifest

A simple way to reduce drift is to keep a manifest for each profile.

It does not need to describe everything. It only needs to record the fields that matter before the task runs.

{
  "profileId": "store-us-018",
  "expectedAccount": "store_us_primary",
  "userDataDir": "./profiles/store-us-018",
  "proxyId": "proxy-us-dallas-01",
  "expectedRegion": "US",
  "timezone": "America/Chicago",
  "locale": "en-US",
  "browserChannel": "chrome",
  "checkUrl": "https://your-app.example/dashboard",
  "lastVerifiedAt": "2026-06-20T10:30:00Z",
  "lastTaskId": "daily-status-check-431"
}

Replace checkUrl with a page that belongs to your own workflow.

The manifest includes proxy and region fields because many teams treat them as blocking checks, even though the short sample below only implements locale, timezone, and login-state checks.

This turns the profile into a contract.

The task is no longer saying:

“Open this profile and hope it is right.”

It is saying:

“Open this profile only if the runtime still matches the account environment I expect.”

Add a preflight before the real task

Here is a simplified Playwright preflight check.

It verifies locale, timezone, and login state before the task continues.

import { chromium } from "playwright";
import fs from "node:fs/promises";

const manifest = JSON.parse(
  await fs.readFile("./profile-manifest.json", "utf8")
);

await fs.mkdir("evidence", { recursive: true });

async function blockRun(reason, details = {}) {
  const report = {
    reason,
    details,
    checkedAt: new Date().toISOString()
  };

  await fs.writeFile(
    `evidence/${manifest.profileId}-preflight-failed.json`,
    JSON.stringify(report, null, 2)
  );

  throw new Error(`Profile preflight failed: ${reason}`);
}

let context;

try {
  context = await chromium.launchPersistentContext(
    manifest.userDataDir,
    {
      channel: manifest.browserChannel,
      locale: manifest.locale,
      timezoneId: manifest.timezone,
      headless: false
    }
  );

  const page = context.pages()[0] ?? await context.newPage();

  const runtime = await page.evaluate(() => ({
    language: navigator.language,
    languages: navigator.languages,
    timezone: Intl.DateTimeFormat().resolvedOptions().timeZone,
    userAgent: navigator.userAgent
  }));

  if (runtime.language !== manifest.locale) {
    await blockRun("locale drift", {
      expected: manifest.locale,
      actual: runtime.language
    });
  }

  if (runtime.timezone !== manifest.timezone) {
    await blockRun("timezone drift", {
      expected: manifest.timezone,
      actual: runtime.timezone
    });
  }

  await page.goto(manifest.checkUrl, {
    waitUntil: "domcontentloaded"
  });

  const loginPromptVisible = await page
    .getByText(/log in|sign in/i)
    .first()
    .isVisible()
    .catch(() => false);

  if (loginPromptVisible) {
    await page.screenshot({
      path: `evidence/${manifest.profileId}-login-required.png`,
      fullPage: true
    });

    await blockRun("missing or expired login state", {
      profileId: manifest.profileId,
      url: page.url()
    });
  }
} finally {
  await context?.close();
}

This is not a full production system.

It is a decision pattern.

Before the task performs account-sensitive actions, it checks whether the runtime still matches the expected profile state.

This sample only checks locale, timezone, and login state. If proxy route, browser version, profile ownership, or worker locking matters for your workflow, add those checks to the same preflight layer instead of treating them as separate debugging steps.

Also, the login detector in this example is intentionally simple. In production, use a stable login marker, route pattern, response signal, or test id instead of a broad text match like /log in|sign in/i.

What should stop the run

Some drift signals should block the task immediately.

For example:

wrong profile path
wrong account
missing login state
unexpected login page
wrong proxy group
unexpected region
timezone or locale mismatch
browser version mismatch after a release
profile already used by another worker
security checkpoint or MFA page

These are not good retry candidates.

Retrying inside the wrong environment can make the failure harder to diagnose.

What should only create a warning

Not every difference should stop execution.

Some signals should create a warning and save evidence, but still allow the task to continue.

Examples:

the profile has not been verified recently
viewport changed, but the task is not layout-sensitive
a non-critical extension updated
page copy changed, but stable locators still work
the task starts from a different URL but reaches the expected page
a temporary banner appears before the main workflow

Blocking everything creates noise.

Ignoring everything creates silent failures.

The useful middle ground is a run, warn, or stop decision.

Save evidence when drift is detected

When profile drift is detected, save enough information for a teammate to understand the failure later.

At minimum, capture:

profile ID
expected account
current URL
screenshot
task ID
worker ID
expected proxy ID
expected region
runtime locale
runtime timezone
browser version
drift summary
last successful task ID

The goal is not only to fail safely.

The goal is to make the failure reviewable.

A useful drift report should answer three questions:

What did the task expect?
What did it actually see?
Why did it stop?

Why retries are the wrong first fix

Retries help with temporary failures.

A timeout can be retried.

A temporary 500 response can be retried.

A flaky selector can be retried while you collect evidence.

Profile drift is different.

If the task is running in the wrong account context, retrying may repeat actions in the wrong profile, overwrite useful state, trigger extra verification, or hide the original cause.

A better sequence is:

Preflight the profile.
Stop on blocking drift.
Save evidence.
Repair or review the environment.
Run the task only after the profile is verified again.

A team workflow note

For one local script, a JSON manifest and a few screenshots may be enough.

For a team, profile state usually needs to be easier to share and review. Profiles, proxies, session checks, screenshots, task logs, and review notes should not live in five disconnected places.

For a deeper account-context checklist, see this account context check for browser tasks.

Teams that manage long-lived browser profiles usually need a shared profile environment, not scattered folders, proxy notes, screenshots, and task logs.

In team environments, this is usually a workflow problem, not just a script problem.

The rule applies to any automation stack:

A browser task should prove its runtime before it acts.

Final checklist

Before a Playwright task uses a persistent browser profile, check:

Is this the intended profile?
Is the expected account signed in?
Is the proxy mapping still correct?
Do timezone and locale match the expected account region?
Did the browser version change?
Did extension state change?
Is another worker using the same profile?
Is the task starting from the expected page state?
Can the task save screenshot and URL evidence if it stops?
Is there a clear decision between run, warn, stop, and review?

Do not debug every Playwright failure as code first.

Sometimes the code is fine.

The runtime changed.

How to Diff Browser Profile State Before Reusing It in Playwright

web4browser — Mon, 29 Jun 2026 12:02:49 +0000

A browser profile can be available and still not be ready.

That is one of the easiest bugs to miss in long-running browser automation.

A worker picks up a profile. The lock is free. The user data directory exists. The proxy test passes. Playwright can launch the browser.

Then the task opens a login screen, lands in the wrong workspace, uses stale local storage, or continues after the previous run already failed.

The issue is not always Playwright.

It is often profile state drift.

If your automation depends on logged-in account context, start with an account context check before browser automation. Then add one more guardrail: diff the profile before reusing it.

Availability is not readiness

A simple worker queue usually checks something like this:

type ProfileLease = {
  profileId: string;
  userDataDir: string;
  lockedBy?: string;
  lockedUntil?: string;
};

If the profile is not locked, the worker runs.

That answers one question:

Can this worker open the profile?

It does not answer the better question:

Is this profile still in the expected state for this task?

That difference matters.

For logged-in browser automation, the profile is not just a folder. It may carry cookies, local storage, session state, extensions, timezone assumptions, language settings, proxy mapping, and the residue of the last run.

Playwright can reuse browser state through a persistent context. That is useful. It is also why stale state can become dangerous.

The failure pattern

This usually appears after the system has been running for a while.

At first, everything looks stable:

profile acquired
browser launched
page opened
task started

Then the task fails in a way that does not look like a code bug:

expected: dashboard page
actual: login page

expected: account_us_042 context
actual: unknown account context

expected: workspace "client-a"
actual: workspace picker

expected: continue task
actual: verification required

The worker did not crash.

The profile was not missing.

The browser opened correctly.

But the profile state was no longer the state the task expected.

That is the gap this article focuses on.

If your application exposes a safe readonly marker, such as a workspace ID, account label, or profile banner, you can include that marker in your snapshot. If it does not, treat account identity as unknown and route uncertain states to review.

Define a baseline after a known good run

Do not diff against memory.

Diff against a saved baseline.

A baseline is the profile state you trusted after the last successful run.

type ProfileBaseline = {
  profileId: string;
  accountKey: string;

  expectedProxyId: string;
  expectedRegion: string;
  expectedTimezone: string;
  expectedLanguage: string;

  browserMajorVersion: string;

  lastKnownUrl: string;
  lastRunStatus: "success" | "review" | "failed";

  criticalCookieNames: string[];
  expectedLocalStorageKeys: string[];

  updatedAt: string;
};

This is not meant to be a full fingerprint dump.

It is an operational snapshot.

It tells the next worker what the profile was supposed to look like when it was last considered safe for automation.

Include registry state, not only page state

Some profile state comes from the browser.

Some state comes from your own system.

For example, proxy identity usually comes from your profile registry, not from the page itself. The page may help you verify region, but the assigned proxy ID should come from the system that maps profiles to proxies.

That means your preflight should compare two layers:

Registry metadata before launch
Browser-visible state after launch

A minimal registry record might look like this:

type ProfileRegistryRecord = {
  profileId: string;
  userDataDir: string;
  assignedProxyId: string;
  assignedRegion: string;
};

The browser can tell you some things.

Your profile registry should tell you which proxy, region, owner, project, or account group the profile is supposed to belong to.

Do not mix those sources together without naming them.

Also be careful with the word region.

assignedRegion is registry intent, not proof of real egress. It tells you what the profile is supposed to use. If real network location matters, verify it with a separate non-account network check before opening the logged-in page.

Collect a lightweight current snapshot

Before launching the real task, run a preflight check.

The preflight should avoid destructive actions. Do not click buttons, submit forms, publish content, change account settings, or accept unexpected prompts.

Just open a stable page, inspect state, record what you see, and close.

import { chromium } from "playwright";

type ProfileSnapshot = {
  profileId: string;

  assignedProxyId: string;
  assignedRegion: string;

  currentUrl: string;
  timezone: string;
  language: string;

  cookieNames: string[];
  localStorageKeys: string[];
};

async function collectProfileSnapshot(
  profile: ProfileRegistryRecord,
  preflightUrl: string
): Promise<ProfileSnapshot> {
  const context = await chromium.launchPersistentContext(profile.userDataDir, {
    headless: true,
  });

  const page = await context.newPage();

  await page.goto(preflightUrl, {
    waitUntil: "domcontentloaded",
    timeout: 30_000,
  });

  const cookies = await context.cookies();

  const localStorageKeys = await page.evaluate(() => {
    return Object.keys(window.localStorage).sort();
  });

  const timezone = await page.evaluate(() => {
    return Intl.DateTimeFormat().resolvedOptions().timeZone;
  });

  const language = await page.evaluate(() => navigator.language);

  const snapshot: ProfileSnapshot = {
    profileId: profile.profileId,

    assignedProxyId: profile.assignedProxyId,
    assignedRegion: profile.assignedRegion,

    currentUrl: page.url(),
    timezone,
    language,
    cookieNames: cookies.map((cookie) => cookie.name).sort(),
    localStorageKeys,
  };

  await context.close();

  return snapshot;
}

This check is intentionally small.

You are not trying to prove that the account is safe forever. You are trying to catch obvious drift before the worker performs real work.

Also remember that opening a persistent context can still update some browser state. Treat this as a minimal preflight, not a pure read-only inspection.

Diff by severity

Do not reduce profile drift to one boolean.

Some differences are harmless. Some should trigger review. Some should stop the run immediately.

Use severity.

type DiffSeverity = "ok" | "soft" | "hard";

type ProfileDiff = {
  severity: DiffSeverity;
  field: string;
  reason: string;
};

function diffProfileState(
  baseline: ProfileBaseline,
  snapshot: ProfileSnapshot
): ProfileDiff[] {
  const diffs: ProfileDiff[] = [];

  if (baseline.expectedProxyId !== snapshot.assignedProxyId) {
    diffs.push({
      severity: "hard",
      field: "proxy",
      reason: `Expected proxy ${baseline.expectedProxyId}, got ${snapshot.assignedProxyId}`,
    });
  }

  if (baseline.expectedRegion !== snapshot.assignedRegion) {
    diffs.push({
      severity: "hard",
      field: "region",
      reason: `Expected region ${baseline.expectedRegion}, got ${snapshot.assignedRegion}`,
    });
  }

  if (baseline.expectedTimezone !== snapshot.timezone) {
    diffs.push({
      severity: "hard",
      field: "timezone",
      reason: `Expected ${baseline.expectedTimezone}, got ${snapshot.timezone}`,
    });
  }

  if (baseline.expectedLanguage !== snapshot.language) {
    diffs.push({
      severity: "soft",
      field: "language",
      reason: `Expected ${baseline.expectedLanguage}, got ${snapshot.language}`,
    });
  }

  const missingCriticalCookies = baseline.criticalCookieNames.filter(
    (name) => !snapshot.cookieNames.includes(name)
  );

  if (missingCriticalCookies.length > 0) {
    diffs.push({
      severity: "hard",
      field: "cookies",
      reason: `Missing critical cookies: ${missingCriticalCookies.join(", ")}`,
    });
  }

  const missingStorageKeys = baseline.expectedLocalStorageKeys.filter(
    (key) => !snapshot.localStorageKeys.includes(key)
  );

  if (missingStorageKeys.length > 0) {
    diffs.push({
      severity: "soft",
      field: "localStorage",
      reason: `Missing localStorage keys: ${missingStorageKeys.join(", ")}`,
    });
  }

  if (baseline.lastRunStatus === "failed") {
    diffs.push({
      severity: "hard",
      field: "lastRunStatus",
      reason: "Previous run failed. Review the profile before reuse.",
    });
  }

  return diffs;
}

The goal is not perfect detection.

The goal is to prevent blind reuse.

Route the profile before the task runs

Once you have diffs, route the profile.

type ProfileRoute = "run" | "human_review" | "quarantine";

function decideProfileRoute(diffs: ProfileDiff[]): ProfileRoute {
  if (diffs.some((diff) => diff.severity === "hard")) {
    return "quarantine";
  }

  if (diffs.some((diff) => diff.severity === "soft")) {
    return "human_review";
  }

  return "run";
}

Then use the route before starting the real task.

const snapshot = await collectProfileSnapshot(
  profile,
  "https://example.com/dashboard"
);

const diffs = diffProfileState(baseline, snapshot);
const route = decideProfileRoute(diffs);

if (route === "quarantine") {
  await saveDiffReport(profile.profileId, route, diffs);
  throw new Error("Profile drift detected. Quarantine before reuse.");
}

if (route === "human_review") {
  await createReviewTicket(profile.profileId, diffs);
  throw new Error("Profile needs review before automation continues.");
}

await runRealTask(profile);

This small routing step changes the model.

A profile is no longer only:

free
busy

It becomes:

ready to run
needs review
unsafe to reuse

That is a better model for multi-account automation.

Save a diff report

When a profile is blocked, save enough evidence for the next developer or operator.

{
  "profile_id": "profile_us_042",
  "route": "quarantine",
  "checked_at": "2026-06-29T08:00:00Z",
  "diffs": [
    {
      "severity": "hard",
      "field": "proxy",
      "reason": "Expected proxy_us_resi_12, got proxy_de_dc_04"
    },
    {
      "severity": "hard",
      "field": "timezone",
      "reason": "Expected America/New_York, got Europe/Berlin"
    },
    {
      "severity": "hard",
      "field": "cookies",
      "reason": "Missing critical cookies: session_id"
    }
  ],
  "next_action": "Open manually, confirm account state, refresh baseline only after review."
}

A useful report should answer five questions:

Which profile was checked?
What changed?
Why did that change matter?
Did the worker run or stop?
What should the next person do?

Without this report, the next run becomes guesswork.

Common mistakes

Only checking locks

Locks prevent two workers from using the same profile at the same time.

They do not prove that the profile is healthy.

A locked profile can be stale. An unlocked profile can be unsafe.

Treating every cookie difference as critical

Some cookies do not matter for the workflow.

Some are required.

Do not compare every cookie blindly. Define the small set of critical cookie names or session indicators your workflow actually depends on.

Updating the baseline too early

Never refresh the baseline just because the preflight ran.

Only refresh it after a known good task, a controlled account reset, or a human review.

Otherwise, the baseline becomes a record of drift instead of a guardrail against drift.

Running headless through uncertain states

Headless preflight is useful for cheap checks.

But if the page shows login, verification, account warnings, permission changes, payment steps, publishing actions, or unexpected workspace state, the task should stop.

Do not push through uncertain account states silently.

A practical checklist

Before reusing a browser profile, check:

Is this the intended profile for the account?
Is the assigned proxy still the expected proxy?
Does the assigned region still match the baseline?
Is the expected session still present?
Are critical cookies still available?
Are required local storage keys still available?
Does the timezone match the account environment?
Does the language still match the expected workflow?
Did the previous run finish cleanly?
Is there an open review ticket for this profile?
Should the baseline be refreshed, or should the profile be quarantined?

The important shift is simple:

Reuse a profile only after proving it is still the right environment for the task.

For teams that manage many long-lived browser profiles, this is where a structured profile environment boundary becomes useful. In a workspace like Web4 Browser, the profile is treated as part of a larger account environment, not just a folder that Playwright can open.

Profile reuse is powerful.

Profile reuse without state diffing is guesswork.

Adding Release Gates to AI Browser Automation Runs With Real Profiles

web4browser — Sat, 27 Jun 2026 06:15:32 +0000

A Playwright task can pass locally and still fail in a team run.

It may open the wrong persistent profile, use the wrong proxy region, assume a session that has already expired, or continue without enough evidence for someone else to debug the run.

That is where retries stop helping.

For browser automation that runs across real account environments, teams need a release gate.

A release gate is a pre-run check that decides whether a task is allowed to continue. It does not ask only, “Did the script run?” It asks a better question:

Is this browser task running in the right environment, with enough evidence to debug or stop it safely?

This article shows a simple release gate pattern for AI browser agents, Playwright jobs, and team automation workflows.

This pattern is intended for authorized workflows, internal tools, QA environments, and account operations where your team has permission to automate. It should not be used to bypass platform rules or automate activity that violates a service’s terms.

A passing run is not a release

Most browser automation starts with a happy path:

open a page
reuse a session
click through a flow
save a result
retry if something fails

That can be fine for a demo.

It is not enough for team workflows.

In real operations, the browser profile may belong to a specific account. The proxy may be tied to a region. The session may already be expired. The task may require human review before it proceeds.

A release gate helps catch those problems before the agent starts acting.

What the gate should check

A useful browser automation release gate should validate five things:

profile identity
proxy and region consistency
session readiness
evidence plan
stop or review rules

The goal is not to make automation heavy. The goal is to block the wrong run early.

Here is a small context object a task runner could pass into a gate.

type BrowserRunContext = {
  runId: string;
  taskName: string;

  profileId: string;
  profileOwner: string;
  allowedProfiles: string[];

  expectedRegion: string;
  detectedRegion?: string;
  proxyId: string;

  sessionRequired: boolean;
  sessionCheckUrl?: string;

  evidenceRequired: {
    screenshot: boolean;
    currentUrl: boolean;
    stepLog: boolean;
    stopReason: boolean;
  };

  requiresHumanReview: boolean;
};

This object changes the mental model.

The task is no longer just a script. It is a script plus runtime context.

Gate 1: check profile identity

The first gate should confirm that the task knows which browser profile it is about to use.

This matters because a task can open the correct website while still using the wrong account environment.

function checkProfileIdentity(ctx: BrowserRunContext): string[] {
  const failures: string[] = [];

  if (!ctx.profileId) {
    failures.push("Missing profileId");
  }

  if (!ctx.profileOwner) {
    failures.push("Missing profile owner");
  }

  if (!ctx.allowedProfiles.includes(ctx.profileId)) {
    failures.push(`Profile ${ctx.profileId} is not approved for this task`);
  }

  return failures;
}

This check does not need to be complex.

It only needs to prevent a task from running when it cannot prove which profile it is using.

Gate 2: check proxy and region consistency

A proxy is not just a network setting in team browser automation.

It is part of the environment contract.

The profile, proxy, region, timezone, language, and target account history should not be treated as unrelated fields.

In practice, detectedRegion can come from an internal egress check, a proxy health endpoint, or a small preflight request before the browser task starts.

function checkProxyRegion(ctx: BrowserRunContext): string[] {
  const failures: string[] = [];

  if (!ctx.proxyId) {
    failures.push("Missing proxyId");
  }

  if (ctx.detectedRegion && ctx.detectedRegion !== ctx.expectedRegion) {
    failures.push(
      `Region mismatch: expected ${ctx.expectedRegion}, got ${ctx.detectedRegion}`
    );
  }

  return failures;
}

This does not guarantee that a task will succeed.

It only confirms that the run is internally consistent enough to continue.

Gate 3: check session readiness

Many browser agents fail because they assume login state that no longer exists.

Before the agent starts clicking, check whether the profile is actually ready for the task.

The selectors below are placeholders. In production, use selectors that match your own application or target workflow.

import type { Page } from "playwright";

async function checkSessionReadiness(
  page: Page,
  ctx: BrowserRunContext
): Promise<string[]> {
  if (!ctx.sessionRequired) return [];

  const failures: string[] = [];

  if (!ctx.sessionCheckUrl) {
    return ["Session is required, but no sessionCheckUrl was provided"];
  }

  await page.goto(ctx.sessionCheckUrl, { waitUntil: "domcontentloaded" });

  const loginButtonVisible = await page
    .locator("text=Log in")
    .first()
    .isVisible()
    .catch(() => false);

  const accountMenuVisible = await page
    .locator("[data-testid='account-menu']")
    .first()
    .isVisible()
    .catch(() => false);

  if (loginButtonVisible && !accountMenuVisible) {
    failures.push("Session check failed: profile appears logged out");
  }

  return failures;
}

A session gate should run before the main task.

If the account context is missing, the task should stop or go to review.

Gate 4: require an evidence plan before the run

A team should know what evidence will be captured before the task starts.

A minimal evidence plan might require:

screenshot
current URL
step log
stop reason

function checkEvidencePlan(ctx: BrowserRunContext): string[] {
  const failures: string[] = [];
  const evidence = ctx.evidenceRequired;

  if (!evidence.screenshot) failures.push("Screenshot capture is disabled");
  if (!evidence.currentUrl) failures.push("Current URL capture is disabled");
  if (!evidence.stepLog) failures.push("Step log capture is disabled");
  if (!evidence.stopReason) failures.push("Stop reason capture is disabled");

  return failures;
}

This gate checks whether the run is configured to capture evidence. It does not prove that the evidence was saved correctly after execution.

That second part should be verified after the task finishes.

Still, this early check matters. It is the difference between “the agent failed” and “the run stopped at the session check because the profile was logged out.”

That difference matters when another teammate has to debug the run later.

Gate 5: approve, block, or send to review

A release gate should not only approve tasks.

It should also block them.

type GateDecision =
  | { status: "approved"; action: "run_task" }
  | { status: "blocked"; action: "send_to_review"; failures: string[] };

function decideGateStatus(failures: string[]): GateDecision {
  if (failures.length === 0) {
    return {
      status: "approved",
      action: "run_task"
    };
  }

  return {
    status: "blocked",
    action: "send_to_review",
    failures
  };
}

For multi-account automation, failing closed is usually safer than retrying blindly.

One wrong assumption can repeat across many profiles.

A minimal release gate runner

Now combine the checks.

async function runReleaseGate(
  page: Page,
  ctx: BrowserRunContext
): Promise<{
  runId: string;
  taskName: string;
  profileId: string;
  checkedAt: string;
  decision: GateDecision;
}> {
  const failures = [
    ...checkProfileIdentity(ctx),
    ...checkProxyRegion(ctx),
    ...checkEvidencePlan(ctx),
    ...(await checkSessionReadiness(page, ctx))
  ];

  return {
    runId: ctx.runId,
    taskName: ctx.taskName,
    profileId: ctx.profileId,
    checkedAt: new Date().toISOString(),
    decision: decideGateStatus(failures)
  };
}

Store this result with the task log.

If the task later fails, the team can see whether the run was approved correctly, blocked correctly, or promoted with a weak gate.

Make blocked gates return a non-zero exit code

If you use the release gate inside a CLI wrapper, the blocked path should exit with a non-zero code.

That lets CI jobs, schedulers, and shell wrappers stop the browser task before it starts.

const result = await runReleaseGate(page, ctx);

if (result.decision.status === "blocked") {
  console.error(JSON.stringify(result, null, 2));
  process.exit(1);
}

console.log(JSON.stringify(result, null, 2));
process.exit(0);

Then a shell wrapper can stay simple.

node run-release-gate.js

if [ $? -ne 0 ]; then
  echo "Release gate failed. Browser task will not run."
  exit 1
fi

node run-browser-task.js

The gate should run before scheduled jobs, batch runs, AI agent actions, and reusable workflow promotion.

It should not be an afterthought.

A practical promotion flow

A browser automation task can move through this flow:

Draft the task.
Test it with a sandbox profile.
Run the release gate against a controlled real profile.
Save screenshots, URL, step log, and stop reason.
Approve, block, or send to human review.
Promote the task into a reusable workflow.

This works for Playwright scripts, AI browser agents, RPA-style flows, and headless monitoring jobs.

The key is to treat the browser profile as part of the runtime contract.

The proxy is part of the contract.

The session state is part of the contract.

The evidence bundle is part of the contract.

Without that contract, a browser agent can click correctly and still operate in the wrong environment.

What not to put in the gate

A release gate should not become a giant rules engine on day one.

Start small.

Avoid checking things that your team will not review or act on. Avoid collecting sensitive data that is not needed for debugging. Avoid turning every warning into a blocker.

A good first version only needs to answer:

Do we know which profile will run?
Does the proxy match the expected region?
Is the session ready?
Will the run capture enough evidence?
Should this task require human review?

That is already enough to prevent many avoidable failures.

Final checklist

Before promoting a browser automation task, ask:

Is the profile approved for this task?
Is the proxy known and expected?
Is the session actually ready?
Are screenshots and step logs enabled?
Is there a clear stop reason?
Does the task need review before it touches real account state?
Is the gate result stored with the run log?

If the answer is unclear, the task should not be promoted yet.

Closing thought

AI browser automation will keep getting easier to start.

The harder problem is making it trustworthy across real profiles, real sessions, real proxies, and real teams.

Release gates give teams a practical way to decide what can run, what must stop, and what needs review before a browser agent touches production-like account environments.

For a related note on what to capture after browser tasks fail, see this write-up on browser automation evidence logs.

Design Browser Profile Permissions Before Automation Runs

web4browser — Thu, 25 Jun 2026 10:28:21 +0000

Browser automation does not always fail because the script is wrong.

Sometimes the script opens the right page, uses the expected proxy, and finds a valid session. Then the task still breaks because the browser profile was changed by another teammate, reused by another worker, or recovered without review.

That is not only a scripting problem.

It is a permission problem.

When browser profiles become part of a team workflow, the question is no longer just:

Can this profile open the account?

The better question is:

Who can view it, open it, edit it, automate it, recover it, and approve exceptions?

A basic browser profile handoff model helps teams check whether a profile is ready for shared work. Before automation runs, that model needs one more layer: explicit permission rules.

Why browser profile permissions matter

A browser profile is not just a folder on disk.

In real workflows, it may contain or depend on:

cookies
local storage
extensions
proxy settings
timezone and language settings
account notes
profile tags
recent task history
automation locks
review status

That makes the profile an operational asset.

If anyone can change its proxy, clear storage, run a worker, or release a failed lock, the team may not know what changed before a failure.

The goal is not to make profiles impossible to use. The goal is to make each kind of action visible and controlled.

Split profile access into separate actions

A common mistake is giving users one broad permission:

Can this person open the profile?

That is too simple for automation.

A better model separates profile access into five actions:

Action	Meaning
View	Read profile metadata, owner, status, tags, and recent task history
Open	Launch the profile for manual work
Edit environment	Change proxy, fingerprint fields, region settings, notes, or tags
Run automation	Allow a worker, script, or agent to act from the profile
Recover	Release locks, approve reruns, quarantine, or restore the profile

These actions should not belong to the same role by default.

The safest person to inspect a profile is not always the right person to modify it.

The right worker to run a low-risk check is not always the right actor to approve recovery after a failed task.

A minimal role matrix

For a small team, the first version can be simple.

Role	View	Open	Edit environment	Run automation	Recover
Viewer	yes	no	no	no	no
Operator	yes	yes	no	no	no
Environment editor	yes	yes	yes	no	no
Automation runner	yes	limited	no	yes	no
Reviewer	yes	yes	no	limited	yes
Admin	yes	yes	yes	yes	yes

This table is not about job titles. It is about workflow boundaries.

A Playwright worker may only need a temporary checkout lease for one profile and one task.

A reviewer may not need to change proxy settings. But they may need to decide whether a failed run should be retried, skipped, or handled manually.

Model the profile as a controlled object

A lightweight manifest makes permission checks easier.

{
  "profile_id": "profile_usa_store_018",
  "account_id": "store_018",
  "owner": "ops-team-a",
  "region": "US",
  "proxy_policy": "fixed",
  "automation_allowed": true,
  "status": "ready",
  "risk_state": "normal",
  "last_task_id": "task_20260625_1042",
  "lock": {
    "locked": false,
    "locked_by": null,
    "expires_at": null
  },
  "permissions": {
    "view": ["viewer", "operator", "automation_runner", "reviewer", "admin"],
    "open": ["operator", "environment_editor", "reviewer", "admin"],
    "edit_environment": ["environment_editor", "admin"],
    "run_automation": ["automation_runner", "admin"],
    "recover": ["reviewer", "admin"]
  }
}

The exact schema can be different.

The important part is that the profile can answer basic questions before a task runs:

Does this profile have an owner?
Is automation allowed?
Is the profile ready?
Is the profile locked?
Is the profile quarantined?
Does this role have permission to run the task?

Without those answers, the worker is guessing.

Add a preflight check before opening the browser

Do not wait until the page is open to discover that the task should not run.

Run a preflight permission check first.

type Role =
  | "viewer"
  | "operator"
  | "environment_editor"
  | "automation_runner"
  | "reviewer"
  | "admin";

type ProfileStatus = "ready" | "in_review" | "quarantined";

interface ProfileManifest {
  profileId: string;
  owner: string | null;
  automationAllowed: boolean;
  status: ProfileStatus;
  lock?: {
    locked: boolean;
    lockedBy?: string;
    expiresAt?: string;
  };
  permissions: Record<string, Role[]>;
}

function checkAutomationPermission(
  profile: ProfileManifest,
  role: Role
): string[] {
  const errors: string[] = [];

  if (!profile.owner) {
    errors.push("Profile has no owner.");
  }

  if (!profile.automationAllowed) {
    errors.push("Automation is not allowed for this profile.");
  }

  if (profile.status !== "ready") {
    errors.push(`Profile is not ready. Current status: ${profile.status}.`);
  }

  if (profile.lock?.locked) {
    errors.push(`Profile is already locked by ${profile.lock.lockedBy}.`);
  }

  if (!profile.permissions.run_automation.includes(role)) {
    errors.push(`Role ${role} cannot run automation from this profile.`);
  }

  return errors;
}

A failed preflight check is not a runtime error.

It is a stop condition.

The worker should not open the browser, touch the profile, or retry with a different profile unless the routing layer explicitly allows it.

Where this check belongs

This check should run before creating the browser context.

In a queue-based workflow, place it after task routing but before profile checkout.

async function runBrowserTask(task: BrowserTask, workerRole: Role) {
  const profile = await loadProfileManifest(task.profileId);

  const permissionErrors = checkAutomationPermission(profile, workerRole);

  if (permissionErrors.length > 0) {
    await recordStopCondition({
      taskId: task.id,
      profileId: profile.profileId,
      reason: "permission_preflight_failed",
      errors: permissionErrors
    });

    return {
      status: "stopped",
      reason: "permission_preflight_failed",
      errors: permissionErrors
    };
  }

  const lease = await checkoutProfile(profile.profileId, task.id);

  try {
    return await runWorkerWithProfile(task, lease);
  } finally {
    await releaseProfileLease(lease.id);
  }
}

This keeps the worker from making unauthorized changes while still giving the queue a clear record of why the task did not run.

The important rule is simple:

Do not launch the profile until the task, role, lock, and profile state all agree.

Keep environment edits out of normal automation runs

Automation should not inherit every permission a human operator has.

In most team workflows, a worker should be able to:

check out an approved profile
open the assigned page
perform allowed actions
save task evidence
return a task result

It should not automatically be able to:

change proxy settings
clear cookies
change timezone
modify fingerprint fields
release stale locks
retry indefinitely
approve its own exception

That separation reduces drift.

A failed task should not make the profile harder to debug.

Log the permission decision

Every automation checkout should leave an audit event.

{
  "event_type": "profile_automation_checkout",
  "task_id": "task_20260625_1042",
  "profile_id": "profile_usa_store_018",
  "requested_by": "worker_07",
  "requested_role": "automation_runner",
  "decision": "approved",
  "checks": {
    "profile_owner_present": true,
    "automation_allowed": true,
    "profile_ready": true,
    "lock_available": true,
    "role_allowed": true
  },
  "timestamp": "2026-06-25T10:42:11Z"
}

This does not need to be heavy.

The event only needs to answer the questions teams ask after something breaks:

Which profile did the task use?
Was the profile ready?
Was another worker using it?
Did the worker have permission?
Was a stop condition overridden?
Who approved the recovery?

If the answer only exists in Slack, chat notes, or memory, the workflow is fragile.

Quarantine profiles after unsafe failures

Not every failed task should return the profile to the ready pool.

Some failures should move the profile into review.

Examples:

login state changed unexpectedly
proxy region no longer matches the profile policy
the page requested extra verification
the worker submitted the wrong form
the worker lost the profile lock
the task stopped on a permission-sensitive page
the output destination is unclear

A simple state model helps:

ready
  -> checked_out
  -> completed
  -> ready

checked_out
  -> failed
  -> in_review
  -> ready

checked_out
  -> unsafe_failure
  -> quarantined
  -> reviewer_approved
  -> ready

The key point is simple:

Retry should not be the default recovery strategy.

Sometimes the safest next action is to stop, preserve evidence, and ask a reviewer to decide.

Rollout checklist

You do not need a full permission system on day one.

Start with a small version:

Add an owner to every profile.
Separate open permission from edit permission.
Require a checkout lock before automation starts.
Log every automation checkout decision.
Create an in-review state for failed tasks.
Prevent automation from editing proxy or fingerprint settings by default.
Require reviewer approval for reruns after unsafe failures.

This turns browser profiles from private habits into shared operational assets.

Final check before automation runs

Before letting automation use shared browser profiles, ask:

Can we identify the owner of this profile?
Can we tell which account it belongs to?
Can we tell whether automation is allowed?
Can we prevent two workers from using it at once?
Can we stop automation from changing environment settings?
Can we preserve evidence after failure?
Can a reviewer decide whether to retry, recover, or quarantine?
Can we explain later why the task was allowed to run?

If the answer is no, the automation stack is missing a control layer.

Playwright, Puppeteer, RPA tools, and AI agents can operate the browser. The team still needs a reliable way to decide which profile can be used, under which role, with which limits, and with what evidence left behind.

For teams comparing this model with an integrated browser workflow, the related Web4 Browser product area is the AI collaboration workspace, where profiles, tasks, logs, exceptions, and review boundaries are treated as part of the same workflow.

The model above does not depend on any specific tool. The core idea is to make browser profile access explicit before automation runs.

Editorial note: This article was drafted with AI assistance and reviewed by the Web4 Browser team for technical accuracy and relevance.

Using Routing Keys and Profile Leases in Playwright Worker Queues

web4browser — Wed, 24 Jun 2026 03:10:53 +0000

The failure did not come from a selector.

Two workers picked jobs for the same account. Both opened automation tasks against the same persistent browser profile. One task was still waiting on a slow page. The other retried, changed the session state, and wrote a clean-looking failure log.

By the time someone inspected the run, the Playwright error only said:

TimeoutError: page.click failed

That was technically true.

It was also not the root problem.

The root problem was that the queue treated browser profile work like stateless background work.

A worker queue is easy to design when jobs are stateless:

take next job
find available worker
run task
mark done

That model works for screenshots, exports, report generation, image processing, and many API jobs.

It becomes fragile when the job opens a real browser profile.

A Playwright worker may not only be opening a page. It may be operating inside a profile that belongs to one account, one proxy route, one session state, one task history, and one review workflow.

In that case, the fastest available worker is not always the correct worker.

For profile-based browser automation, the queue should route by account context, not worker speed.

The snippets below are pseudo-code. The same model can be implemented with BullMQ, Temporal, Redis, Postgres advisory locks, Sidekiq, Celery, or another queue system.

Why speed-first routing breaks

A simple worker loop often starts like this:

while (true) {
  const job = await queue.next();
  const worker = await pool.firstAvailable();

  await worker.run(job);
}

This is fine if every worker can run every job.

But browser profile automation has hidden state.

A job may require:

{
  "accountId": "store-us-018",
  "profileId": "profile-store-us-018",
  "expectedProxyRegion": "US",
  "sessionMode": "persistent",
  "taskType": "daily_status_check"
}

That job should not run on any free worker.

It should run only when the correct account environment is available, the profile is not already in use, the expected proxy context still matches, and the previous run does not require human review.

A speed-first queue asks:

Which worker is free?

An account-aware queue asks:

Which account environment is safe to operate now?

Those are different scheduling problems.

Make account context part of the job

A queue cannot route by account context unless the job carries enough context.

At minimum, a browser automation job should include account identity, profile identity, task intent, run mode, retry rules, and an idempotency key.

type BrowserJob = {
  jobId: string;
  accountId: string;
  profileId: string;
  taskType: string;

  expectedProxyRegion?: string;
  expectedLanguage?: string;
  expectedTimezone?: string;

  runMode: "visible" | "headless";
  riskLevel: "low" | "medium" | "review_required";

  idempotencyKey: string;
  createdAt: string;
};

The important shift is simple.

Instead of saying:

Run this browser task.

The queue should know:

Run this task for this account, inside this profile, under this expected environment, unless the account state says to stop.

That sentence is the real routing contract.

For a broader framing of this problem, this related article explains why account context for browser automation matters beyond the browser window itself.

Route by account or profile

The scheduler needs a routing key.

The safest default is usually the browser profile:

function routingKey(job: BrowserJob) {
  return `profile:${job.profileId}`;
}

That prevents two workers from using the same profile at the same time.

In some systems, the account is the better boundary:

function routingKey(job: BrowserJob) {
  return `account:${job.accountId}`;
}

That prevents two different profiles from touching the same account in parallel.

For read-only tasks, you may eventually allow narrower routing:

function routingKey(job: BrowserJob) {
  return `account:${job.accountId}:task:${job.taskType}`;
}

Start strict.

A slow but safe scheduler is easier to improve than a fast scheduler that corrupts session state.

Add a profile lease

A queue claim and a profile lease are not the same thing.

A queue claim means:

This worker owns this job.

A profile lease means:

This worker is allowed to use this browser profile for a limited time.

A worker can own a job and still fail to get the profile. Another job may already be using it. The account may be paused. A previous run may have left the profile in a review-required state.

A minimal lease can look like this:

async function checkoutProfile(job: BrowserJob) {
  const leaseKey = `profile:${job.profileId}`;

  const lease = await locks.acquire(leaseKey, {
    ttlMs: 15 * 60 * 1000,
    metadata: {
      jobId: job.jobId,
      accountId: job.accountId,
      taskType: job.taskType
    }
  });

  if (!lease.ok) {
    throw new Error("PROFILE_ALREADY_LEASED");
  }

  return lease;
}

The lease should expire automatically. It should also be released explicitly.

const lease = await checkoutProfile(job);

try {
  await runBrowserTask(job);
} finally {
  await lease.release();
}

This gives the queue a clean concurrency boundary.

It also gives the team an audit point: which worker used which profile, for which job, and when.

Handle lease renewal and stale workers

A fixed lease TTL is only safe for short tasks.

Real browser jobs can take longer than expected. A page may load slowly. A file export may take several minutes. A human review step may pause the flow. If the lease expires while the worker is still running, another worker may acquire the same profile.

That brings back the original problem.

For longer jobs, add lease renewal.

async function runWithLeaseRenewal(job: BrowserJob) {
  const lease = await checkoutProfile(job);

  const heartbeat = setInterval(async () => {
    await lease.extend({
      ttlMs: 15 * 60 * 1000
    });
  }, 60 * 1000);

  try {
    await runBrowserTask(job);
  } finally {
    clearInterval(heartbeat);
    await lease.release();
  }
}

This is still not enough.

You also need to protect against stale workers.

A stale worker is a worker that lost the lease, kept running, and later tried to write results. This can happen after a pause, crash recovery, network split, or slow event loop.

One way to reduce the risk is to use a fencing token.

When the worker acquires the lease, the lock service returns a monotonic token.

type ProfileLease = {
  id: string;
  profileId: string;
  fencingToken: number;
  release: () => Promise<void>;
  extend: (input: { ttlMs: number }) => Promise<void>;
};

Every important write includes that token.

await evidence.write({
  jobId: job.jobId,
  profileId: job.profileId,
  leaseId: lease.id,
  fencingToken: lease.fencingToken,
  result: "completed"
});

The storage layer rejects writes from an older token.

async function writeEvidence(event: EvidenceEvent) {
  const currentLease = await leases.currentForProfile(event.profileId);

  if (event.fencingToken < currentLease.fencingToken) {
    throw new Error("STALE_WORKER_WRITE_REJECTED");
  }

  await evidenceStore.insert(event);
}

This does not make distributed systems magical.

It does make one important rule explicit:

A worker that no longer owns the profile should not be allowed to write final state for that profile.

That rule matters when browser profiles represent account state.

Gate account readiness before launching Playwright

Do not wait for Playwright to fail before discovering that the account was not ready.

Before opening the browser, run a readiness check.

async function validateAccountReadiness(job: BrowserJob) {
  const account = await accounts.get(job.accountId);
  const profile = await profiles.get(job.profileId);

  if (account.status === "paused") {
    return { ok: false, reason: "ACCOUNT_PAUSED" };
  }

  if (profile.reviewRequired) {
    return { ok: false, reason: "PROFILE_REVIEW_REQUIRED" };
  }

  if (
    job.expectedProxyRegion &&
    profile.proxyRegion !== job.expectedProxyRegion
  ) {
    return { ok: false, reason: "PROXY_REGION_MISMATCH" };
  }

  return { ok: true };
}

This check is boring.

That is why it is useful.

Many browser automation failures do not need a dramatic fix. They need the system to stop before a predictable mismatch becomes a noisy run.

Classify blocked jobs

A blocked job is not always a failed job.

It may be blocked because:

blocked_by_profile_lease
blocked_by_account_pause
blocked_by_proxy_mismatch
blocked_by_review_required
blocked_by_duplicate_idempotency_key

Each reason should lead to a different action.

A profile lease conflict can be retried later.
A proxy mismatch should stop until configuration is fixed.
A review-required state should move to a human queue.
A duplicate idempotency key should be marked as already handled.

A simple scheduling function might look like this:

async function schedule(job: BrowserJob) {
  const readiness = await validateAccountReadiness(job);

  if (!readiness.ok) {
    await queue.moveToBlocked(job, readiness.reason);
    return;
  }

  await queue.enqueueByRoutingKey(job, {
    routingKey: `profile:${job.profileId}`
  });
}

The goal is not to run every job immediately.

The goal is to run the right job in the right account environment.

Make retries context-aware

Retries are dangerous in browser automation.

If a task fails because of a temporary navigation issue, a retry may help.

If it fails because the account is logged out, the proxy changed, or a review screen appeared, an automatic retry may make the state worse.

Retry rules should inspect failure reasons.

function shouldRetry(event: TaskFailureEvent) {
  if (event.reason === "TIMEOUT") return true;
  if (event.reason === "TEMPORARY_NAVIGATION_ERROR") return true;

  if (event.reason === "LOGIN_REQUIRED") return false;
  if (event.reason === "PROFILE_MISMATCH") return false;
  if (event.reason === "PROXY_REGION_MISMATCH") return false;
  if (event.reason === "HUMAN_REVIEW_REQUIRED") return false;

  return false;
}

A retry counter is not enough.

The scheduler should know whether the failure belongs to the page, the browser, the profile, the account, or the workflow.

Log scheduling evidence, not only Playwright errors

Many systems log Playwright errors but forget to log scheduling decisions.

That makes debugging harder.

When a task stops, the team should be able to inspect a record like this:

{
  "jobId": "job-2026-06-23-001",
  "routingKey": "profile:profile-store-us-018",
  "accountId": "store-us-018",
  "profileId": "profile-store-us-018",
  "workerId": "worker-04",
  "leaseId": "lease-8731",
  "fencingToken": 42,
  "runMode": "headless",
  "expectedProxyRegion": "US",
  "actualProxyRegion": "US",
  "result": "blocked",
  "stopReason": "LOGIN_REQUIRED"
}

This tells a better story than:

TimeoutError: page.click failed

A Playwright error tells you what the script saw.

A scheduling record tells you whether the task should have been running in that account environment at all.

That is the missing layer in many worker queue designs.

A minimal account-aware worker flow

Putting the pieces together, the flow looks like this:

async function handleBrowserJob(job: BrowserJob) {
  const readiness = await validateAccountReadiness(job);

  if (!readiness.ok) {
    await evidence.write({
      jobId: job.jobId,
      accountId: job.accountId,
      profileId: job.profileId,
      result: "blocked",
      reason: readiness.reason
    });

    return;
  }

  const lease = await checkoutProfile(job);

  try {
    await evidence.write({
      jobId: job.jobId,
      accountId: job.accountId,
      profileId: job.profileId,
      result: "started",
      leaseId: lease.id,
      fencingToken: lease.fencingToken
    });

    await runWithPlaywright(job);

    await evidence.write({
      jobId: job.jobId,
      profileId: job.profileId,
      leaseId: lease.id,
      fencingToken: lease.fencingToken,
      result: "completed"
    });
  } catch (err) {
    const reason = classifyBrowserFailure(err);

    await evidence.write({
      jobId: job.jobId,
      profileId: job.profileId,
      leaseId: lease.id,
      fencingToken: lease.fencingToken,
      result: "failed",
      reason
    });

    if (shouldRetry({ reason })) {
      await queue.retryLater(job);
    } else {
      await queue.moveToReview(job, reason);
    }
  } finally {
    await lease.release();
  }
}

The queue library is not the main point.

The important boundary is this:

job
  -> readiness gate
  -> routing key
  -> profile lease
  -> lease heartbeat
  -> Playwright run
  -> evidence log

That boundary keeps profile state from being treated as disposable worker state.

Where the workspace layer fits

This pattern is tool-agnostic.

You can build the scheduler yourself. You can also move more of this logic into a browser automation workspace.

The hard part is keeping account identity, browser profile, proxy context, session state, task history, and review decisions close enough that the scheduler can make safe decisions.

A workspace-style browser automation layer can help here when it keeps profiles, proxy mapping, task logs, and review states close to the scheduler.

This is also the direction Web4 Browser is exploring: keeping profiles, proxy mapping, task logs, review states, and repeatable workflows closer to the automation layer.

More workers make the system faster.

Account-aware scheduling makes it safer to scale.

Final checklist

Before scaling Playwright workers across persistent browser profiles, check these points:

[ ] Every browser job includes accountId and profileId.
[ ] The queue has a routing key based on account or profile.
[ ] Two workers cannot use the same profile at the same time.
[ ] Long-running jobs renew profile leases.
[ ] Stale workers cannot write final state after losing a lease.
[ ] The scheduler checks account readiness before launching Playwright.
[ ] Environment expectations are visible to the job.
[ ] Retries depend on failure reason, not only retry count.
[ ] Each run records worker ID, profile ID, routing key, lease ID, fencing token, and stop reason.

A browser worker queue should not only ask which worker is free.

It should ask which account context is ready.

That is the difference between running jobs faster and running profile automation with control.

Building a Browser Profile Checkout Flow Before Launching Playwright Workers

web4browser — Mon, 22 Jun 2026 07:00:12 +0000

A Playwright worker should not pick a browser profile the same way it picks an available CPU slot.

That works for stateless tests.

It breaks when the task depends on a real account environment.

A worker may be free, but the profile may not be. The profile may already be running in another task. The account may be logged out. The proxy may have changed. The last run may have failed on a verification page. A teammate may have opened the same profile manually five minutes ago.

If the worker starts anyway, the failure usually looks like a timeout, a selector problem, or a flaky login step.

The real problem happened earlier.

The profile was never checked out.

This article is not only about profile locking. It treats checkout as a full admission gate before real-account workers run.

Profile checkout is an admission gate

A profile checkout flow is a pre-launch gate for browser automation.

Before a worker receives a page or browser context, the system confirms that the intended profile is safe to use for the task.

The checkout flow should answer:

Is this the correct profile for this account?
Is the profile already locked by another worker?
Does the profile match the task’s platform and account?
Is the session ready, expired, challenged, or unknown?
Do proxy region, timezone, and language still match the expected environment?
Is there a directory for logs, screenshots, traces, and stop reasons?
Should the task run, wait, route to review, or quarantine the profile?

This is closer to checking out a deployment environment, a test device, or a database migration lock than simply launching a browser.

Why Playwright workers need this step

Playwright makes it easy to launch a browser, attach to an existing browser, or use a persistent context.

That convenience can hide an important detail: persistent browser state is not just a launch option. It is part of the task boundary.

Playwright’s BrowserType API reference documents both launchPersistentContext() and connectOverCDP(). The first uses a user data directory for persistent browser state. The second attaches to an existing Chromium instance over Chrome DevTools Protocol.

So if your automation uses real account state, a profile cannot be treated as a disposable folder.

The worker should not begin until the profile has passed checkout.

The safer worker pipeline

A safer pipeline looks like this:

Task queue
  -> choose task
  -> checkout profile
  -> validate account context
  -> launch or attach browser
  -> run worker
  -> write evidence
  -> release, review, or quarantine profile

The important change is simple:

Worker execution starts after checkout, not before it.

Start with a checkout manifest

A checkout manifest describes what the worker expects before it opens the page.

{
  "taskId": "task_20260622_001",
  "profileId": "profile_us_store_018",
  "accountId": "store_018",
  "platform": "example-dashboard",
  "expectedProxyRegion": "US",
  "expectedTimezone": "America/New_York",
  "expectedLanguage": "en-US",
  "entryUrl": "https://example.com/dashboard",
  "requiresLoggedInSession": true,
  "allowHeadless": true,
  "evidenceDir": "runs/20260622/task_20260622_001",
  "onCheckoutFailure": "human_review"
}

This is not meant to be a perfect schema.

It is meant to stop vague execution.

A logged-in browser task should not receive only this:

{
  "url": "https://example.com/dashboard"
}

A URL is not enough.

The worker needs account context, profile ownership, expected environment, and an evidence path.

For teams that still mix cookies, sessions, and profiles loosely, it helps to first separate those layers. This related note on cookie, session, and browser profile separation is a useful model before building the checkout gate.

Gate 1: reserve the profile

The first gate is a lease.

Do not let two workers use the same profile unless your system explicitly supports that mode.

This is not just a workflow preference. Playwright’s documentation for persistent contexts notes that browsers do not allow launching multiple instances with the same user data directory. In worker-based systems, that makes a lease part of the safety model, not an optional optimization.

A simple lease record can look like this:

{
  "profileId": "profile_us_store_018",
  "lockedBy": "worker_03",
  "taskId": "task_20260622_001",
  "lockedAt": "2026-06-22T14:00:00Z",
  "leaseUntil": "2026-06-22T14:10:00Z"
}

The lease should have a TTL because workers crash.

The release step should be explicit because tasks fail.

The examples below assume your own Task, Page, ProfileMetadata, CheckoutError, and registry types.

type ProfileLease = {
  profileId: string;
  accountId: string;
  cdpEndpoint?: string;
  userDataDir?: string;
  lockedBy: string;
  leaseUntil: string;
};

async function reserveProfile(task: Task): Promise<ProfileLease | null> {
  const profile = await profileRegistry.findByAccount(task.accountId);

  if (!profile) return null;
  if (profile.locked && !profile.leaseExpired) return null;
  if (profile.status === "quarantined") return null;

  return profileRegistry.lock(profile.id, {
    lockedBy: task.workerId,
    taskId: task.id,
    ttlSeconds: 600
  });
}

No lease, no worker run.

Gate 2: confirm the profile matches the task

After reserving the profile, confirm that it belongs to the task.

This sounds obvious, but many automation bugs come from weak naming and loose routing.

Check:

profile ID
account ID
platform
project or group
expected region
allowed task type
current profile status

function assertProfileMatchesTask(lease: ProfileLease, task: Task) {
  if (lease.accountId !== task.accountId) {
    throw new CheckoutError("account_mismatch");
  }

  if (task.allowedProfileIds && !task.allowedProfileIds.includes(lease.profileId)) {
    throw new CheckoutError("profile_not_allowed_for_task");
  }
}

Do not rely only on a visible profile name.

Names drift.

IDs should be stable.

Gate 3: attach to the intended runtime

Teams usually use one of two patterns.

The first pattern is a persistent context:

const context = await chromium.launchPersistentContext(lease.userDataDir!, {
  headless: task.allowHeadless
});

The second pattern is attaching to a running managed browser profile:

const browser = await chromium.connectOverCDP(lease.cdpEndpoint!);
const context = browser.contexts()[0];
const page = context.pages()[0] ?? await context.newPage();

The checkout system should know which pattern it is using.

Do not silently fall back to a fresh context.

A fresh context may pass basic page tests, but it will not contain the account state that the task expects.

if (!context) {
  throw new CheckoutError("missing_browser_context");
}

A worker should fail early when it cannot prove that it attached to the intended runtime.

Gate 4: probe session state

Stored cookies do not always mean a usable session.

The worker should open the entry page and classify what the profile sees.

type SessionState =
  | "ready"
  | "logged_out"
  | "needs_review"
  | "unexpected_account"
  | "unknown";

async function probeSession(page: Page, task: Task): Promise<SessionState> {
  await page.goto(task.entryUrl, { waitUntil: "domcontentloaded" });

  const loginVisible = await page
    .getByText(/log in|sign in/i)
    .first()
    .isVisible({ timeout: 3000 })
    .catch(() => false);

  if (loginVisible) return "logged_out";

  const reviewVisible = await page
    .getByText(/verify|verification|captcha|two-factor/i)
    .first()
    .isVisible({ timeout: 3000 })
    .catch(() => false);

  if (reviewVisible) return "needs_review";

  const expectedAccountVisible = await page
    .getByText(task.expectedAccountLabel)
    .first()
    .isVisible({ timeout: 3000 })
    .catch(() => false);

  if (!expectedAccountVisible) return "unknown";

  return "ready";
}

This probe does not need to solve every case.

It only needs to stop unsafe runs.

A checkout flow should fail closed when the profile state is unclear.

Add policy boundaries to the workflow

A profile checkout gate should also protect the team from running the wrong kind of automation.

For authorized QA, monitoring, internal operations, and repetitive account-management tasks, checkout makes automation safer and easier to debug.

It should not be used to bypass platform rules, ignore verification flows, or continue running when a page clearly needs human review.

That is why the safest checkout result is sometimes not “run.”

It is “stop and review.”

Gate 5: verify environment consistency

For real account workflows, the profile is not only about cookies.

It often includes proxy route, timezone, language, extension state, local storage, permissions, and other environment settings.

Before running a worker, compare the manifest with current profile metadata.

function verifyEnvironment(profile: ProfileMetadata, task: Task) {
  const failures: string[] = [];

  if (profile.proxyRegion !== task.expectedProxyRegion) {
    failures.push("proxy_region_mismatch");
  }

  if (profile.timezone !== task.expectedTimezone) {
    failures.push("timezone_mismatch");
  }

  if (profile.language !== task.expectedLanguage) {
    failures.push("language_mismatch");
  }

  return failures;
}

Do not automatically “fix” everything during checkout.

A worker that changes proxy region or timezone right before a logged-in task may create a bigger account-context problem.

Checkout should classify the state first.

Then the system can decide whether to run, wait, or route to human review.

Gate 6: prepare evidence before execution

Evidence should be ready before the first click.

At minimum, create a run directory like this:

runs/
  20260622/
    task_20260622_001/
      checkout.json
      profile_manifest.json
      session_probe.png
      worker.log
      final_state.json

The approved checkout record can look like this:

{
  "checkoutStatus": "approved",
  "profileId": "profile_us_store_018",
  "taskId": "task_20260622_001",
  "sessionState": "ready",
  "environmentFailures": [],
  "startedAt": "2026-06-22T14:00:05Z"
}

If checkout fails, still write evidence.

{
  "checkoutStatus": "blocked",
  "reason": "needs_review",
  "profileId": "profile_us_store_018",
  "taskId": "task_20260622_001",
  "screenshot": "session_probe.png"
}

A blocked checkout with evidence is more useful than a failed worker with no context.

Put the gates behind a wrapper

Here is a simplified checkout wrapper.

async function checkoutProfileForWorker(task: Task) {
  const lease = await reserveProfile(task);

  if (!lease) {
    return {
      ok: false,
      action: "requeue",
      reason: "profile_unavailable"
    };
  }

  try {
    assertProfileMatchesTask(lease, task);

    const runtime = await attachRuntime(lease, task);
    const page = await getOrCreatePage(runtime.context);

    const sessionState = await probeSession(page, task);

    if (sessionState !== "ready") {
      await evidence.captureCheckoutFailure(task, lease, page, sessionState);

      await profileRegistry.markNeedsReview(lease.profileId, {
        reason: sessionState,
        taskId: task.id
      });

      return {
        ok: false,
        action: "human_review",
        reason: sessionState
      };
    }

    const profileMeta = await profileRegistry.getMetadata(lease.profileId);
    const envFailures = verifyEnvironment(profileMeta, task);

    if (envFailures.length > 0) {
      await evidence.writeJson(task.evidenceDir, "checkout.json", {
        checkoutStatus: "blocked",
        reason: "environment_mismatch",
        failures: envFailures
      });

      return {
        ok: false,
        action: "human_review",
        reason: "environment_mismatch",
        failures: envFailures
      };
    }

    await evidence.writeJson(task.evidenceDir, "checkout.json", {
      checkoutStatus: "approved",
      profileId: lease.profileId,
      taskId: task.id,
      sessionState,
      startedAt: new Date().toISOString()
    });

    return {
      ok: true,
      lease,
      runtime,
      page
    };
  } catch (error) {
    await evidence.writeJson(task.evidenceDir, "checkout_error.json", {
      message: String(error),
      taskId: task.id,
      profileId: lease.profileId
    });

    await profileRegistry.markNeedsReview(lease.profileId, {
      reason: "checkout_error",
      taskId: task.id
    });

    return {
      ok: false,
      action: "human_review",
      reason: "checkout_error"
    };
  }
}

Then the worker becomes simpler.

const checkout = await checkoutProfileForWorker(task);

if (!checkout.ok) {
  await queue.route(task, checkout.action, checkout.reason);
  return;
}

try {
  await runTaskWithPage(checkout.page, task);

  await evidence.writeJson(task.evidenceDir, "final_state.json", {
    status: "completed",
    completedAt: new Date().toISOString()
  });
} catch (error) {
  await evidence.captureWorkerFailure(task, checkout.page, error);

  await profileRegistry.markNeedsReview(checkout.lease.profileId, {
    reason: "worker_failed",
    taskId: task.id
  });
} finally {
  await profileRegistry.release(checkout.lease.profileId, task.id);
}

The worker no longer decides whether the profile is safe.

It only runs after the gate approves the environment.

Use clear checkout failure reasons

A checkout flow should return reasons that help the queue decide what happens next.

profile_unavailable
  Another worker owns the lease. Requeue the task.

account_mismatch
  The profile does not belong to the requested account. Stop.

logged_out
  The account needs manual login or a separate login workflow.

needs_review
  Verification, challenge, CAPTCHA, or unusual page state appeared.

environment_mismatch
  Proxy, region, timezone, or language no longer matches the manifest.

missing_browser_context
  The worker attached to the wrong runtime or created a fresh context.

evidence_not_ready
  The worker cannot write logs or screenshots. Fail before execution.

These reasons are more useful than a generic timeout.

Some tasks should be retried.

Some should be reviewed.

Some should quarantine the profile until a human checks the account environment.

Release is part of checkout

Checkout is not finished when the worker starts.

The profile must be released with a final status.

{
  "profileId": "profile_us_store_018",
  "taskId": "task_20260622_001",
  "releaseStatus": "needs_review",
  "lastKnownUrl": "https://example.com/verify",
  "finalScreenshot": "final_state.png",
  "completedAt": "2026-06-22T14:03:44Z"
}

A profile that ended on a verification page should not immediately return to the ready pool.

A profile that failed because of an environment mismatch should not be picked by the next worker.

A profile that completed successfully can be released normally.

This is how checkout becomes a state machine, not just a preflight function.

The practical rule

Do not route logged-in browser automation by worker availability alone.

Route it by account context.

A safe task needs:

task intent
+ profile ownership
+ session state
+ environment consistency
+ evidence path
+ release rule

Only then should a Playwright worker run.

This is why browser automation teams eventually outgrow loose scripts and shared profile folders. They need a workflow layer where profiles, proxies, headless runs, logs, and review states are managed together.

Teams that do not want to hard-code this layer into every script usually move toward a shared headless browser automation workspace.

The important shift is not “more workers.”

It is safer admission control before workers touch real account environments.

When a Browser Profile Should Be Quarantined After Automation Failure

web4browser — Sat, 20 Jun 2026 12:37:21 +0000

A browser profile lease solves a concurrency problem.

It answers:

Which worker is allowed to use this profile right now?

But after an automation failure, another question appears:

Is this profile still safe to reuse?

Those are not the same question.

A worker can release a lease correctly while still leaving the browser profile in an unknown state. The profile may contain changed cookies, refreshed tokens, modified local storage, a pending verification screen, an unfinished form, or a task result that nobody recorded.

If the scheduler immediately gives that profile to the next worker, the next run may not start from a clean account environment.

It may inherit damage from the previous failure.

That is why some failed profiles should not go directly back into the available pool.

They should be quarantined.

A lease is not a trust decision

A profile lease is about ownership.

It prevents two workers from opening the same profile at the same time. That matters, but it does not prove the profile is healthy after a failed run.

Quarantine is different. It is a post-failure state.

It means:

This profile was touched by a failed run, and we do not yet trust its account, session, environment, or task state.

In browser automation, a profile is not just a folder on disk. It can carry cookies, local storage, login state, permissions, extensions, proxy assumptions, language settings, and recent task history.

That is why debugging automation failures often requires looking beyond the script. You need to understand the account context in browser automation, not just the exception message.

What profile quarantine means

Quarantine does not mean deleting the profile.

It means temporarily removing the profile from normal scheduling until a review or recovery process decides what should happen next.

A quarantined profile should not be picked by:

a normal retry
another worker
a background status check
a headless task
an AI agent run
a teammate looking for any available profile

Instead, the profile should carry a reason, evidence, and a required next action.

For example:

{
  "profile_id": "profile_042",
  "status": "quarantined",
  "reason": "worker_crash_after_authenticated_action",
  "failed_run_id": "run_2026_06_20_018",
  "last_step": "submit_account_update",
  "last_known_url": "https://example.com/dashboard",
  "session_state": "unknown",
  "evidence": {
    "screenshot": true,
    "console_log": true,
    "network_summary": true,
    "worker_exit_code": 137
  },
  "review_required": true
}

The schema can vary.

The important part is that your system has a state between available and broken.

That state is quarantined.

When a failure does not need quarantine

Not every failure should quarantine a profile.

Quarantine is usually unnecessary if:

the browser never launched
the profile was never opened
the worker failed before acquiring the lease
the run only touched public pages
the failure was clearly outside the browser profile
the browser closed cleanly and evidence is complete

The key question is not:

Did the task fail?

The better question is:

Did the failed run leave the profile in a state that the next run cannot safely explain?

If the profile was never touched, it usually does not need review.

If account state, session state, or profile storage may have changed, it should not be reused blindly.

Quarantine after authenticated state is reached

Quarantine becomes more important after login.

Before login, many failures are just infrastructure failures: DNS errors, launch errors, dependency problems, proxy connection failures, or selector misses on public pages.

After login, the browser is interacting with account state.

Quarantine is usually appropriate when failure happens after:

the account dashboard loaded
a session refresh occurred
a form was filled
a file was uploaded
an account setting changed
a message was drafted
a checkout or submission flow started
an agent interpreted an account-specific page
a headless task continued without visual review

The risk is not only that the task failed.

The risk is that the next run may continue from a state the scheduler does not understand.

Quarantine when session state may have changed

Some failures are dangerous because they make session state uncertain.

Examples:

the page asked for login again
a verification prompt appeared
the account was redirected to a warning page
the session expired halfway through the task
a token refresh failed
local storage changed during the run
cookies changed right before the crash
the automation cleared or modified browser data
the task appeared to switch accounts unexpectedly

A profile can still open successfully while being unsafe for the next task.

That is the trap.

“Profile opens” does not mean “profile is trusted.”

Quarantine when the environment changed mid-run

Browser automation often assumes that the profile, proxy, timezone, language, and region are consistent.

If those assumptions changed during the failed run, the profile should not return directly to the pool.

Quarantine is appropriate when:

the proxy failed mid-run
the worker retried through a different proxy
the exit region did not match the expected profile region
timezone or language settings changed
a mismatch was detected but the workflow continued
the task ran with an environment different from the assigned account context

A scheduler that only checks locked = false will miss this.

A better scheduler asks whether the profile environment is still coherent.

Quarantine when the worker crashed while the browser was open

A worker crash is one of the clearest quarantine signals.

A crash means the automation may not have executed its cleanup path.

The worker may have failed to:

close the page correctly
save final evidence
mark the task result
record the last visible URL
detect a stop screen
restore temporary settings
write the final session state

A normal retry assumes the previous run ended in a known state.

A worker crash means the final state is unknown.

Unknown does not always mean corrupted. But unknown is enough to quarantine until someone or something checks it.

Quarantine near non-idempotent actions

Some browser actions are safe to repeat.

Opening a page is usually safe. Reading a dashboard is usually safe. Taking a screenshot is usually safe.

Other actions are not safe to repeat without context.

Examples:

submitting a form
sending a message
changing account settings
uploading a file
deleting or archiving something
approving a workflow
confirming a payment-related step
accepting a prompt that changes account state

If automation fails near a non-idempotent action, do not immediately retry with the same profile.

Ask first:

Did the action already happen?
Did the website accept the request before the crash?
Did the UI fail to show confirmation even though the backend accepted it?
Would a retry duplicate the action?
Would the next worker understand the current page?

If the answer is unknown, quarantine the profile.

Quarantine when evidence is incomplete

Sometimes the failure is not the biggest problem.

The missing evidence is.

A failed run should leave enough information for the next operator to understand what happened.

At minimum, capture:

profile ID
run ID
worker ID
lease start and end time
last step name
last URL
screenshot
visible account state
proxy ID and region
relevant console errors
network failure summary
retry count
stop reason
browser close status

If the evidence bundle is incomplete, quarantine is safer than reuse.

Without evidence, the next run is not debugging.

It is guessing.

A Playwright example

With Playwright, this problem often appears when using a persistent profile directory.

For example:

import { chromium, type BrowserContext } from "playwright";

type ProfileRunResult = {
  openedProfile: boolean;
  reachedAuthenticatedArea: boolean;
  workerCrashed: boolean;
  browserClosedCleanly: boolean;
  evidenceComplete: boolean;
  sessionStateChanged: boolean;
  environmentChanged: boolean;
  nearNonIdempotentAction: boolean;
};

function shouldQuarantine(result: ProfileRunResult): boolean {
  if (!result.openedProfile) return false;

  if (result.workerCrashed) return true;
  if (!result.browserClosedCleanly) return true;
  if (!result.evidenceComplete) return true;

  if (!result.reachedAuthenticatedArea) {
    return false;
  }

  return (
    result.sessionStateChanged ||
    result.environmentChanged ||
    result.nearNonIdempotentAction
  );
}

async function runWithPersistentProfile(profilePath: string) {
  let context: BrowserContext | undefined;
  let browserClosedCleanly = false;

  const result: ProfileRunResult = {
    openedProfile: false,
    reachedAuthenticatedArea: false,
    workerCrashed: false,
    browserClosedCleanly: false,
    evidenceComplete: false,
    sessionStateChanged: false,
    environmentChanged: false,
    nearNonIdempotentAction: false
  };

  try {
    context = await chromium.launchPersistentContext(profilePath, {
      headless: false
    });

    result.openedProfile = true;

    const page = await context.newPage();

    await page.goto("https://example.com/dashboard");
    result.reachedAuthenticatedArea = true;

    // After this point, the run is touching account state.
    await page.getByRole("button", { name: "Update settings" }).click();
    result.nearNonIdempotentAction = true;

    await page.screenshot({ path: "evidence/final.png", fullPage: true });
    result.evidenceComplete = true;
  } catch (error) {
    await saveFailureEvidence(error);
    result.evidenceComplete = true;
    throw error;
  } finally {
    if (context) {
      try {
        await context.close();
        browserClosedCleanly = true;
      } catch (closeError) {
        await saveFailureEvidence(closeError);
      }
    }

    result.browserClosedCleanly = browserClosedCleanly;

    if (shouldQuarantine(result)) {
      await markProfileAsQuarantined(profilePath, result);
    } else {
      await markProfileAsAvailable(profilePath);
    }
  }
}

async function saveFailureEvidence(error: unknown) {
  console.error("Saving failure evidence", error);
}

async function markProfileAsQuarantined(
  profilePath: string,
  result: ProfileRunResult
) {
  console.log("Quarantine profile", profilePath, result);
}

async function markProfileAsAvailable(profilePath: string) {
  console.log("Release profile", profilePath);
}

The exact implementation will depend on your scheduler, queue, and profile store.

The main point is the placement.

Do not only release the profile in finally.

First decide whether the failed run changed the trust level of that profile.

In a real worker pool, workerCrashed is usually set by the supervisor process, not by the page task itself. A page task can report what it observed, but the supervisor is usually the component that knows whether the process crashed, timed out, or was killed.

Use profile states, not just locks

A simple scheduler may treat profiles as either locked or unlocked.

That model is too small for multi-account automation.

A more useful model looks like this:

available
leased
cooldown
quarantined
needs_review
repairing
retired

Each state has a different meaning.

available means a worker can use the profile.

leased means a worker is currently using it.

cooldown means the profile is probably fine, but should not be reused immediately.

quarantined means a failure created uncertainty.

needs_review means a human or recovery workflow must inspect the evidence.

repairing means the system is actively restoring or validating the profile.

retired means the profile should no longer be used.

The goal is to avoid a common mistake:

treating every released lock as a reusable profile.

What review should check

A quarantined profile needs a review path.

That review can be manual, automated, or hybrid.

A practical review checklist:

Confirm the profile identity.
Confirm which account the profile belongs to.
Check the failed run ID and last step.
Review the final screenshot and last known URL.
Verify whether the account is logged in, logged out, challenged, or partially loaded.
Confirm proxy, region, timezone, and language.
Check whether the last action may have completed.
Decide whether to resume, repair, reset, or retire.
Write the decision back to the profile record.
Only then return the profile to the available pool.

Quarantine should produce a decision.

It should not become a forgotten holding area.

The retry mistake

Many failures look temporary.

Timeouts look temporary. Proxy errors look temporary. Selector misses look temporary. Headless crashes look temporary.

Some of them are temporary.

But the exception class is not enough.

A timeout before login is different from a timeout after submitting an authenticated form.

A crash before browser launch is different from a crash after session refresh.

A proxy error before opening the profile is different from a proxy error after the account dashboard loads.

The quarantine decision should depend on what the profile may have experienced, not just the final error message.

The cleanup mistake

Another common mistake is cleaning the profile too quickly.

Clearing cookies or local storage might be the right recovery action, but doing it immediately can destroy useful evidence.

Before cleaning anything, capture the state.

Ask:

What was the last visible account state?
Which storage values changed recently?
Did the site still recognize the account?
Was the proxy consistent with the profile?
Did the failure repeat from the same step?
What evidence would be lost if the profile was reset now?

Cleaning may repair the profile.

Cleaning too early can erase the reason it failed.

Why AI browser agents make this stricter

AI browser agents make quarantine more important, not less.

A rigid script may stop when the page changes. An agent may adapt, continue, and find another path.

That flexibility can be useful. It also means the agent may move through states the original workflow did not explicitly model.

After a failed agent run, the team needs to know:

what the agent saw
what it changed
what it skipped
what it assumed
why it stopped
whether the profile is still safe

A profile used by an agent should be quarantined when the action trace is incomplete, the final page state is unclear, or the agent made a judgment call near an account boundary.

The question is not only whether the agent failed.

The question is whether the profile remains trustworthy after the agent failed.

The practical rule

Here is the rule I use:

A failed browser profile can be reused only when the team can explain the last account state, the last environment state, the last task state, and the last evidence state.

If one of those is unknown, quarantine the profile.

That may feel conservative in a small automation project.

In a multi-worker system, it becomes operational hygiene.

A browser profile is not just a launch target. It is the account environment that the next worker will inherit.

Treat it that way.

Final checklist

Quarantine the profile if:

the worker crashed after opening the profile
the run reached an authenticated area
session state may have changed
cookies or local storage may have changed
proxy or region changed during the run
the failure happened near a non-idempotent action
the account showed login, verification, warning, or redirect screens
evidence is incomplete
the browser did not close cleanly
the next operator cannot explain what happened

Do not quarantine automatically if:

the profile was never opened
the failure happened before browser launch
the run only touched public pages
no account state was loaded
the browser closed cleanly
evidence is complete
the failure is clearly outside the profile

The goal is not to quarantine everything.

The goal is to stop treating failed account environments as clean inputs.

A lease prevents two workers from colliding.

A quarantine state prevents one failed run from becoming the starting point for the next failure.

Designing Browser Profile Leases for Multi-Worker Automation

web4browser — Fri, 19 Jun 2026 09:39:21 +0000

A stale lock is a recovery problem.

A profile lease is a runtime design problem.

This builds on an earlier concurrency problem: preventing two workers from opening the same browser profile is only the first step.

The harder question is what happens after a profile lock becomes stale, but the account state inside that profile is still unknown.

If you run one browser automation worker on one local profile, a lock file may feel enough. The worker starts, writes a lock, launches a persistent browser context, finishes the job, and removes the lock.

That model starts to fail when you add more workers, retries, queues, and real browser profiles that carry account state.

In Playwright projects, this often shows up around launchPersistentContext, shared userDataDir, or long-running workers that reuse real browser state.

A lock can tell you that a profile is occupied.

It usually cannot tell you enough to reuse that profile safely.

It may not tell you which worker owns the profile, which run created the lock, whether the worker is still alive, what URL the task reached, or whether another worker should continue after a crash.

That is where a browser profile lease helps.

A lease is not just a lock. It is a runtime contract between the scheduler, the worker, and the account-bound browser profile.

It answers four questions:

Who owns this profile right now?
Which run is using it?
Until when is this ownership valid?
What should happen if the worker disappears?

For the team handoff side of this problem, this related note on browser profile management for teams is a useful companion. This article focuses on the runtime model: how to design profile leases before launching multiple automation workers against persistent browser profiles.

The failure mode

Here is a common situation:

profile_id: profile_shop_17
worker_a: acquired profile
worker_a: launched browser
worker_a: completed login
worker_a: crashed before cleanup
worker_b: waiting for the same account task
lock_file: still exists

Now the scheduler has a decision to make.

Should it delete the lock?

Should it retry the task?

Should worker B open the same profile?

Should the profile go to manual review?

The file itself cannot answer that.

The main risk is not only that two workers may open the same profile at the same time. The bigger risk is that a second worker may reuse a profile whose account state is unknown.

That can happen after a crash during login, a partial form submission, a proxy mismatch, a verification prompt, a failed redirect, or a run that changed local storage before failing.

A lock protects the profile from simultaneous access.

A lease protects the profile from unsafe reuse.

What a profile lease should record

A lease record does not need to be complicated. It needs to be explicit.

A minimal lease could look like this:

{
  "lease_id": "lease_20260619_001",
  "profile_id": "profile_shop_17",
  "account_id": "account_shop_17",
  "worker_id": "worker_03",
  "run_id": "run_20260619_094500",
  "task_type": "inventory_check",
  "proxy_id": "proxy_us_east_12",
  "lease_status": "active",
  "lease_started_at": "2026-06-19T09:45:00Z",
  "heartbeat_at": "2026-06-19T09:46:30Z",
  "expires_at": "2026-06-19T09:50:00Z",
  "last_safe_step": "dashboard_loaded",
  "release_policy": "manual_review_on_unknown_state"
}

The important fields are not just metadata.

They create an operational boundary.

profile_id tells the system which browser environment is being used.

account_id prevents the scheduler from treating the profile as a generic browser folder.

worker_id and run_id connect the profile to a specific execution.

proxy_id helps detect whether the run used the expected network context.

heartbeat_at tells the scheduler whether the worker is still reporting.

last_safe_step helps decide whether the profile can be reused after failure.

release_policy prevents the system from cleaning up state it does not understand.

Checkout should happen before launch

A worker should not open a persistent browser profile directly.

It should request a checkout first.

In pseudo-code, that checkout step might look like this:

const lease = await profileLeases.checkout({
  profileId: "profile_shop_17",
  accountId: "account_shop_17",
  workerId: "worker_03",
  runId: "run_20260619_094500",
  taskType: "inventory_check",
  ttlSeconds: 300
});

if (!lease.granted) {
  throw new Error(`Profile unavailable: ${lease.reason}`);
}

const browser = await launchPersistentProfile({
  profileId: lease.profile_id,
  proxyId: lease.proxy_id
});

The scheduler should be allowed to deny checkout.

Common reasons include:

profile already leased
profile under review
profile quarantined
proxy mismatch
account owner mismatch
previous run ended in unknown state

This is the difference between a worker pool and an account-aware runtime.

A basic worker pool asks:

Which worker is free?

A profile lease system asks:

Which account environment is safe to use?

That extra question matters when a browser profile contains cookies, local storage, proxy expectations, region settings, extension state, and task history.

Heartbeats are ownership updates

A lease should not be granted and then forgotten.

Long-running browser tasks need heartbeat updates.

In pseudo-code, a heartbeat update might look like this:

await profileLeases.heartbeat({
  leaseId: lease.lease_id,
  workerId: "worker_03",
  runId: "run_20260619_094500",
  currentStep: "checking_inventory_page",
  currentUrl: page.url()
});

A heartbeat is not only a liveness signal.

It also creates a timeline.

09:45:00 checkout granted
09:45:12 browser launched
09:45:21 dashboard loaded
09:46:03 inventory page opened
09:46:30 heartbeat received
09:51:31 heartbeat missing
09:52:00 lease marked stale

That timeline is much more useful than a leftover lock file.

But a stale heartbeat does not automatically mean the profile is safe.

It only means the worker stopped reporting.

The browser process may still be open. The task may have crashed after changing account state. The account may now be on an unexpected page.

So the next step should be inspection, not automatic reuse.

TTL is not a cleanup command

A common mistake is treating lease TTL as permission to delete the lock.

That is unsafe.

TTL should mean:

The worker must renew ownership before this time.

It should not mean:

After this time, another worker can reuse the profile no matter what happened.

A lease can expire while the profile is still risky.

A safer state machine looks like this:

Condition	Lease action	Profile action
Worker finished cleanly	release	reusable
Worker renewed heartbeat	extend	keep leased
Heartbeat missing	mark stale	inspect before reuse
Browser process still alive	keep blocked	do not reuse
Run crashed after account mutation	quarantine	human review
Login or verification prompt detected	review required	do not auto-retry
Proxy or account context mismatch	quarantine	investigate

The rule is simple:

An expired lease is not the same as a clean release.

A clean release is an explainable ending.

An expired lease is an unresolved ending.

Use more than active and free

A profile lease system should support more states than active and free.

At minimum, I would use something like this:

available
leased
stale
review_required
quarantined
disabled

available means the profile can be checked out.

leased means a worker currently owns it.

stale means the worker stopped reporting, but the final state is not known.

review_required means automation should pause until a human or a recovery job checks the profile.

quarantined means the profile should not return to the pool until its state is cleared.

disabled means the profile is out of rotation.

Quarantine is not punishment. It is a safety state.

A profile should be quarantined when the automation system cannot prove that the browser environment is safe to reuse.

Examples:

The worker died during login.
The worker died after submitting a form.
The final URL is unknown.
The expected proxy changed during the run.
The task ended without a final screenshot.
The run modified cookies or local storage before crashing.
The page opened a verification or security prompt.
The account context does not match the profile metadata.

This may feel conservative.

But it prevents the next worker from continuing in the wrong account state.

In browser automation, many production failures are not selector failures.

They are context failures.

Log lease events like task events

A lease event should be part of the automation evidence bundle.

Log every transition.

{
  "event": "lease_acquired",
  "lease_id": "lease_20260619_001",
  "profile_id": "profile_shop_17",
  "account_id": "account_shop_17",
  "worker_id": "worker_03",
  "run_id": "run_20260619_094500",
  "timestamp": "2026-06-19T09:45:00Z"
}

Useful lease events include:

lease_acquired
lease_heartbeat
lease_extended
lease_release_requested
lease_released_cleanly
lease_marked_stale
profile_quarantined
profile_reviewed
profile_returned_to_pool

The goal is not to create more logs for the sake of logging.

The goal is to answer operational questions later.

Who used this profile last?
Which task changed its state?
Which proxy was active?
Did the run finish cleanly?
Was the profile reviewed before reuse?
Why was it quarantined?

Those questions become important when the worker count grows.

They become even more important when different people maintain the automation system, review failures, and operate the accounts.

A minimal lease lifecycle

A practical browser profile lease lifecycle can look like this:

1. Register profile with account metadata
2. Bind expected proxy and region context
3. Worker requests profile checkout
4. Scheduler grants lease only if profile is available
5. Worker launches persistent browser context
6. Worker sends heartbeat during execution
7. Worker records final state
8. Scheduler releases, reviews, or quarantines profile
9. Next worker can only use cleanly released profiles

This lifecycle turns a profile from a local folder into a managed account environment.

That distinction matters.

A browser profile is not just a place where cookies live.

It can contain local storage, session behavior, language settings, extension state, history, proxy expectations, fingerprint configuration, and account-specific assumptions.

If your automation system treats that profile like a disposable directory, multi-worker execution will eventually create account-state confusion.

Route by account context, not only worker availability

Profile leases also change how you think about scheduling.

A naive scheduler may do this:

Pick next job.
Find any free worker.
Run immediately.

An account-aware scheduler does this:

Pick next job.
Find required account context.
Find matching profile.
Check profile lease status.
Check proxy and region expectations.
Grant lease.
Run task.
Record final state.

The second model takes more design work.

It is also safer to operate.

It prevents these problems:

Two workers opening the same profile.
One worker using the wrong account environment.
A task running with the wrong proxy.
A retry continuing from an unknown page.
A profile being reused after an unresolved crash.
A team member debugging without knowing who last used the account.

The point is not to make automation heavy.

The point is to make browser state explicit.

A rule that works well

Here is a practical rule for multi-worker browser automation:

A worker can acquire a browser profile only when the previous lease ended with an explainable state.

Explainable states include:

clean success
expected failure
manual review completed
quarantine cleared

Unresolved states should not count as safe:

lock file deleted
TTL expired
worker disappeared
retry requested
unknown final URL

This rule reduces the chance that automation silently corrupts account state.

It also makes debugging easier.

When a profile is unavailable, the system can explain why.

That explanation tells the developer whether to fix a scheduler bug, inspect a worker crash, review a profile, or change the retry policy.

Where this fits in team automation

Profile leases are not only a backend detail.

They become part of the team workflow.

A developer needs to know which run owns a profile.

An operator needs to know whether an account is safe to continue.

A reviewer needs to know why a profile was quarantined.

A scheduler needs to know whether a profile can be checked out again.

That is why browser automation for account-based work needs more than scripts, queues, and retries.

It needs account-aware runtime state.

Tools in this space, including Web4 Browser, are moving toward that workflow view: profiles are not just windows, but account environments that should carry identity, proxy context, task history, and review status.

A lease model is one way to apply that idea in your own automation architecture.

Final checklist

Before you run multiple workers against persistent browser profiles, check whether your system can answer these questions:

Does every profile have an account owner?
Does every checkout create a lease record?
Does every lease include worker ID and run ID?
Does the worker send heartbeat updates?
Is TTL treated as a renewal deadline, not a cleanup command?
Can the system distinguish stale from cleanly released?
Can the system quarantine profiles after unknown failures?
Are proxy and account context checked before launch?
Are lease transitions logged?
Can a human reviewer return a profile to the pool?
Can the scheduler explain why a profile is unavailable?

A browser profile lock prevents simultaneous access.

A browser profile lease prevents unsafe reuse.

That is the difference that matters when automation moves from one script to many workers.

Recovering Stale Browser Profile Locks Without Corrupting Account State

web4browser — Thu, 18 Jun 2026 08:10:58 +0000

A browser profile lock is supposed to prevent one dangerous situation: two workers opening the same account environment at the same time.

The previous post in this series covered prevention: do not let two workers acquire the same browser profile.

This one covers recovery.

What happens when the first worker crashes, times out, or loses network access after it has already opened a logged-in browser profile?

That is where many automation systems make the wrong decision. They see an old lock, delete it, and let another worker continue.

That may make the queue move again, but it can quietly corrupt account state.

A stale lock should not be treated as a file to remove. It should be treated as an unfinished account operation that needs a controlled recovery path.

For a broader team workflow model, this connects to the idea of a profile ownership and handoff layer.

TL;DR

A stale browser profile lock should move through recovery states, not disappear.

Use this model:

held
  -> suspected_stale
  -> quarantined
  -> inspected
  -> available | resume_pending | manual_review

The lock is only metadata. The real thing you are protecting is the browser profile behind it: cookies, local storage, proxy mapping, extension state, task history, and the last known page state.

The lock is not the account state

A lock only tells your system that a worker claimed the right to use a profile.

It does not tell you whether the browser process is still alive.

It does not tell you whether the profile closed cleanly.

It does not tell you whether the last task stopped on a safe page.

It does not tell you whether cookies, local storage, IndexedDB, extension storage, or profile metadata were being modified when the failure happened.

That is why this rule matters:

Never recover a browser profile lock by deleting the lock alone.

The lock is metadata. The account state lives somewhere else.

A safe recovery model has to protect both.

What makes a profile lock stale?

A profile lock becomes stale when the system can no longer trust that the owner worker is still actively using the profile.

Common causes include:

the worker process crashed
the host restarted
the job exceeded its maximum runtime
heartbeat updates stopped
the queue visibility timeout expired
the browser process is still alive but detached from the worker
the worker completed the task but failed before releasing the lock
a network partition made the worker unreachable

These cases do not all mean the same thing.

A crashed worker may be gone.

A network-partitioned worker may still be running.

A browser process may still hold the profile directory even if the job owner disappeared.

A task may have failed after submitting a form, changing settings, or landing on a verification page.

So lock age > timeout is useful, but it is not enough to safely reassign the profile.

Store locks as leases, not permanent ownership

A browser profile lock should behave like a lease.

A lease has an owner, an expiry time, a heartbeat, and a version.

The version is important because it prevents an old worker from writing after a new worker has recovered the profile.

A simple lock record can look like this:

{
  "profile_id": "profile_us_018",
  "owner_worker_id": "worker-7",
  "task_id": "task_20260618_0932",
  "lease_token": 42,
  "acquired_at": "2026-06-18T09:32:10Z",
  "heartbeat_at": "2026-06-18T09:36:40Z",
  "expires_at": "2026-06-18T09:38:40Z",
  "state": "held"
}

The lease_token is a fencing token.

Every write related to this profile should include the latest token. That includes task logs, status updates, screenshots, profile metadata updates, and release attempts.

If worker-7 comes back after the lock has already been recovered by worker-12, its old token should be rejected.

That one rule prevents many silent corruption cases.

Do not jump from stale to available

This is the common mistake:

if (lock.expires_at < now) {
  await deleteLock(profileId)
  await enqueue(profileId)
}

It is simple, but too dangerous.

The lock may be stale, but the profile may not be safe.

A safer system uses intermediate states:

held
  -> suspected_stale
  -> quarantined
  -> inspected
  -> available | resume_pending | manual_review

The point of quarantined is to prevent a second worker from immediately opening the profile while the system is still deciding what happened.

The recovery worker is not taking over the account yet.

It is taking over the investigation.

Step 1: mark the lock as suspected stale

When a lease expires, update the lock only if the old value still matches what you observed.

This is a compare-and-swap operation.

async function markSuspectedStale(profileId, observedToken) {
  const lock = await lockStore.get(profileId)

  if (!lock) {
    return { ok: false, reason: "missing_lock" }
  }

  if (lock.lease_token !== observedToken) {
    return { ok: false, reason: "lock_changed" }
  }

  if (new Date(lock.expires_at) > new Date()) {
    return { ok: false, reason: "lease_still_active" }
  }

  return lockStore.compareAndSet(profileId, observedToken, {
    ...lock,
    state: "suspected_stale",
    suspected_at: new Date().toISOString()
  })
}

This protects you from racing with another worker that already renewed or recovered the lock.

Step 2: quarantine the profile

Once a lock is suspected stale, the profile should not go back into the normal worker pool.

Move it to quarantine.

A quarantined profile is temporarily blocked from normal automation until the system checks:

whether an old browser process is still running
whether the old worker can still send heartbeats
whether the profile directory is still held by the OS
whether the last task stopped at a safe checkpoint
whether the account session requires human review
whether the task can be resumed or must restart

This step is not about being slow.

It is about avoiding two workers writing to the same browser state.

Step 3: capture recovery evidence before cleanup

Before killing processes, deleting temporary files, or opening the profile again, capture evidence.

At minimum, store something like this:

{
  "profile_id": "profile_us_018",
  "old_worker_id": "worker-7",
  "old_task_id": "task_20260618_0932",
  "lease_token": 42,
  "last_heartbeat_at": "2026-06-18T09:36:40Z",
  "detected_stale_at": "2026-06-18T09:39:05Z",
  "last_known_step": "submit_budget_change",
  "last_known_url": "https://example.com/account/campaigns",
  "last_screenshot": "s3://evidence/task_20260618_0932/last.png",
  "proxy_id": "proxy-us-dallas-03",
  "profile_dir": "/profiles/profile_us_018",
  "recovery_reason": "heartbeat_timeout"
}

This evidence helps you answer the question later:

Did the profile fail because the worker died, the website changed, the proxy shifted, the browser crashed, or the task should have stopped for human review?

Without recovery evidence, stale lock recovery becomes guesswork.

Step 4: reject late writes

The dangerous case is not only “the worker crashed.”

The dangerous case is this:

A worker looked dead, another worker took over, and then the first worker came back.

This can happen with network partitions, overloaded hosts, slow hosts, or delayed cleanup.

That is why every write should check the current token.

async function writeTaskEvent(profileId, leaseToken, event) {
  const lock = await lockStore.get(profileId)

  if (!lock) {
    throw new Error("profile lock missing")
  }

  if (lock.lease_token !== leaseToken) {
    throw new Error("stale lease token rejected")
  }

  await taskLog.append({
    profile_id: profileId,
    lease_token: leaseToken,
    ...event
  })
}

If an old worker tries to mark the task as complete after recovery started, the system rejects it.

In browser automation, this protects account state. The old worker may have a stale view of the page, proxy, session, or task plan.

Step 5: inspect before reuse

After quarantine, the recovery worker should run a health check.

This should be separate from the original business task.

Do not immediately continue clicking buttons on the target website. First inspect whether the browser environment is safe to reuse.

A simple inspection output can look like this:

Profile directory exists: yes
Profile directory held by active browser process: no
Last task ended at safe checkpoint: unknown
Last screenshot available: yes
Last URL belongs to expected domain: yes
Proxy mapping unchanged: yes
Session state present: yes
Manual review flag: no
Lease token advanced: yes

If the last task stopped during a sensitive operation, do not auto-resume.

Examples include:

after clicking submit
during checkout
while changing account settings
on a verification page
after a failed login attempt
during password, MFA, or recovery flows
while editing campaign, billing, wallet, or payout settings

For those states, the recovery result should be manual_review, not available.

Step 6: choose release, resume, retry, or review

A stale lock recovery should end in one of four outcomes.

Release

Use this when the task never started or failed before touching account state.

suspected_stale -> quarantined -> inspected -> available

This is the cleanest path.

The profile can return to the worker pool after a short cooldown.

Resume

Use this only when your task has explicit checkpoints and idempotent steps.

suspected_stale -> quarantined -> inspected -> resume_pending

A resumable task should know the last safe step:

{
  "task_id": "task_20260618_0932",
  "resume_from": "open_campaign_list",
  "last_safe_checkpoint": "campaign_list_loaded"
}

If you cannot name the last safe checkpoint, do not resume.

Retry

Use this when the profile is safe, but the task should restart from the first step.

Even then, be careful.

Restarting a browser task is not the same as retrying an API request. The website may already have seen part of the previous action.

Manual review

Use this when the account state may have changed or the last page requires judgment.

This should be the default for ambiguous states.

A manual review flag is not a failure of automation. It is a boundary that prevents automation from making a bad recovery decision.

A compact recovery function

The exact storage layer can be Redis, Postgres, DynamoDB, or something else.

The important part is the state machine.

async function recoverStaleProfileLock(profileId) {
  const lock = await lockStore.get(profileId)

  if (!lock) {
    return { action: "none", reason: "no_lock" }
  }

  if (new Date(lock.expires_at) > new Date()) {
    return { action: "none", reason: "lease_active" }
  }

  const marked = await markSuspectedStale(
    profileId,
    lock.lease_token
  )

  if (!marked.ok) {
    return { action: "none", reason: marked.reason }
  }

  const recoveryToken = lock.lease_token + 1

  await lockStore.update(profileId, {
    ...lock,
    state: "quarantined",
    lease_token: recoveryToken,
    recovery_started_at: new Date().toISOString()
  })

  const evidence = await collectRecoveryEvidence(profileId, lock)
  await recoveryLog.write(evidence)

  const inspection = await inspectProfileHealth(profileId)

  if (inspection.requires_manual_review) {
    await lockStore.update(profileId, {
      state: "manual_review",
      lease_token: recoveryToken,
      reason: inspection.reason
    })

    return {
      action: "manual_review",
      reason: inspection.reason
    }
  }

  if (inspection.can_resume) {
    await lockStore.update(profileId, {
      state: "resume_pending",
      lease_token: recoveryToken,
      resume_from: inspection.resume_from
    })

    return {
      action: "resume",
      from: inspection.resume_from
    }
  }

  await lockStore.update(profileId, {
    state: "available",
    lease_token: recoveryToken,
    released_at: new Date().toISOString()
  })

  return { action: "released" }
}

The function is intentionally boring.

That is a good sign.

Recovery logic should not be clever. It should be explicit, auditable, and hard to race.

Add a short cooldown before reuse

After a stale lock is released, avoid immediate reuse if the failure mode is unclear.

A short cooldown can prevent accidental overlap with delayed cleanup.

available_after = recovered_at + cooldown_seconds

This is especially useful when workers run on remote machines, containers, or headless environments where process cleanup can lag behind queue state.

The cooldown should not replace fencing tokens.

It is only an additional safety margin.

Common failure patterns

Here are the stale-lock mistakes that show up repeatedly in browser automation systems.

Blind lock deletion

Deleting the lock makes the profile available, but it does not prove the profile is safe.

No fencing token

Without a token, an old worker can come back and write stale task results after recovery has already started.

No quarantine state

If the only states are locked and available, the system has no place to inspect ambiguous failures.

No recovery evidence

Without the last URL, step name, screenshot, proxy mapping, and task state, the recovery decision becomes a guess.

Automatic retry after sensitive steps

A retry after a submit, checkout, settings update, or login challenge can duplicate actions or move the account into a worse state.

Changing proxy during recovery

A stale lock is already an unstable state. Changing the proxy at the same time makes debugging harder and can change account context.

What should never happen automatically

These actions should not be part of automatic stale lock recovery:

deleting the whole profile directory
clearing cookies to “fix” the session
changing the proxy during recovery
opening the same profile in two browsers to compare state
marking the original task as successful without evidence
retrying a form submission without a checkpoint
assigning the profile to a different account
accepting late writes without checking the lease token

These shortcuts may make the queue green.

They can also damage the account context your automation depends on.

A practical stale lock checklist

Before returning a browser profile to the worker pool, answer these questions:

Lock:
- Was the lease expired?
- Was the lock changed with compare-and-swap?
- Was the lease token advanced?

Worker:
- Is the old worker still alive?
- Did the old worker send a late heartbeat?
- Can old writes be rejected by token?

Browser:
- Is the browser process closed?
- Is the profile directory still locked?
- Was the browser closed cleanly?

Task:
- What was the last known step?
- What was the last known URL?
- Is there a screenshot or trace?
- Was the task in a sensitive operation?

Account state:
- Did cookies or local storage change?
- Is the proxy mapping unchanged?
- Is the session still valid?
- Does the page require human review?

Decision:
- release, resume, retry, or manual review?

The goal is not to make recovery complicated.

The goal is to make it explicit.

The right abstraction is profile recovery

A stale browser profile lock is not only a concurrency problem.

It is an account-state recovery problem.

That is why the recovery model should sit near profile ownership, task logs, proxy mapping, screenshots, and human review rules.

If those systems are separate, stale lock recovery will always depend on guessing.

For long-running browser automation, the safer pattern is:

one profile
one owner lease
one active task
one evidence trail
one recovery decision

A browser workflow layer should not only run tasks. It should record enough context to recover them.

That is the real lesson of stale locks:

The lock is only the symptom.

The system has to protect the account environment behind it.

Editorial note: This article was drafted with AI assistance and reviewed by the author before publication.

How to Prevent Two Workers From Using the Same Browser Profile

web4browser — Wed, 17 Jun 2026 04:56:12 +0000

A browser automation queue can look healthy while it is already corrupting state.

One worker picks up a task. Another worker picks up a different task. Both resolve to the same account context. Both try to use the same browser Profile.

The scheduler thinks it is doing useful work.

The browser state tells a different story.

One run sees a logged-in session. Another run gets redirected to login. A cookie changes during execution. Local storage is updated halfway through a task. A proxy check passes, but the page looks like it belongs to another run.

This is not always a Playwright problem.

It is often a Profile ownership problem.

Once browser automation depends on real Profile state, the Profile cannot be treated like a stateless input folder. It needs a lock.

Where this problem appears

A basic queue usually routes work like this:

task -> any free worker

That is fine for stateless jobs.

It is not enough when a browser task depends on a specific account environment. For account-based automation, the routing model usually becomes:

task -> account_context -> profile_id -> worker

That solves the first problem: the task runs in the intended account context. I covered that routing layer in routing browser automation tasks by account context, where the main problem is choosing the right Profile before assigning a worker.

This article starts at the next failure point: once the right Profile is selected, how do you prevent two workers from using it at the same time?

task_101 -> profile_store_us_018
task_102 -> profile_store_us_018

If both tasks start, two workers can mutate the same browser state.

That state may include:

cookies
local storage
IndexedDB
cache
extension state
active tabs
login session
proxy binding
task notes
recovery checkpoints

A browser Profile is not just a launch argument. In a real automation workflow, it is part of the account context.

Browser-level locks are not a workflow model

Some teams assume Chromium or the operating system will protect the Profile directory.

Sometimes it will.

A second process may fail to open the same user data directory. You may see a browser launch error. You may get a locked directory error. You may get a vague crash.

But that is still too late.

At that point, the scheduler has already assigned the task. The worker has already tried to start. The queue may retry. Another worker may pick up the same task. The logs may say “browser failed to launch” instead of “Profile already in use.”

A useful Profile lock should be visible to the automation system before the browser launches.

The scheduler needs to know something like this:

{
  "profile_id": "profile_store_us_018",
  "locked_by": "worker_07",
  "task_id": "task_101",
  "lease_expires_at": "2026-06-17T15:30:00Z",
  "status": "running"
}

Now the system can make a routing decision before touching browser state.

A Profile lock should answer three questions

A lock that only says “busy” is not enough.

It should answer three questions.

First: who owns this Profile right now?

profile_id -> worker_id + task_id

Second: how long is that ownership valid?

lease_expires_at -> when the lock should be considered stale

Third: what should happen if the worker disappears?

stale lock -> recover, inspect, retry, or require human review

Without those answers, the lock becomes another hidden failure mode.

A simple Profile lock model

The simplest model is one active lock per Profile.

profile_id: unique
task_id: current task
worker_id: current worker
lease_expires_at: timestamp
heartbeat_at: timestamp
status: running | releasing | stale | failed

The scheduler should acquire the lock before the worker opens the browser.

A basic flow looks like this:

1. Receive task
2. Resolve account context
3. Resolve profile_id
4. Try to acquire Profile lock
5. If acquired, start browser task
6. Send heartbeat during execution
7. Save evidence before release
8. Release lock after task finishes

A Redis-style lock may look like this:

SET profile_lock:profile_store_us_018 task_101 NX PX 900000

That gives the worker a lease.

If the worker crashes, the lock eventually expires.

But expiration alone is not enough. You still need an execution record explaining what happened before the lock disappeared.

Add ownership checks before launching Playwright

In Playwright, the risky part usually begins when you launch a persistent browser context or connect automation to an existing Profile.

The lock should happen before that.

A simplified example:

async function runTask(task) {
  const profileId = resolveProfileId(task.accountContext);

  const lock = await acquireProfileLock({
    profileId,
    taskId: task.id,
    workerId: process.env.WORKER_ID,
    leaseMs: 15 * 60 * 1000
  });

  if (!lock.acquired) {
    await rescheduleTask(task.id, {
      reason: "profile_lock_conflict",
      profileId,
      currentOwner: lock.currentOwner
    });

    return;
  }

  try {
    const context = await chromium.launchPersistentContext(
      profilePath(profileId),
      {
        headless: false
      }
    );

    await executeBrowserTask(context, task);
    await saveTaskResult(task.id, "completed");
  } catch (error) {
    await saveFailureEvidence({
      taskId: task.id,
      profileId,
      error
    });

    throw error;
  } finally {
    await releaseProfileLock({
      profileId,
      taskId: task.id
    });
  }
}

The exact storage layer does not matter as much as the rule:

Do not open the Profile until ownership is confirmed.

Do not release the lock before saving evidence

A common mistake is releasing the Profile lock immediately after a failure.

That makes the queue look healthy, but it can destroy the debugging path.

The safer order is:

1. Task fails
2. Capture current URL
3. Capture screenshot
4. Save console or network summary if available
5. Save profile_id, proxy_id, task_id, and worker_id
6. Mark final task status
7. Release Profile lock

The lock protects the Profile during execution.

The evidence protects the team after execution.

If the lock is released before evidence is saved, the next worker may open the same Profile and change the state you needed to inspect.

Worker concurrency should be controlled per Profile

Many automation systems only control global concurrency:

max_workers = 10

That limits total execution volume.

It does not prevent two workers from touching the same Profile.

For account-based browser automation, concurrency should also exist at the Profile level:

profile_store_us_018 -> max_active_runs = 1
profile_store_de_042 -> max_active_runs = 1
profile_test_guest_001 -> max_active_runs = 3

Not every Profile needs the same rule.

A logged-in business account should usually have one active owner.

A disposable test Profile may allow more parallelism.

A read-only monitoring Profile may have different rules from a Profile that performs state-changing actions.

The rule should be based on what the task can mutate.

When a Profile may not need an exclusive lock

An exclusive Profile lock is not always required.

The important question is whether the task can mutate shared browser state.

A Profile may not need exclusive ownership when:

it is a short-lived temporary Profile
it has no shared login state
it does not reuse cookies or local storage
it is used only for isolated test runs
the task is fully read-only
the Profile is intentionally disposable after execution

For example, a worker that creates a new temporary browser context for every run may not need a Profile-level lock. There is no long-lived account state to protect.

A read-only monitoring task may also allow limited concurrency if it does not modify cookies, local storage, account settings, or active workflow state.

But the moment a Profile represents a real account environment, the default should change.

If the task can alter login state, account settings, session data, proxy expectations, or recovery evidence, exclusive ownership is safer.

A practical rule is:

shared Profile state -> lock it
temporary isolated state -> concurrency may be allowed

Lock conflicts are workflow signals

A Profile lock conflict is not just a queue delay.

It may mean:

two tasks were routed to the same account context
a previous worker crashed
a task took longer than expected
the Profile is being used manually
the task priority model is unclear
the Profile should be split into separate workflows

That is why lock conflicts should be logged as workflow events.

Example:

{
  "event": "profile_lock_conflict",
  "profile_id": "profile_store_us_018",
  "blocked_task_id": "task_102",
  "current_task_id": "task_101",
  "current_worker_id": "worker_07",
  "decision": "rescheduled",
  "next_check_seconds": 300
}

This gives the team a useful signal.

The system may need better task sequencing, not just more workers.

Add Profile behavior to the task manifest

The worker should not infer Profile rules at runtime.

A task manifest can make the expected behavior explicit:

{
  "task_id": "task_101",
  "account_id": "store_us_018",
  "profile_id": "profile_store_us_018",
  "proxy_id": "proxy_us_dallas_01",
  "requires_exclusive_profile_lock": true,
  "allowed_actions": ["inspect_login", "read_dashboard"],
  "lock_timeout_seconds": 900,
  "human_review_on_lock_conflict": true
}

This makes the task easier to reason about.

If another task already owns the Profile, the scheduler should not blindly retry. It should decide whether to wait, reschedule, skip, or send the task to review.

Checklist before scaling workers

Before increasing worker count, check whether your Profile model can answer these questions:

Can every task resolve to one intended Profile?
Can the scheduler see whether that Profile is already owned?
Does the lock include task ID and worker ID?
Does the lock have a lease and heartbeat?
Is stale lock recovery handled explicitly?
Is evidence saved before lock release?
Are lock conflicts visible in task logs?
Can some Profiles allow concurrency while others require exclusivity?
Can manual use of a Profile be detected or recorded?
Can the team tell whether a failure came from code, Profile state, proxy mapping, or worker contention?

If the answer is no, adding more workers may only make state corruption faster.

The practical rule

Account-aware routing answers one question:

Where should this task run?

Profile locking answers another:

Is it safe to run there right now?

A reliable browser automation system needs both.

routing decides the intended environment
locking protects the environment during execution

For small scripts, this may feel like overengineering.

For teams running browser tasks against real account contexts, it becomes basic infrastructure.

This is where browser automation starts to look less like isolated scripting and more like environment operations. If your team is already debugging Profile state, proxy mapping, cookies, and task logs together, tools such as Web4 Browser can help manage those pieces inside a shared browser environment workspace instead of scattering the logic across queue code, browser scripts, and manual notes.

Route Browser Automation Tasks by Account Context, Not Worker Availability

web4browser — Tue, 16 Jun 2026 04:00:12 +0000

Most browser automation queues start simple.

A task enters the queue.
A worker becomes available.
The worker opens a browser.
The script runs.

That model works when every task is anonymous.

It starts breaking when the browser is already logged in.

Here I am talking about authorized team workflows: internal dashboards, QA accounts, support operations, client-approved workspaces, or other account-bound browser tasks where the team is allowed to operate those accounts.

In these workflows, the browser is not just a runtime. It carries account state, cookies, local storage, proxy routing, region settings, permissions, and sometimes a human review history.

If your scheduler treats every browser profile as a generic worker slot, the queue can quietly send a task into the wrong account environment.

That is how a Playwright script can be technically correct and still operate in the wrong place.

For teams building long-running account workflows, the missing layer is not another retry loop. It is account-aware task routing. A browser automation workspace should know which account context a task belongs to before it lets a worker touch a page.

The common worker pool model is too generic

The examples below are pseudo-TypeScript. The goal is to show the routing model, not a complete queue implementation.

A basic browser automation task often looks like this:

type BrowserTask = {
  taskId: string;
  url: string;
  action: "inspect" | "click" | "extract" | "submit";
  payload?: Record<string, unknown>;
};

Then the worker pool does something like this:

const task = await queue.next();
const worker = await workers.firstAvailable();

await worker.run(task);

This is fine for public page checks, static scraping, QA smoke tests, and other jobs where identity does not matter.

It is weak for logged-in workflows.

The task does not say which account owns the work.
It does not say which browser profile must be used.
It does not say which proxy group is expected.
It does not say whether human review is required before submit actions.
It does not say what should happen if the original profile is busy.

The scheduler only sees “available worker”.

The business workflow actually needs “the correct account environment”.

Account context should be part of the task

For logged-in browser automation, the queue payload should include the account context contract.

A more useful task model looks like this:

type AccountBoundBrowserTask = {
  taskId: string;
  accountId: string;
  profileId: string;
  proxyGroupId: string;
  expectedRegion: string;
  action: "inspect_status" | "collect_metrics" | "prepare_form";
  targetUrl: string;
  riskLevel: "low" | "review_required" | "blocked";
  createdBy: "human" | "agent" | "schedule";
};

Now the scheduler has something to enforce.

The worker should not ask:

Which browser is free?

It should ask:

Which worker can run this exact account context safely?

That difference matters.

A profile with the right cookies but the wrong proxy is not valid.

A profile with the right proxy but the wrong account session is not valid.

A profile that is already locked by another task is not valid.

A profile that requires human review before a submit action is not valid for a fully automated run.

Match workers by environment, not availability

Account affinity means a task should prefer, or require, a specific account environment.

This is similar to routing distributed jobs to nodes with the right data locality. In browser automation, the “data” is the account state inside the browser profile.

A simple routing rule can look like this:

function canRunTask(worker: BrowserWorker, task: AccountBoundBrowserTask) {
  return (
    worker.profileId === task.profileId &&
    worker.proxyGroupId === task.proxyGroupId &&
    worker.region === task.expectedRegion &&
    worker.status === "available"
  );
}

Task assignment becomes stricter:

async function assignTask(task: AccountBoundBrowserTask) {
  const candidates = await workers.list();

  const worker = candidates.find((candidate) =>
    canRunTask(candidate, task)
  );

  if (!worker) {
    await queue.defer(task, {
      reason: "no_matching_account_context",
    });
    return;
  }

  await worker.lockProfile(task.profileId, task.taskId);
  await worker.run(task);
}

This is not just a performance detail. It is a correctness rule.

If the correct account context is unavailable, the safe behavior is to wait, defer, or ask for review.

The unsafe behavior is to run the task in a profile that looks “similar enough”.

Run a preflight check before page actions

Even when the scheduler selects the right worker, the worker should still verify runtime state before acting.

A preflight check can inspect:

Current profile ID
Expected account ID
Proxy group or outbound region
Login state
Current domain
Permission level for the requested action
Whether the profile is locked by another run
Whether the task requires human review

A preflight result might look like this:

{
  "task_id": "task_1042",
  "account_id": "acct_store_us_018",
  "profile_id": "profile_us_018",
  "expected_region": "US",
  "actual_region": "US",
  "login_state": "active",
  "profile_lock": "owned_by_current_task",
  "permission": "inspect_only",
  "preflight_status": "pass"
}

If the check fails, the worker should stop before performing the business action.

const preflight = await runPreflight(task);

if (preflight.status !== "pass") {
  await evidence.write({
    taskId: task.taskId,
    stopReason: preflight.reason,
    expected: preflight.expected,
    actual: preflight.actual,
  });

  throw new Error(`Preflight failed: ${preflight.reason}`);
}

A failed preflight is not a crash.

It is the system preventing an account-context mistake before it becomes a business mistake.

Lock the profile during execution

Profile locks prevent two workers from using the same logged-in environment at the same time.

Without a lock, this can happen:

Worker A opens Profile 018.
Worker B also opens Profile 018.
Worker A changes state.
Worker B reads an old assumption.
Both write different evidence.
The team cannot tell which run caused the final state.

A basic profile lock can include:

type ProfileLock = {
  profileId: string;
  taskId: string;
  workerId: string;
  lockedAt: string;
  expiresAt: string;
};

The lock needs a TTL because workers can crash.

The worker should refresh the lock while the task is running. If the worker dies, the lock eventually becomes stale and can be reviewed or released.

Do not silently steal locks unless the task is clearly safe to resume.

In account workflows, a stale lock often means the previous browser state is unknown. That should trigger inspection before retry.

Retries must preserve account ownership

Retries become risky when they ignore account context.

This is a bad retry rule:

If task fails, send it to any available worker.

This is safer:

If task fails, retry only in the same account context unless a human approves reassignment.

Retry metadata should preserve ownership:

{
  "retry_of": "task_1042",
  "allowed_profile_id": "profile_us_018",
  "allowed_proxy_group_id": "proxy_us_stable",
  "retry_reason": "navigation_timeout",
  "max_attempts": 2,
  "requires_review_after": 2
}

Some failures are safe to retry, such as a temporary navigation timeout before login state is touched.

Some failures should stop immediately:

Account mismatch detected
Region mismatch detected
Unexpected verification prompt
Submit action blocked by policy
Profile lock conflict
Page shows a different account identity than expected

A good automation system does not retry everything.

It classifies failures before deciding whether to continue.

Log expected context against actual context

When a browser task runs in a multi-account system, logging only “success” or “failed” is not enough.

The log should compare expected context with actual runtime context:

{
  "run_id": "run_20260615_001",
  "task_id": "task_1042",
  "worker_id": "worker_07",
  "expected_account_id": "acct_store_us_018",
  "actual_account_marker": "store-us-018",
  "expected_profile_id": "profile_us_018",
  "actual_profile_id": "profile_us_018",
  "expected_proxy_group": "proxy_us_stable",
  "actual_proxy_group": "proxy_us_stable",
  "preflight_status": "pass",
  "final_status": "completed"
}

This makes debugging much easier.

If the task fails, the team can see whether the script logic failed or whether the task entered the wrong environment.

That distinction matters.

A selector timeout is a script issue.
A profile mismatch is a routing issue.
A proxy mismatch is an environment issue.
A submit blocked by review policy is a permission issue.

Without context logs, all of these look like “automation failed”.

A practical routing checklist

Before scaling browser automation across many logged-in profiles, check these rules:

Every task has an accountId.
Every account maps to one expected profileId.
Every profile maps to an expected proxy group or region.
Workers cannot run account-bound tasks without passing preflight.
Profiles are locked during execution.
Retries preserve account ownership.
Review-required tasks cannot run as fully automated submit actions.
Logs compare expected context with actual runtime context.
Failure reasons separate script errors from environment errors.
Stale locks require inspection before release.

This checklist changes how the whole system behaves.

The scheduler stops treating browsers as disposable execution slots.

It starts treating each browser profile as an account-bound runtime.

Final thought

In simple automation, any browser can be a worker.

In multi-account automation, the browser profile is part of the task identity.

That means routing matters as much as scripting. A correct Playwright script can still produce the wrong result if it runs inside the wrong account context.

The safer model is to bind each task to its account, profile, proxy group, permission level, and evidence trail before execution starts.

That is the direction tools like Web4 Browser are moving toward: a multi-account browser workbench where profiles, proxies, AI tasks, logs, and human review are handled as one workflow instead of scattered settings.