Snowflake’s Snowsight host change can lock users out—even when Private Link is configured

Snowflake is moving Snowsight sign-in and subsequent API traffic from a shared regional host to an account-specific hostname. The change is scheduled to start October 16, 2026, but Snowflake labels it pending and says the date may change. For enterprises that filter outbound web traffic, this is not a cosmetic DNS update: users can lose access to Snowsight if the new hostname is absent from firewall, proxy or endpoint allowlists.

The topology—not the account setting—decides who is affected

Snowflake says the action test is how each user reaches Snowsight. Public connections behind a firewall, forward proxy or network allowlist require the new host. Pure Private Link traffic does not. The easy-to-miss case is a mixed environment: an account may have Private Link configured while some users still enter over a public connection; those public paths still need the update.

Before the change, Snowsight uses a shared host shaped like apps-api.c1.<region>.<cloud>.app.snowflake.com. Afterward, sign-in and later API calls also use <org-account>.<region>.<cloud>.snowflake.com. Snowflake explicitly says the account-specific host is additional, not a replacement, so administrators must retain the existing shared host too.

Treat this as a path-by-path rollout

Administrators can discover the required public hostname by running SELECT SYSTEM$ALLOWLIST(); and locating the ACCOUNT_PUBLIC entry. Snowflake instructs customers to allow outbound HTTPS to that host anywhere traffic is filtered, including corporate firewalls, secure web gateways, browser policies and ZTNA or SASE controls.

A single successful test is not sufficient evidence of readiness. Snowflake’s validation endpoint returns HTTP 200 when the tested path can reach the new host, but the company warns that different VPN profiles, device-posture groups, network segments or proxy policies may behave differently. Teams should therefore test representative office, remote and restrictive user paths before rollout.

The practical lesson for data-agent operators is broader than Snowsight. Browser-based analyst and agent workflows often inherit enterprise egress controls that are invisible at the application layer. A platform routing improvement can therefore present as an authentication outage or broken API session unless network dependencies are inventoried and tested per user population. Here, Snowflake provides the exact hostname discovery and validation steps; the remaining operational risk is whether every relevant path is included.