--- title: Auto relogin slug: contact-center/auto-relogin-isautoreloginenabled docTags: createdAt: 2026-04-16T20:24:33.601Z --- # Auto relogin (`isAutoReloginEnabled`) This article documents the **contact center** server preference `isAutoReloginEnabled`, which controls whether the **web client** uses an enhanced keep-alive and **automatic re-login** path after prolonged connectivity loss. It complements the agent-facing steps in [Login at Ameyo](docId\:yRdLi1lQgHr_n_iZ38vtn). :::hint{type="info"} **Naming** — The preference key in the server preference store is `isAutoReloginEnabled`. The product UI may label this concept as “auto re-login” or similar. ::: *** ## Purpose When **enabled**, after the client detects sustained keep-alive / ping failures (or a keep-alive timeout), the application can navigate to an **auto re-login** flow. When connectivity returns, the client: 1. Verifies that the **same browser origin** is reachable (REST `/ameyorestapi/echo`). 2. For supported **agent-class** roles, **re-authenticates using credentials already held by the client** (force login), then **re-syncs** saved UI state (for example campaign, extension, agent status) so the user is **not** prompted to type user ID and password again on the login screen. When **disabled**, the client uses the **standard** keep-alive timer only; recovery from outages is left to normal session behavior and manual login if the session is lost. *** ## Configuration | Item | Detail | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Preference key** | `isAutoReloginEnabled` | | **Type** | Boolean (store and interpret as string `true` / `false` where applicable). | | **Scope (code)** | Read at **Contact Center** hierarchy via the server preference store (`CONTACT_CENTER` context and contact center id). | | **Who sets it** | Typically an **Administrator** (or operations) using your deployment’s **Server Preference Store** tooling for the target contact center. | | **After change** | Follow your standard process for applying server preference updates (for example **Reload Server Preference Store** where required — see [System Settings Tab](#)). | :::hint{type="warning"} **Same origin** — Recovery pings use the **current page host** (`Location`). The feature does **not** switch the browser to a different hostname (for example a manual “failover URL”). Designs that rely on DNS/VIP or reverse proxy so the **same URL** maps to a healthy node are compatible; designs that require the user to open a **different** host are not covered by this mechanism alone. ::: *** ## Related client behavior (reference) The following are **implementation details** useful for support and advanced troubleshooting. They are **not** separate administrator preferences in the codebase reviewed for this page: | Behavior | Notes | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Keep-alive interval** | Fixed client interval (**20 seconds**) between keep-alive attempts when auto re-login mode is active. | | **Keep-alive timeout check** | Separate **12 second** repeating check can treat a **stuck** keep-alive as overdue and trigger the auto re-login path. | | **Failures before auto re-login** | Consecutive keep-alive failures beyond a **configurable** maximum (default **3**, meaning **more than three** failures) can trigger auto re-login; the maximum can be supplied per user via `getMaxPingFailureCountForUser` (server). | | **Echo poll (recovery)** | After entering auto re-login, the client polls `/ameyorestapi/echo` about every **3 seconds** until HTTP **200** is received, then proceeds with re-login and state sync. | Fast failures (for example browser **Offline** in developer tools) may space attempts **20 seconds** apart; a short outage may therefore **recover without** entering the auto re-login screen if the next keep-alive succeeds before thresholds are met. *** ## Roles and UX | Area | Behavior (summary) | | ----------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Professional Agent, Executive** | After server is up again: **state sync** path including **force login** with stored credentials; then return to the previous place where possible; optional WebRTC re-registration when applicable. | | **Supervisor, Analyst, Administrator, User Access Manager** | After server is up: **save user data** event / local storage path rather than the full agent sync chain (see client `AutoReloginPresenter` implementation). | Exact role names in your deployment may follow your license and user-type configuration. *** ## Product version notes - Release notes have referred to `autoReloginPhoneAgent` and similar flags in patch history; align operational runbooks with the **actual** key in the preference store for your version (`isAutoReloginEnabled` for the path described here). - Validate behavior on your **specific** release before enabling in production (see for example **Contact Center - Patch Release Notes 6\_9\_0** in this repository’s Release Notes). *** ## See also - [Login at Ameyo](docId\:yRdLi1lQgHr_n_iZ38vtn) — end-user login steps and campaign selection. - [System Settings Tab](docId\:fBIW3gzuEBTT1NuAxJSOr) — reloading server preference store after changes. - [Generic Toolbar Integration](docId\:tl7A4UH-S7hsXQpmIAG44) — CRM loginHandler behavior mentions **auto re-login** in integration contexts.