Alexa Devices Unavailable in Home Assistant

Direct answer: If the Alexa Devices integration becomes unavailable in Home Assistant after working normally, first identify whether the failure is an Amazon service response, an authentication problem, or a local Home Assistant issue. A log entry containing Service Unavailable after earlier successful updates does not by itself mean that your password or multi-factor authentication is wrong. Preserve the logs, verify Amazon services and local connectivity, reload the integration once, and reauthenticate only when Home Assistant explicitly reports an authentication failure.

Symptoms covered by this guide

Alexa speakers and related entities become unavailable together.
The integration works after setup or reload but later stops updating.
Logs show Service Unavailable, CannotRetrieveData, timeouts, or failed coordinator updates.
Reloading the integration temporarily restores entities.
Home Assistant requests reauthentication or rejects a one-time password.
The Alexa app works while Home Assistant cannot update Alexa entities.

This guide concerns the official Alexa Devices integration documented by Home Assistant. It does not cover every custom Alexa component, the separate Alexa Smart Home skill, or general voice-assistant exposure. Confirm the integration name before applying any step.

Why Alexa Devices can become unavailable

The integration depends on several layers: Home Assistant, its network and DNS path, Amazon account authentication, multi-factor authentication, and Amazon endpoints that return device and communication data. A failure in any layer can make many entities unavailable at once. The correct recovery depends on the error class.

A public Home Assistant Core issue filed for Core 2026.6.4 documents a recurring case in which initial authentication and updates succeeded, followed later by a Service Unavailable response. In that report, reloading restored operation without reauthentication. That is evidence of one observed failure pattern, not proof that every unavailable Alexa integration has the same cause or that the behavior affects every version.

Before changing anything

Record the Home Assistant Core version and installation type.
Note when Alexa entities last updated successfully.
Open Settings, System, Logs and save the exact redacted error.
Confirm whether every Alexa entity failed or only one device.
Check whether the Alexa mobile app can currently see and control the same devices.
Create a current Home Assistant backup before deleting or reconfiguring the integration.

Do not post Amazon passwords, authenticator secrets, one-time codes, cookies, tokens, full diagnostic archives, email addresses, or household information. Redact identifiers from screenshots and logs.

Step 1: Distinguish service failure from authentication failure

Read the first meaningful exception near the failed update. A server-side Service Unavailable or HTTP 503 response means the requested service did not complete the request at that time. It is different from an unauthorized or forbidden response. Authentication failures commonly mention invalid credentials, reauthentication, an expired session, unauthorized access, or a failed one-time password.

If recent log entries show successful updates followed by a 503-style response, preserve that sequence. Do not repeatedly change the password. If the integration explicitly creates a repair or reauthentication flow, follow that flow using the official interface.

Step 2: Confirm the scope outside Home Assistant

Open the Alexa app and check device state. If the app also fails, the problem is likely upstream of Home Assistant: an Amazon service incident, account problem, household configuration, or device connectivity issue. If the app works, continue testing the Home Assistant path without assuming Amazon is fully healthy; different API functions can fail independently.

Check Home Assistant’s System status and any relevant integration alert. Review the official Alexa Devices integration documentation for current prerequisites. Avoid relying on old forum instructions because authentication requirements and supported features can change.

Step 3: Verify Home Assistant network, time, and DNS

Cloud authentication can fail when the Home Assistant host has no reliable internet path, resolves DNS incorrectly, has an inaccurate clock, or is being filtered by a firewall. Confirm that other cloud integrations update normally. Review host, supervisor, and core logs for broader network failures.

Accurate time matters for TLS certificates and time-based one-time passwords. Home Assistant OS normally manages time automatically, but a host that cannot reach its time source may drift. Check the host time and timezone rather than compensating by repeatedly generating codes.

If you use a custom DNS server, ad blocker, outbound proxy, VLAN policy, or firewall, temporarily test a known-safe rule change only if you understand the impact. Do not disable perimeter security broadly. Record the result and restore the previous rule after the test.

Step 4: Reload the integration once

Go to Settings, Devices & services, locate Alexa Devices, open its menu, and choose Reload. Watch the logs while it reloads. A successful reload that restores all entities without an authentication prompt indicates that the saved credentials were still accepted at that moment.

Reloading is a diagnostic action, not a permanent fix for a repeating upstream failure. Do not create an hourly reload automation as a first response. Repeated reloads can hide the timing and error needed for a useful bug report, increase traffic to an external service, and make the problem harder to diagnose.

Step 5: Reauthenticate only when requested

The official integration documentation requires an Amazon account and multi-factor authentication through an authenticator application, with the authenticator method configured appropriately in the Amazon account. Follow the current Home Assistant reauthentication flow and the official Amazon security interface.

Enter the account email, password, and current one-time password only in the authorized setup form. Confirm that the authenticator device clock is accurate. If several attempts fail, stop briefly rather than triggering additional account protection. Verify that you selected the correct Amazon account and regional marketplace.

If reauthentication succeeds but the integration later reports Service Unavailable, treat that as a separate runtime problem. Repeating the same login process is unlikely to fix a remote availability failure permanently.

Step 6: Check account and household details

Amazon Household membership, multiple profiles, regional accounts, and changes to security settings can affect available data. The official Home Assistant documentation notes a limitation involving reminders and accounts linked to an Alexa Household. Do not remove household members merely to test an unrelated unavailable-device problem.

Review recent changes: password reset, multi-factor method change, marketplace move, household change, revoked sessions, or new security alerts. Resolve suspicious account activity directly through Amazon before reconnecting third-party software.

Step 7: Rule out custom-component conflicts

