“Snowflake logs” means one of two things, and the export works the same for both. It can be security data your team stores in Snowflake tables. Or it can be Snowflake’s own audit trail, the SNOWFLAKE.ACCOUNT_USAGE views such as LOGIN_HISTORY and QUERY_HISTORY. For small pulls, run the query in SnowSQL with JSON output. For anything bigger, unload with COPY INTO a stage using FILE_FORMAT = (TYPE = JSON), and download the files with GET.
Snowflake’s own logs drew a lot of attention in 2024, when attackers used stolen credentials to log in to customer accounts that didn’t enforce MFA. Login and query history are now standard asks in an investigation. Prime Core has more than 24,000 unique detection rules, mapped to 676 MITRE ATT&CK techniques. Below is how to get the data out, sanitize it, and investigate it for free in LogTotal.
Before you start
Access to ACCOUNT_USAGE. By default, only ACCOUNTADMIN can read these views. Other roles need the IMPORTED PRIVILEGES grant on the SNOWFLAKE database, or one of its database roles.
Latency and retention. ACCOUNT_USAGE views keep a year of history but lag behind by up to a couple of hours. For the last seven days with no lag, the INFORMATION_SCHEMA.LOGIN_HISTORY table function is an alternative.
A warehouse. Queries and unloads need a running warehouse, and they consume credits. Filter by time.
Option 1: SnowSQL with JSON output (small pulls)
snowsql -q "SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY
WHERE EVENT_TIMESTAMP >= '2026-10-19' AND EVENT_TIMESTAMP < '2026-10-20'" \
-o output_format=json -o friendly=false -o timing=false > sf_logins_1019.json
jq -c '.[]' sf_logins_1019.json > sf_logins_1019.jsonl
Option 2: Unload to a stage (larger exports)
COPY INTO @~/exports/login_history_1019/
FROM (
SELECT OBJECT_CONSTRUCT(*)
FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY
WHERE EVENT_TIMESTAMP >= '2026-10-19' AND EVENT_TIMESTAMP < '2026-10-20'
)
FILE_FORMAT = (TYPE = JSON COMPRESSION = NONE)
OVERWRITE = TRUE;
JSON unloads need a single column, which is why the query wraps each row in OBJECT_CONSTRUCT(*). That function leaves out NULL fields. Then download from your user stage (@~):
GET @~/exports/login_history_1019/ file:///tmp/sf_export/;
and combine the files with cat /tmp/sf_export/* > sf_logins_1019.jsonl. The same pattern works for your own security tables. Swap in the table name and its timestamp column.
What to look for in login history
Look for failed logins (IS_SUCCESS = ‘NO’) in bursts, and password logins without a second factor (SECOND_AUTHENTICATION_FACTOR empty). Note logins from client IPs and client types you don’t recognize. Then follow those sessions into QUERY_HISTORY to see what was read.
Upload, sanitize and review in LogTotal
- Upload. Open logtotal.com and drop in the .jsonl file.
- Sanitize.
- Review.
When it goes wrong
| Symptom | Likely cause | Fix |
|---|---|---|
| Object does not exist or not authorized on ACCOUNT_USAGE | Role lacks access to the SNOWFLAKE database | Ask for IMPORTED PRIVILEGES or a database role |
| Today’s logins missing | ACCOUNT_USAGE latency | Use INFORMATION_SCHEMA.LOGIN_HISTORY for recent events |
| COPY INTO error about columns | JSON unload needs one column | Wrap rows in OBJECT_CONSTRUCT(*) |
| Fields missing in the JSON | OBJECT_CONSTRUCT drops NULL values | Expected; absent means NULL |
| GET fails | Not run from SnowSQL or the Snowflake CLI | GET runs from a client, not the web UI |
FAQ
Can I do this in the web interface?
Querying, yes. Downloads from the web interface aren’t JSON. The client route above gives you JSON lines.
What about Snowflake event tables?
Event tables hold logs and traces from your own functions and apps. Export them the same way as any table.