Troubleshooting Snowpipe¶

When a pipe doesn’t load the files that you expect, start with the diagnostic steps. They narrow most problems down to one of three places: the event notifications from your cloud storage service, the pipe itself, or the files. Then find your symptom in the sections that follow.

If you already know the symptom, go straight to its section:

To find out about problems as they happen, rather than after you notice missing data, set up error notifications, or record Snowpipe events and create an alert on them. To find out when a pipe stops loading files for any reason, including when event notifications stop arriving, see Get alerted when a pipe stops loading files.

Diagnose a problem¶

To find the cause of most Snowpipe problems, complete the following steps in order.

Step 1: Check the pipe status¶

Call SYSTEM$PIPE_STATUS, which returns a JSON object. You need the MONITOR or OWNERSHIP privilege on the pipe, or the MONITOR EXECUTION privilege on the account:

SELECT SYSTEM$PIPE_STATUS('mydb.myschema.orders_pipe');

Check the following fields:

If files load later than usual but pendingFileCount stays low, Snowflake might be throttling the pipe. Look for pipe_throttled events, which are recorded only if LOG_EVENT_LEVEL is WARN or more verbose.

Step 2: Check the copy history¶

Next, check what happened to each file. Query the COPY_HISTORY table function for the pipe’s target table. You need the MONITOR privilege on the account, or any privilege on the target table:

SELECT file_name, status, row_count, first_error_message, last_load_time
  FROM TABLE(mydb.INFORMATION_SCHEMA.COPY_HISTORY(
    TABLE_NAME => 'myschema.orders',
    START_TIME => DATEADD('hour', -24, CURRENT_TIMESTAMP())))
  ORDER BY last_load_time DESC;

The STATUS column shows the result for each file, such as Loaded, Partially loaded, Load failed, or Load in progress. By default (ON_ERROR = SKIP_FILE), Snowpipe doesn’t load a file that contains errors, and the file has the Load failed status. For a file that didn’t load completely, FIRST_ERROR_MESSAGE shows the first error in the file.

The table function covers the last 14 days. For older loads, query the COPY_HISTORY view in the Account Usage schema. To review recent loads without SQL, open the pipe’s Copy History tab in Snowsight. For more information, see Review copy history and pipe metrics.

If a file that you expect is missing from the results, check an earlier time range. If it’s still missing, one of the following happened:

• The file is still waiting in the pipe’s queue. If pendingFileCount isn’t 0, check oldestPendingFilePath and oldestFileTimestamp.
• The pipe never received a notification for the file, or the file is outside the pipe path. See Some staged files were never loaded.
• The pipe was dropped or recreated. The table function doesn’t return loads by a pipe that was dropped or recreated, so query the COPY_HISTORY view instead.
• The target table was truncated after the file loaded. The copy history shows only the loads after the latest truncate.

If you staged a file again with the same name, and the results show only one row for that file, with a LAST_LOAD_TIME earlier than when you staged it again, Snowpipe ignored the new copy. If you record Snowpipe events at the DEBUG level, an ignored file has a file_lifecycle event with a SKIPPED state. See Modified or corrected files don’t load.

Step 3: Get details about load errors¶

To get details about the errors in files that a pipe failed to load, query the VALIDATE_PIPE_LOAD table function. The function returns details such as the line and column where each error occurred and the rejected record:

SELECT *
  FROM TABLE(mydb.INFORMATION_SCHEMA.VALIDATE_PIPE_LOAD(
    PIPE_NAME => 'mydb.myschema.orders_pipe',
    START_TIME => DATEADD('hour', -24, CURRENT_TIMESTAMP())));

VALIDATE_PIPE_LOAD returns an error if the pipe’s COPY INTO statement transforms semi-structured data, such as JSON, Avro, ORC, Parquet, or XML. It returns results only for the role that owns the pipe, or for a role that has all of the following privileges: MONITOR on the pipe (or MONITOR EXECUTION on the account), USAGE on an external stage (or READ on an internal stage), and SELECT and INSERT on the target table.

