Incorrect Delivery for S3 and S3 Datalake

What to do

• Check whether you use RudderStack Data Processing Pipeline (US), Warehouses in us. Check your stack

  Paste a package.json, lockfile, Terraform or a list of domains at down.guide/stack to see every provider you depend on.

• Confirm your retries, queues and scheduled jobs caught up after the 2h 15m it lasted.

  Anything that failed between 2025-05-28 17:00 UTC and 2025-05-28 19:15 UTC may need a replay.

• Subscribe to RudderStack's feed to hear about the next one first. RSS feed

  https://down.guide/feed?provider=rudderstack works in Slack (/feed subscribe), Discord feed bots and any RSS reader.

Updates from RudderStack 2

1. identifiedMay 28, 2025, 5:00 PM UTC

   Issue has been identified with S3 and S3 datalake deliveries. Actively working on the fix.

   provider

2. resolvedMay 28, 2025, 7:15 PM UTC

   An issue was identified with the delivery module for S3 & S3_DATALAKE destinations, leading to the incorrect duplication of the prefix in the final file path. This resulted in data being uploaded to an unintended location, making it unavailable for any downstream consumption for the duration of the incident. The flag was enabled only for free tier and starter and growth customers. Follow the below recommended steps to recover the data: Prerequisite: Make sure the AWS CLI is installed and configured locally to access the relevant S3 bucket. 1. Go to the Rudderstack configuration page of your S3/S3 Datalake destinations and copy bucket name and prefix. 2. Copy all the files from the double-prefix path to the single prefix path. Command: aws s3 cp s3://{bucket_name}/{prefix}/{prefix}/ s3://{bucket_name}/{prefix}/ --recursive 3. Delete the original files (optional) Command:aws s3 rm s3://{bucket_name}/{prefix}/{prefix}/ --recursive

   provider

Corrections

None so far.

Something wrong on this page? Report an error or send us a note. Every fix is listed here.