Skip to main content
Most mobile login problems are the sign-in browser handoff or a stale session, and the fix depends on your platform, because the app signs in differently on each: Android hands off to Chrome (Custom Tabs), while iOS uses Safari (ASWebAuthenticationSession). Jump to yours.

Android

Chrome / Custom Tabs, Samsung Internet, Android System WebView, Okta passkey errors.

iOS

Safari sign-in, clearing website data, managed (Intune) devices.

​
Android

On Android, Rootly signs in through Chrome Custom Tabs, so most login issues trace back to Chrome, a non-Chrome default browser, or a stale Android System WebView.
Likely cause: sign-in completes in the browser, but the session handed back to the app is out of sync, often because a previous web login is still active.Fix:
  1. On the sign-in screen, tap the ⋮ menu (top-right) and choose Open in Chrome, then complete sign-in there.
  2. If it still loops, open Chrome, sign out of rootly.com, then reopen the app and sign in again.
Likely cause: your Okta org requires a passkey / security key / biometric (WebAuthn), and sign-in opened in a browser context that can’t perform it (commonly Samsung Internet, or a stale WebView).Fix:
  1. Make sure Chrome is your default browser (Settings → Apps → Default apps → Browser app). Some phones default to a browser that can’t complete this step, such as Samsung Internet.
  2. Force-stop Rootly, clear its cache and storage, and in Chrome clear cookies for rootly.com and okta.com.
  3. Update Chrome and Android System WebView, then retry.
If WebAuthn is required org-wide, your Okta admin can add a fallback MFA method or a mobile sign-on rule that doesn’t force WebAuthn. See Okta’s article.
Likely cause: a stale Android System WebView / Chrome cache fails before the handoff to your identity provider (so your IdP logs show nothing).
Likely cause: a per-app VPN scoped to Rootly only. Android hands sign-in off to an external browser — Chrome, or whichever custom-tab provider is set as default — and that browser runs outside the tunnel, so it cannot reach a corporate auth endpoint that is only reachable through the VPN. The app looks stuck and your identity provider logs show nothing, because the request never arrived.Fix: your Intune admin pushes the use_in_app_browser AppConfig key set to true. Sign-in then happens in an embedded web view inside the app process, which is inside the VPN tunnel. See Managed App Configuration.If your organization uses Intune with Rootly, SSO sign-in already runs in that embedded web view, so the key isn’t needed for it.
Likely cause: Conditional Access rejects the embedded browser; older app versions could leave the app waiting for a callback that finished elsewhere.Fix: update to the latest app, ensure Microsoft Authenticator is installed, and sign in with Microsoft. If it loops, close and reopen the app. You’re usually already signed in. See the Intune setup notes.

​
iOS

On iOS, Rootly signs in through Safari (ASWebAuthenticationSession), so there is no “Open in Chrome.” Issues here are usually a stale Safari session or a managed-device policy.
Likely cause: the Safari sign-in session is stale or didn’t hand back to the app.Fix:
  1. Update the Rootly app. The latest version uses a native in-app sign-in.
  2. Clear Safari data: Settings → Apps → Safari → Clear History and Website Data (to target just Rootly, use Settings → Safari → Advanced → Website Data, find rootly.com, and remove it).
Likely cause: Conditional Access requires an approved client; the older Safari/WebView path could stall.Fix: update to the latest app, ensure Microsoft Authenticator is installed, and tap Sign in with Microsoft. If it loops, close and reopen the app. See the Intune setup notes.
Fix: your Okta (or IdP) admin can add a fallback MFA method or a mobile sign-on rule so mobile sign-in isn’t forced through a security key. (The Android-specific browser steps don’t apply on iOS.)
Likely cause: a per-app VPN scoped to Rootly only, on a device that isn’t Intune-managed. iOS then signs in through Safari, which runs outside that tunnel, so a corporate auth endpoint reachable only through the VPN cannot be reached. Sign-in stalls and your identity provider logs show nothing.On an Intune-managed device, or when your organization uses Intune with Rootly, the app completes SSO in an embedded web view inside the app process, which stays inside the tunnel.Fix: widen the VPN profile to cover Safari as well as Rootly, or make the auth endpoint reachable without the VPN. Your MDM admin owns both.

​
Web & admin (any platform)

Likely cause: something in the path is filtering by source IP. SSO involves your browser, Rootly, and your identity provider, and a VPN changes the apparent source of that traffic — so an IdP sign-on policy, a Conditional Access rule, or a network egress filter can allow one path and block the other.Fix: compare a working and a failing attempt in your identity provider’s sign-in logs first. That tells you whether the request reached the IdP and was refused, or never arrived at all — and those have different owners. A refusal is an IdP policy question; a request that never arrives is a network one.If your network restricts outbound traffic, confirm the hostnames Rootly needs are reachable from inside the tunnel. See IP Allowlist.
Likely cause: some Chromium-based browsers (for example Brave) break the auth/refresh flow.Fix: use Google Chrome.
Likely cause: once SSO is enabled for an email domain, password sign-in is blocked for that domain, so a SAML misconfiguration can lock everyone out.Fix: validate the SAML connection before enforcing SSO. If you’re already locked out, contact support@rootly.com to recover access.
These are admin / configuration issues. Reach out to support@rootly.com and Rootly support will review your SSO/SCIM setup.
Still stuck? See Contacting Support for what to send us (your sign-in method, whether web login works, and a device dump), or email support@rootly.com.