To see every error in a file, you can also run a COPY INTO <table> statement for the same file with VALIDATION_MODE = RETURN_ALL_ERRORS. With this copy option, COPY INTO checks the file and returns its errors without loading any data. VALIDATION_MODE isn’t supported for Apache Iceberg™ tables, or for COPY INTO statements that transform data or use MATCH_BY_COLUMN_NAME.

If neither option works for your pipe, use the copy history. The FIRST_ERROR_MESSAGE, FIRST_ERROR_LINE_NUMBER, FIRST_ERROR_CHARACTER_POS, and FIRST_ERROR_COLUMN_NAME columns show where the first error is, and ERROR_COUNT shows how many rows have errors.

Pipe execution states¶

When executionState isn’t RUNNING, the pipe usually isn’t loading files. FAILING_OVER is the exception. The following table explains each state and what to do about it:

Load missed files after you fix a problem¶

Before you recreate a pipe to fix a problem, note when it stopped loading: the lastIngestedTimestamp value from Step 1 or, if you record Snowpipe events, the timestamp of the pipe_lifecycle event that reported the problem. The event’s TIMESTAMP value is in UTC and has no time zone, so add +00:00 when you use it, for example 2026-10-02T20:00:00+00:00. After you recreate a pipe, SYSTEM$PIPE_STATUS no longer returns the old pipe’s lastIngestedTimestamp, and the COPY_HISTORY table function no longer returns its loads, so you can’t look up this time afterward.

After you fix the cause, call SYSTEM$PIPE_STATUS and confirm that executionState is RUNNING and that pendingFileCount is going down. Then load the files that didn’t load while the problem lasted:

• Files that failed to load, for example with an access denied error or a remote file not found error, stay in the pipe’s load metadata, so Snowpipe doesn’t try them again, even with ALTER PIPE ... REFRESH. To list them, query the copy history from the time that the problem started:

  Copy code

  SELECT file_name, first_error_message, last_load_time
    FROM TABLE(mydb.INFORMATION_SCHEMA.COPY_HISTORY(
      TABLE_NAME => 'myschema.orders',
      START_TIME => '2026-10-02T13:00:00-07:00'::TIMESTAMP_LTZ))
    WHERE status = 'Load failed'
    ORDER BY last_load_time;
  

  If you recreated the pipe, the table function no longer returns the old pipe’s loads, so query the COPY_HISTORY view instead. Its data is usually up to 2 hours behind, but it can be up to 2 days behind for a table that has had few recent loads. To load the files that you find, see Reload a file that Snowpipe already processed.

• Files that the pipe never queued, such as files whose notifications it never received or that arrived while the target table was missing, don’t appear in the copy history. To load them, see Load historical or missed files. If you recreated the pipe, set MODIFIED_AFTER in ALTER PIPE ... REFRESH to the time that you noted. If you don’t, the new pipe loads files that the old pipe already loaded.

Files don’t load with automated loading¶

Use the results of Step 1 to find the section that matches your symptom.

Some staged files were never loaded¶

With automated loading, a pipe loads only the files that it receives event notifications for. If the copy history doesn’t list some files at all, the pipe probably never processed event notifications for them, for one of the following reasons:

• The files were staged before you configured event notifications.
• The pipe was paused for longer than 14 days, so some of its queued files were dropped.
• The files arrived while the target table was missing. See STOPPED_MISSING_TABLE in Pipe execution states.
• The files are outside the pipe path, or don’t match the PATTERN copy option. See Event notifications arrive, but the pipe doesn’t load the files.
• The files were written in a way that doesn’t send the event that Snowpipe listens for. See Large files in Amazon S3 don’t load and Files in Azure Data Lake Storage Gen2 don’t load.
• A notification failed to arrive.

To load these files, see Load historical or missed files.

Event notifications don’t reach Snowflake¶

If lastReceivedMessageTimestamp is missing or older than your newest files, Snowflake isn’t receiving event notifications from your cloud storage service. If the timestamp was updating and then stopped, confirm that the following configuration is still in place:

