A test that passes in the mabl Trainer or in a local run can fail in the cloud if it relies on configuration that exists on your machine but not on mabl's infrastructure. Cloud runs start fresh, with none of the logins, network access, or settings you had locally. This article identifies five differences behind most cloud-only failures, how each shows up, and where to fix it.
| What you see in the cloud run | Most likely difference |
|---|---|
| Fails at login with a 401, or bounces back to the sign-in page | No signed-in session |
| First page load times out or is refused; hostname doesn't resolve | Traffic comes from a different place |
| A step times out and the screenshot shows a verification page | Something treats the run as a bot |
| Internal URL fails in the cloud but works in the Trainer | The Trainer and the cloud run take different routes |
| Find step or assertion fails on a page that looks different | The cloud sees a different version of your app |
The cloud browser has no signed-in session
Every cloud run starts in a new browser, and so does the Trainer. The difference is the machine underneath. On your own machine, the browser can inherit your operating system login, a device certificate, or a managed-browser policy that your identity provider trusts, so single sign-on completes without asking you. In the cloud there is no such machine, so the app sees a stranger.
Windows-integrated authentication (NTLM or Negotiate) is the strictest case: it depends on a domain session the cloud browser never has, so it can't work from a cloud run at all.
How it shows up: the test fails at or right after login, often with a 401 or a redirect back to the sign-in page.
Where to fix it: give the test its own login. In the Desktop App, turn on Block single sign-on under browser overrides so the Trainer sees the same login page the cloud does. Then create a dedicated test account with a username and password, record the login as a flow, and add MFA authenticator steps if the account requires them. Logging into your app covers the details and the limitations, including NTLM.
Traffic comes from a different place
From your machine, requests reach your app from inside your network. From the cloud, they arrive from mabl's static IP addresses, or from your Link Agent's host if the environment uses mabl Link. Firewalls, IP-restricted accounts, and geographic rules all see a different source.
How it shows up: the very first page load either times out or is refused, before the test does anything. Internal hostnames fail to resolve.
Where to fix it: if your app isn't reachable from the public internet, you need one of two approaches: allowlist mabl's IP addresses at your firewall, or run a Link Agent inside your network. Choosing between mabl Link and static IP allowlisting helps you decide, and Setting up your network for mabl lists what your network needs to allow.
Something between mabl and your app treats the run as a bot
Your own firewall may admit a cloud run while a service in front of your app, such as a content delivery network or identity provider, still treats it as a bot.
How it shows up: a step times out waiting for an element, and the screenshot or DOM snapshot shows a verification page or CAPTCHA instead of your app.
Where to fix it: Troubleshooting connectivity issues explains how to confirm the edge is the cause and what to do about it.
The Trainer and the cloud run take different routes
By default, the Trainer runs a browser on your machine, so its traffic goes straight from your machine to your app. A test that works in the Trainer against an internal URL proves that your workstation can reach the app, not that mabl's cloud can.
Cloud runs send browser traffic through a Link Agent only if the test's environment is set to use a Link tunnel. Two options let a test pass by a route that its scheduled cloud runs don't use:
- Training over a Link tunnel. You choose the tunnel each time you launch the Trainer, and mabl doesn't save it with the test or its environment. A test trained over a tunnel still needs its environment set to use mabl Link before cloud runs go through it.
- Routing a run through your computer. A cloud run that uses your personal Link tunnel reaches whatever your computer reaches. The same test without your personal tunnel, such as in a plan or a deployment event, uses only the environment's tunnels.
Requires Link 3.0 or later
Training over a tunnel and personal Link tunnels require Link 3.0 or later. Link 3.0 is turned on per account. If your account still uses legacy Link, see Migrating from legacy Link to Link 3.0.
How it shows up: cloud runs against an internal URL fail on the first page, while the Trainer, local runs, or runs routed through your computer pass.
Where to fix it: check that the environment uses a Link tunnel with a connected agent, then run a cloud test. See Running tests over mabl Link and Troubleshooting issues with mabl Link.
The cloud sees a different version of your app
Apps that vary what they serve by session, cookie, or IP address can show a cloud run something your machine never saw: a different A/B variant, a feature flag in a different state, or a load balancer routing the run to a different backend.
How it shows up: the test fails on a find step because the page is laid out differently, or an assertion fails on a value that differs between variants.
Where to fix it: make the variant explicit in the test, with a set cookie step, a starting URL, or an API call to your feature flag provider. Automating tests across A/B variants lists the option for each way teams implement variants.