Reliability
Keep account work recoverable
Browser sessions hold valuable work. Isoline gives each profile separate state, manages session ownership, and keeps saved profile versions available for recovery.
Build recovery into everyday work
Name profiles clearly, keep team access current, close sessions before handing them over, and verify an important workflow after restoring a saved version.
What reliable browser work needs
These are the product behaviors to evaluate with your own profiles and team. Performance depends on the device, network, websites, and profile size.
| Workflow | What it means | How to check it | In Isoline |
|---|---|---|---|
| Separate browser state Per profile | Cookies, storage, settings, and extensions belong to the selected profile. | Open two profiles and verify that signing in or changing state in one leaves the other unchanged. | Profile isolation |
| Saved profile versions Recoverable work | Return a profile to a saved version when a change needs to be reversed. | Save a known state, make a reversible change, and verify the restored profile with your real workflow. | Backup and restore |
| Clear session ownership Team handovers | Workspace permissions and session locks coordinate who can use a profile. | Hand a profile to an authorized teammate and verify the session is closed and saved before it changes hands. | Workspace access control |
| Maintained browser Chromium | Browser updates carry upstream fixes through a dedicated update process. | Review the current browser version and update notices before relying on a sensitive workflow. | Browser updates |
Check your own workload
A browser can behave differently with ten lightweight profiles and with a large, extension-heavy workload. Include these checks in your evaluation.
- Cold and warm launch time for a profile of a given size.
- Memory and disk cost per running profile, and how many profiles one machine sustains.
- Crash rate under sustained multi-profile use.
- Restore time for a large profile, and how it degrades as history and cache grow.
- Synchronization throughput and conflict behaviour for a team working in parallel.
- Compatibility with your Mac, browser extensions, proxies, and target websites.
How we discuss performance
We publish numerical results only with enough context to reproduce and interpret them.
- A written method, published before the run, that defines the population, the repetitions, and what counts as a failure.
- A committed script and pinned dependencies, so the campaign can be repeated.
- The exact build identifier, platform, and date the result came from.
- Every failure accounted for, including the ones excluded and the reason for excluding them.
- A separate statement of what the result does not cover.