• Amazon S3: If you use Amazon SQS, the bucket’s event notification still sends s3:ObjectCreated events to the queue in the notification_channel column of the SHOW PIPES output. If you use Amazon SNS or Amazon EventBridge, that column shows the topic ARN instead. In that case, confirm that the bucket’s event notification or EventBridge rule still publishes to that topic, and that the topic still has a subscription for the queue in the notificationChannelName value of the SYSTEM$PIPE_STATUS output. If the topic’s subscription for the queue was deleted, see Snowpipe stops loading after an Amazon SNS subscription is deleted.
• Google Cloud Storage: channelErrorMessage in the SYSTEM$PIPE_STATUS output is empty or starts with no monitoring permission, the Pub/Sub subscription still exists, and the Snowflake service account still has the roles that it needs. See also Loads from Google Cloud Storage are delayed or files are missed.
• Microsoft Azure: channelErrorMessage is empty, and the Event Grid subscription still sends events to the storage queue that the notification integration references.

For the setup steps for each cloud, see Automate Snowpipe for Amazon S3, Automate Snowpipe for Google Cloud Storage, or Automate Snowpipe for Microsoft Azure Blob Storage. The sections that follow describe more specific causes.

After you fix the configuration, load the files that were staged while notifications weren’t arriving. For more information, see Load historical or missed files.

Event notifications arrive, but the pipe doesn’t load the files¶

If lastReceivedMessageTimestamp is recent but lastForwardedMessageTimestamp isn’t, the notification channel receives notifications, but none of them are for files in the location that the pipe watches. Several pipes, and several buckets in the same region, can share a channel, so the recent notifications might belong to other pipes. lastForwardedFilePath shows the last file that Snowpipe forwarded to the pipe. Check the following:

• Notifications for your files: Confirm that your storage location still sends event notifications for the path where your files land. For more information, see Event notifications don’t reach Snowflake.
• The pipe path: The pipe loads files only from its pipe path, which is the path in its FROM clause that Snowflake appends to the stage URL. Compare that combined path with the location where your application writes files.
• The PATTERN copy option: If the pipe’s COPY INTO statement includes PATTERN, check whether the regular expression filters out the files. Snowpipe forwards notifications based only on the path, so lastForwardedMessageTimestamp can be recent even when PATTERN filters out every file.

To change the pattern or the pipe path, recreate the pipe as described in Recreate a pipe safely, and then load the files that it missed, as described in Load missed files after you fix a problem.

Large files in Amazon S3 don’t load¶

When an application uploads a large file to Amazon S3 with a multipart upload, S3 sends an s3:ObjectCreated:CompleteMultipartUpload event. If the event notification for your bucket includes only s3:ObjectCreated:Put, s3:ObjectCreated:Post, or s3:ObjectCreated:Copy, Snowpipe never learns about these files, and they don’t appear in the copy history or in SYSTEM$PIPE_STATUS. Multipart uploads are typically used for files larger than 8 to 16 MiB, depending on the client that uploads the files. For example, the AWS CLI uses a multipart upload for files larger than 8 MiB by default.

To fix this problem, complete the following steps:

1. In the Amazon S3 console, open the bucket for your stage, and then select Properties » Event notifications.
2. Change the event types for the notification to All object create events, or add s3:ObjectCreated:CompleteMultipartUpload.
3. Upload a large file, and then confirm that it appears in the copy history.
4. Load the large files that were uploaded before you changed the event types. For more information, see Load historical or missed files.

Snowpipe stops loading after an Amazon SNS subscription is deleted¶

The first time that you create a pipe that references an Amazon SNS topic, Snowflake subscribes a Snowflake-owned Amazon SQS queue to the topic. If an AWS administrator deletes that subscription, every pipe that references the topic stops receiving event notifications.

Before you recreate the pipes, note when each one stopped loading, as described in Load missed files after you fix a problem, so that you can load the files that it missed afterward. Then use one of the following options:

