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: 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.)

​
Web & admin (any platform)

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 we’ll 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.