If both the official integration and a custom Alexa component are installed, confirm which one owns the failing entities and log messages. Custom integrations are maintained separately and can use different authentication or update methods. Review Settings, Devices & services and the custom integration store before deleting anything.

Start Home Assistant in a controlled configuration only when you understand the consequences. Removing a custom integration can change entity IDs and break automations. Back up first and document current entity mappings.

Step 8: Compare versions and known issues

Record the exact Core version, not merely “latest.” Check the official release notes and the Home Assistant Core issue tracker for the same integration, error, and version. Read issue status and maintainer responses. A single open report does not establish a universal regression, and a closed report may be fixed only in a newer release.

Do not downgrade Home Assistant casually. Restoring an older backup can also roll back database schema, integrations, and configuration. If maintainers recommend a specific patch release, review its release notes and create a verified backup before updating.

How to interpret common results

Alexa app and Home Assistant both fail: investigate Amazon service, account, or device connectivity first.
App works; reload restores Home Assistant: preserve logs and investigate a coordinator, session, or remote endpoint failure.
Reauthentication requested: complete the official flow and verify the authenticator method.
401 or unauthorized: focus on credentials, session, account region, and security changes.
503 or Service Unavailable: avoid unnecessary password changes; check timing, service health, and known issues.
Only one entity fails: inspect that device, its account state, and whether the integration still exposes it.

Verify the recovery

Confirm the integration card shows no setup failure.
Confirm several Alexa entities have fresh states.
Test one non-critical entity or information update.
Check logs for repeated coordinator errors.
Wait longer than the previous failure interval.
Confirm a normal Home Assistant restart does not immediately reproduce the problem.

A successful reload is not sufficient when the problem previously returned after hours. Keep the observation window long enough to distinguish recovery from temporary relief.

Rollback and safe recovery

If a configuration change makes the problem worse, restore the previous DNS, firewall, or account setting and reload once. If you removed the integration, restore from a known backup only after considering changes made since that backup. Re-adding an integration may create different entity IDs, so review automations, dashboards, scripts, and exposed voice-assistant entities.

When to escalate

Prepare a concise report with the Core version, installation type, integration name, approximate failure time, first relevant stack trace, whether the Alexa app worked, whether Reload restored operation, and how long recovery lasted. Include diagnostics only after reviewing them for secrets. Search for an existing matching Core issue before creating a new one.

If the error suggests account compromise, stop technical troubleshooting and secure the Amazon account. Change credentials through the official account page, review devices and sessions, and confirm multi-factor methods.

Prevention

Keep Home Assistant on a supported release after reviewing breaking changes.
Maintain a verified backup before updates or integration removal.
Use a stable DNS and internet path for cloud integrations.
Keep the authenticator method available and its device clock accurate.
Document entity IDs before reconfiguration.
Avoid automated reload loops that conceal recurring faults.
Review integration alerts and release notes when behavior changes.

Build a timeline instead of treating every log line as the cause

Coordinator-based integrations can emit secondary errors after the first failure. Start with the earliest error in the same update cycle, then follow later messages in order. A timeout, DNS failure, or remote 503 can cause entities to become unavailable and produce additional warnings that are consequences rather than causes. Record the time of the last successful update, the first failed request, the moment entities changed state, and the result of one reload.

Compare that timeline with other events: a Home Assistant update, router restart, DNS change, Amazon password change, authenticator change, or an internet interruption. Correlation is not proof, but a precise timeline helps eliminate unrelated changes. If no configuration changed and the error begins with a remote service response, avoid rebuilding the integration before checking whether the service recovers.

Why aggressive retry automations are risky

An automation that reloads a failing cloud integration every few minutes may appear convenient, but it can create repeated authentication or API traffic, conceal the original error, and interfere with normal backoff behavior. It can also leave dependent automations alternating between available and unavailable states. Use a single manual reload as a diagnostic step. If maintainers later document a temporary workaround, follow its exact limits and remove it when a fixed release is installed.

Check dependent automations after recovery

When Alexa entities return, review automations that ran during the outage. An unavailable sensor may have prevented a condition from evaluating as expected, and state-based triggers normally do not replay missed transitions automatically. Do not assume that restoring the integration will reproduce reminders, timers, or notifications that were missed.

Use automation traces to confirm what happened. Test a non-critical path, verify entity state freshness, and inspect the trace for skipped conditions or unavailable inputs. Avoid testing announcements late at night or controls connected to safety-sensitive equipment.

Regional and account consistency checks

Confirm that the Amazon account, marketplace region, Alexa app session, and integration configuration refer to the same household. A region mismatch can resemble an empty or incomplete device list even when login succeeds. If the account has recently moved regions, document the previous and current marketplace before reconfiguration. Do not create duplicate Amazon accounts as a troubleshooting shortcut.

Sources

Last reviewed: September 8, 2026.

Related Troubliq guides: Start with the safe diagnostic method, browse troubleshooting guides, and review Home Assistant automation trigger diagnosis when the integration is available but an automation still does not run.

Final decision checklist

Reload once when credentials appear valid and the error is a temporary service response. Reauthenticate when Home Assistant explicitly requests it or logs show authorization failure. Investigate local network and time when several cloud services fail. Wait and document when a remote endpoint returns a temporary 503. Escalate with redacted evidence when the failure repeats on a current supported release. This sequence addresses the most likely layer while protecting the account and preserving useful evidence.

Find your next troubleshooting path

Use the related guide that matches the next confirmed layer of the failure. Avoid changing unrelated systems at the same time.

Alexa Devices integration becomes unavailable in Home Assistant: diagnose Service Unavailable errors