• Wait 72 hours after the subscription was deleted, until Amazon SNS clears it, and then recreate every pipe that references the topic, with the same topic in the pipe definition. For more information, see the Amazon SNS documentation.
• To avoid the 72-hour wait, create an SNS topic with a different name, and then recreate the pipes with the new topic.

For the steps to create a pipe that uses SNS, see Option 2: Send S3 event notifications through Amazon SNS in Automate Snowpipe for Amazon S3.

Files in Azure Data Lake Storage Gen2 don’t load¶

Some third-party clients don’t call FlushWithClose in the Azure Data Lake Storage Gen2 REST API. Without that call, Azure doesn’t send the event that tells Snowpipe that a file is ready. To load these files, call the Azure Data Lake Storage Gen2 REST API yourself to flush and close the files. For more information, see the Microsoft documentation for the Flush method and for the Path Update operation.

If your clients do call FlushWithClose, check that the Event Grid subscription for the storage account doesn’t filter out FlushWithClose events. For the supported events, see Automate Snowpipe for Microsoft Azure Blob Storage. After you fix the filter, load the files that arrived before the fix, as described in Load historical or missed files.

Loads from Google Cloud Storage are delayed or files are missed¶

If loads from Google Cloud Storage are delayed or files are missed, check the following:

• The bucket notification. The notification must send OBJECT_FINALIZE events in the JSON payload format, and its object prefix must cover the pipe’s path. If a message has no payload, Snowpipe discards it without reporting an error in channelErrorMessage or in the event table, so the only symptom is that the file never loads. For more information, see Step 2: Create a Pub/Sub topic and subscription.
• Other consumers of the subscription. If another application pulls messages from the same subscription, each consumer receives only some of the messages, and the pipe misses files. Use a separate subscription for Snowflake.
• The Snowflake service account’s roles. The service account needs the Pub/Sub Subscriber role on the subscription and the Monitoring Viewer role on the project. Without the Monitoring Viewer role, CREATE PIPE fails with a Could not monitor error. If the role is removed after you create the pipe, Snowpipe keeps loading files, but the numOutstandingMessagesOnChannel field in the output of SYSTEM$PIPE_STATUS is no longer accurate, and the channelErrorMessage field reports no monitoring permission. Loading can also slow down when many messages are waiting in the subscription. To grant the roles, see Step 4: Grant Snowflake access to the subscription.

After you fix the problem, load any files that the pipe missed, as described in Load historical or missed files.

Automated loading doesn’t work across government and commercial regions¶

The government regions of the cloud providers don’t allow event notifications to be sent to or from commercial regions. As a result, automated loading doesn’t work when the account is in a commercial region and the bucket is in a government region, or the reverse. For more information, see AWS GovCloud (US) and Azure Government.

Files don’t load with the REST API¶

If your application calls the Snowpipe REST API, check the following:

• Authentication: The REST API uses either key pair authentication with a JSON Web Token (JWT) or workload identity federation. The Snowflake Ingest SDKs for Java and Python generate the JWT for you. If you call the endpoints directly, you get the token yourself. A request with an invalid or expired token returns HTTP error 401. For more information, see Authentication and access control. If Snowflake rejects the JWT, see JWT token is invalid.
• Invalid requests: HTTP error 400 means that the request is invalid. For example, the request has no files, a file path is longer than 1,024 bytes, a required parameter is missing or invalid, or the pipe is a clone in the STOPPED_CLONED state. Correct the request before you send it again. For a cloned pipe, see Pipe execution states.
• Pipe name and privileges: HTTP error 404 means that Snowflake doesn’t recognize the pipe name, or that the role has no privileges on the pipe or on the database and schema that contain it. HTTP error 403 means that the role has privileges on the pipe, but not the privilege that the endpoint requires. For more information, see Grant access privileges.
• Load status: Call the insertReport or loadHistoryScan endpoint to see what happened to the files that you submitted. For more information, see Snowpipe REST API reference.
• Rate limits: HTTP error 429 means that a request exceeded a rate limit or, for insertFiles, contained more than 5,000 files. If insertFiles returns 429, Snowflake didn’t queue the files. Split lists of more than 5,000 files into smaller requests, and submit the files again after a delay. Wait longer between retries if the error repeats. If loadHistoryScan returns 429, call it less often and with a narrower time range, or use insertReport instead. For more information, see Handle errors and retries and pipe_throttled events.
• The pipe and the files: Complete the diagnostic steps to check the pipe status and the copy history.

