Failed Logins (24h), Snowflake

​

At a glance

The count of failed authentication attempts against your Snowflake account in the last 24 hours, read from LOGIN_HISTORY. A healthy account sits at or near zero. A non-zero count is rarely benign: a burst of failures usually means one of three things, and a platform team needs to tell them apart fast. Either a credential went stale (a rotated service-account key still cached in a pipeline, an expired key-pair), or someone is fat-fingering a password, or the account is being probed: credential stuffing, a brute-force attempt, or a leaked username being tested. Snowflake is a data platform holding your entire analytics estate, so the security stakes are high. This card is the early-warning tripwire: the >10 alert fires before a slow probe becomes a successful breach, and well before the quarterly access review would ever surface it.

​

Calculation

failed_logins_24h =
  SELECT COUNT(*)
  FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY
  WHERE is_success = 'NO'
    AND event_timestamp >= now − 24h

breakdown = GROUP BY user_name, error_code, client_ip

• The reason code is the diagnosis. LOGIN_HISTORY.error_code and error_message tell you why the attempt failed: an incorrect password reads differently from an expired key-pair, which reads differently from a network-policy block. The error reason is what separates “stale credential” from “attack”.
• Group by user before you panic. Ten failures from one service account is almost always a single stale credential retrying on a loop. Ten failures spread across ten different usernames from one IP is credential stuffing. The raw count is identical; the shape is opposite. Always read the breakdown.
• Client IP names the source. A failure burst from a known office or pipeline IP is operational; the same burst from an unfamiliar geography or a cloud-provider IP range is a probe. Snowflake records client_ip on every row.
• Network-policy blocks count too. If you run an IP allowlist via a network policy, attempts from outside it land here as failures. A spike of these is usually a misconfigured client or a genuine outside probe, both worth seeing.
• Lockout interacts with the count. Snowflake locks a user for 15 minutes after 5 consecutive failures by default. A determined brute force therefore shows as bursts of ~5 then a pause, a recognisable sawtooth in the breakdown.

​

Worked example

1. FIVETRAN_SVC is the real story (28 of 34), and it is operational, not an attack. The error is JWT_TOKEN_INVALID: the key-pair the Fivetran connector authenticates with has been rotated in Snowflake but the new public key was never (or only partially) registered, or the old key was unset. The service account is retrying its sync every few minutes and failing each time. This is not a breach; it is a broken pipeline. The downstream impact is data: ingest has stalled, so warehouse tables are going stale. Cross-check Snowflake Event Ingest vs Ecom Orders, which will show ingest flatlined while orders keep flowing.
2. j.okafor (4 failures) is a human. Four INCORRECT_USERNAME_PASSWORD from the office VPN is someone mistyping their password after a holiday. Below the lockout threshold, self-resolving, no action beyond a note.
3. unknown (2 failures) is a probe to watch, not yet to act on. Two USER_DOES_NOT_EXIST from an unfamiliar IP is someone guessing usernames. Two is noise; if it climbs or starts hitting real usernames, it becomes credential stuffing and the response escalates to tightening the network policy.

Triage by shape, not by count:
  28 from one service account, one error code  → stale credential, fix the key-pair
  4  from one human, password error            → benign, self-resolves
  2  from "unknown" at an odd IP                → probe, monitor; escalate if it grows
The headline "34" alone would have looked like an attack. The breakdown shows it is mostly a broken sync.

1. The count is meaningless without the breakdown. “34 failed logins” could be a single stale service account or a coordinated attack. The error code and the per-user grouping are what tell you which, and they demand completely different responses.
2. Most failure bursts are operational, not malicious. Rotated keys, expired passwords, and misconfigured clients dwarf real attacks in frequency. Check for a stale credential first; treat as an attack only once the breakdown shows a spray across users or unfamiliar IPs.
3. A service-account failure burst is also a data-freshness incident. When a pipeline cannot authenticate, ingest stops. The security alert and a stale-data problem are the same event; pair with the ingest cross-channel card.

​

Sibling cards to reference together

​

Reconciling against the source

Failure count, last 24h: SELECT COUNT(*) FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY WHERE is_success = 'NO' AND event_timestamp >= DATEADD('hour', -24, CURRENT_TIMESTAMP()); Breakdown by user and reason: SELECT user_name, error_message, client_ip, COUNT(*) FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY WHERE is_success = 'NO' AND event_timestamp >= DATEADD('hour', -24, CURRENT_TIMESTAMP()) GROUP BY 1,2,3 ORDER BY 4 DESC; Low-latency check (last 7 days, no lag): SELECT * FROM TABLE(INFORMATION_SCHEMA.LOGIN_HISTORY(DATEADD('hour', -24, CURRENT_TIMESTAMP()), CURRENT_TIMESTAMP())) WHERE is_success = 'NO'; Managed console: Snowsight under Admin -> Users & Roles for user status (locked / disabled), and Monitoring -> Query History does not cover logins, so the login view above is the authoritative source. There is no separate console widget for failed logins; the LOGIN_HISTORY view is the native equivalent of this card.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre