Copy page

Snowflake

Authentication Logs

Collects Snowflake authentication events (login attempts) for monitoring sign-in activity, MFA usage, and failed logins.

Sync Type: Incremental

Requirements

1. You must have a Snowflake account and access to create a service account user, create a role, and assign it.
2. Monad uses key pair authentication — follow the Snowflake docs on how to set this up here. Be sure to have your private and public keys handy.
3. Create a new Snowflake service account user:

Code
CREATE USER monad_service_account
    COMMENT = 'Service account for monad snowflake authentication logs input'
    TYPE = 'service'
    RSA_PUBLIC_KEY='Your RSA Public Key';

4. Create a role and grant it the access needed to read the LOGIN_HISTORY view. Reading the view is a SELECT, so it runs on a warehouse and the role needs USAGE on one:

Code
CREATE ROLE monad_login_history_role;

-- Read access to the account-level usage views (LOGIN_HISTORY lives here)
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE monad_login_history_role;

-- A warehouse is required to execute the query
GRANT USAGE ON WAREHOUSE your_warehouse TO ROLE monad_login_history_role;

-- Grant the role to the service account
GRANT ROLE monad_login_history_role TO USER monad_service_account;

5. To read organization-wide logins (the organization_usage source), the input must connect to the organization account with a role that can read SNOWFLAKE.ORGANIZATION_USAGE (typically ACCOUNTADMIN).

Details

Monad reads Snowflake's built-in LOGIN_HISTORY view on the schedule defined by cron, tracking the latest EVENT_TIMESTAMP it has processed and fetching only new events on each run.

Choose where to read from with the Source setting:

• account_usage — SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY: all login attempts for the current account. ~365-day retention, up to ~2 hours of latency.
• organization_usage — SNOWFLAKE.ORGANIZATION_USAGE.LOGIN_HISTORY: login attempts across every account in the organization. Requires an Enterprise (or higher) edition account, up to ~24 hours of latency, and must be run from the organization account.

Note: Unlike the Users and Grants inputs (which use metadata SHOW commands), reading LOGIN_HISTORY is a SELECT and therefore runs on the configured virtual warehouse, consuming compute credits. Use a small, auto-suspending warehouse to keep this cost minimal.

Scheduling: Snowflake populates LOGIN_HISTORY with a latency of up to ~2 hours (up to ~24 hours for organization_usage), so events do not appear in the view immediately. Set the Cron schedule to run no more often than every 2 hours — a more frequent schedule wastes compute polling for data that isn't available yet and won't surface events any sooner.

Configuration

The following configuration defines the input parameters. Each field's specifications, such as type, requirements, and descriptions, are detailed below.

Settings

Setting	Type	Required	Description
Account	string	Yes	The unique identifier for your Snowflake account, typically in the form of 'organization-account_name'
User	string	Yes	The username of the Snowflake account used to establish the connection
Role	string	Yes	The name of the role to use (must be able to read the LOGIN_HISTORY view)
Warehouse	string	Yes	The Snowflake virtual warehouse used to execute the query (reading LOGIN_HISTORY runs on compute)
Source	string	Yes	The view to read from: account_usage (current account) or organization_usage (all accounts in the organization — requires an Enterprise or higher edition account). Default: account_usage
Authentication Type	string	Yes	Authentication method: "password" or "private key" (default: "private key")
Cron	string	Yes	Cron expression defining the sync schedule. Because LOGIN_HISTORY has up to ~2 hours of latency, schedule no more often than every 2 hours (e.g., "0 */2 * * *").

Secrets

Secret	Type	Required	Description
Private Key	string	Conditional	The private key used for authentication (required if using private key auth)
Password	string	Conditional	The user's password (required if using password auth)

Note: One of Private Key and Password is used to authenticate with this input, based on the selected Authentication Type.

Sample Record

Code
{
  "EVENT_ID": 384729104857,
  "EVENT_TIMESTAMP": "2026-06-30T14:22:05.123Z",
  "EVENT_TYPE": "LOGIN",
  "USER_NAME": "JSMITH",
  "CLIENT_IP": "203.0.113.42",
  "REPORTED_CLIENT_TYPE": "JDBC_DRIVER",
  "REPORTED_CLIENT_VERSION": "3.13.30",
  "FIRST_AUTHENTICATION_FACTOR": "PASSWORD",
  "SECOND_AUTHENTICATION_FACTOR": "DUO_PUSH",
  "IS_SUCCESS": "YES",
  "ERROR_CODE": null,
  "ERROR_MESSAGE": null,
  "RELATED_EVENT_ID": 0,
  "CONNECTION": null,
  "CLIENT_PRIVATE_LINK_ID": null,
  "FIRST_AUTHENTICATION_FACTOR_ID": null,
  "SECOND_AUTHENTICATION_FACTOR_ID": null,
  "LOGIN_DETAILS": null
}