Modified or corrected files don’t load¶

Snowpipe ignores any file whose path and name match a file in the pipe’s load metadata, which records the files that the pipe processed in the last 14 days, including files that failed to load. Snowpipe ignores a matching file even if you modify it or run ALTER PIPE ... REFRESH. Truncating the target table doesn’t clear the pipe’s load metadata.

To load a corrected or modified file, see Reload a file that Snowpipe already processed.

Duplicate data in the target table¶

To find files that loaded more than once, and which pipe or COPY INTO statement loaded them, query the copy history. Use a role that has the MONITOR privilege on the pipe. Without it, the PIPE_NAME column is NULL for Snowpipe loads, and the query reports them as COPY INTO loads:

SELECT file_name,
       COUNT(*) AS load_count,
       ARRAY_AGG(COALESCE(pipe_name, 'COPY INTO')) AS loaded_by
  FROM TABLE(mydb.INFORMATION_SCHEMA.COPY_HISTORY(
    TABLE_NAME => 'myschema.orders',
    START_TIME => DATEADD('day', -14, CURRENT_TIMESTAMP())))
  WHERE status IN ('Loaded', 'Partially loaded')
  GROUP BY file_name
  HAVING COUNT(*) > 1;

The table function covers only the last 14 days and doesn’t return loads by a pipe that was dropped or recreated. To find duplicates from a recreated pipe, or from a file that was staged again after 14 days, query the COPY_HISTORY view instead:

SELECT file_name,
       COUNT(*) AS load_count,
       ARRAY_AGG(COALESCE(pipe_name, 'COPY INTO')) AS loaded_by
  FROM SNOWFLAKE.ACCOUNT_USAGE.COPY_HISTORY
  WHERE table_catalog_name = 'MYDB'
    AND table_schema_name = 'MYSCHEMA'
    AND table_name = 'ORDERS'
    AND status IN ('Loaded', 'Partially loaded')
    AND last_load_time >= DATEADD('day', -90, CURRENT_TIMESTAMP())
  GROUP BY file_name
  HAVING COUNT(*) > 1;

If rows appear in the target table more than once, check for the following causes:

• Overlapping pipes: Two pipes that load from overlapping paths, such as <storage_location>/path1/ and <storage_location>/path1/path2/, both load the files in the inner path. To compare the paths in your pipe definitions, run SHOW PIPES or query the PIPES view.
• A path without a trailing slash: A stage URL such as s3://mybucket/orders, or a pipe path such as orders, also matches orders_archive/, so a pipe can load files from folders that you didn’t intend. If another pipe loads that folder, both pipes load the same files. End stage URLs and pipe paths with a forward slash (/). For more information, see Give each pipe its own location.
• Bulk loads of the same files: COPY INTO and Snowpipe keep separate load metadata, so a COPY INTO statement that loads files from the same location as a pipe can load them again.
• Files staged again after 14 days: Snowpipe loads a file with the same name again after the file’s record in the pipe’s load metadata expires.
• A recreated pipe: Recreating a pipe drops its load metadata, so ALTER PIPE ... REFRESH can load files again afterward. For the safe procedure, see Recreate a pipe safely.
• A cloned pipe: After you resume a pipe in a cloned database or schema, it receives event notifications for new files in the location that it watches, like the source pipe. If its COPY INTO statement names the target table as db.schema.table, or as schema.table in a cloned schema, it loads the data into the source table, not the clone. For more information, see Pipe execution states.
• A partial load followed by a reload: If a pipe uses ON_ERROR = CONTINUE, the rows that loaded from a file with errors stay in the table when you reload the file.

Common error messages¶

The following sections describe common Snowpipe error messages and how to resolve them. These messages appear in the FIRST_ERROR_MESSAGE column of the copy history, in the error field of SYSTEM$PIPE_STATUS, or in Snowpipe events.

Remote file was not found¶

You might see the following error message:

Remote file '<file_url>' was not found. There are several potential causes. The file might not exist. The required credentials may be missing or invalid.

Snowpipe received a notification for a file, but it couldn’t find the file when it tried to load it. Check the following:

• The file still exists: Confirm that the file is at the path in the error message. If an application or a lifecycle rule deletes or moves files before Snowpipe loads them, change the application or rule so that it waits until Snowpipe loads the files. For more information, see Delete files after Snowpipe loads them.
• The stage credentials are valid: Confirm that the storage integration or credentials for the stage still grant access to the location.
• No other load removed the file: If you also load the same files with COPY INTO and PURGE = TRUE, that load can delete a file before Snowpipe loads it. Don’t purge files that a pipe also loads.

After you fix the problem, load the files that failed. For more information, see Load missed files after you fix a problem.

Access denied errors¶

You might see either of the following error messages:

Failed to access remote file: access denied. Please check your credentials

Failure using stage area. Cause: [Access Denied (Status Code: 403; Error Code: AccessDenied)]

Your cloud storage service rejected Snowflake’s request to read the stage location or the file. Verify the storage integration or credentials for the stage, and check the permissions that they grant on the bucket or container and on the files to load. For the permissions that each cloud requires, see Automate Snowpipe for Amazon S3, Automate Snowpipe for Google Cloud Storage, or Automate Snowpipe for Microsoft Azure Blob Storage. After you fix the permissions, load the files that failed. For more information, see Load missed files after you fix a problem.

JWT token is invalid¶

You might see the following error message:

snowflake.ingest.error.IngestResponseError: Http Error: 401, Vender Code: 390144, Message: JWT token is invalid.

A call to the Snowpipe REST API included a JSON Web Token that Snowflake couldn’t validate. Check the following:

• The token is signed with the private key whose public key is assigned to the user. Run DESCRIBE USER and confirm that RSA_PUBLIC_KEY_FP or RSA_PUBLIC_KEY_2_FP matches the fingerprint in the token.
• The account identifier and user name in the token use all uppercase characters.
• The token hasn’t expired. A token is valid for at most one hour after it’s issued.

For more information, see Set up the Snowpipe REST API and Authenticating to the server.

003139=SQL compilation error:\nIntegration ''{0}'' associated with the stage ''{1}'' cannot be found.

After you set the stage’s STORAGE_INTEGRATION parameter, the pipes that reference the stage use the integration for their next load, so you don’t need to recreate them. To load the files that failed while the integration was missing, see Load missed files after you fix a problem.

Load times recorded with CURRENT_TIMESTAMP are earlier than expected¶

If a column captures the load time with CURRENT_TIMESTAMP as a default value or in the pipe’s COPY INTO statement, its values can be a few hours earlier than the LAST_LOAD_TIME values that the COPY_HISTORY table function or the COPY_HISTORY view returns. The difference occurs because Snowflake evaluates CURRENT_TIMESTAMP when it compiles the load operation in cloud services, rather than when it commits the rows to the table.

All of the following functions have this problem, so don’t use them to record load times, either in a pipe’s COPY INTO statement or as a column default value:

• CURRENT_DATE
• CURRENT_TIME
• CURRENT_TIMESTAMP
• GETDATE
• LOCALTIME
• LOCALTIMESTAMP
• SYSDATE
• SYSTIMESTAMP

Instead, to record when each row is loaded, enable row timestamps on the target table (ROW_TIMESTAMP = TRUE) and query the METADATA$ROW_LAST_COMMIT_TIME metadata column, which records when each row was last committed. Keep the following in mind:

• Rows that were loaded before you enabled row timestamps have a NULL value.
• If a row is updated after it loads, the value reflects the update, not the load.
• Row timestamps aren’t supported for Iceberg tables.