sentinel-2-l2a collection: ~33% of scenes present on S3 missing from the STAC catalog

[GioZadig]

My company and I are operating a calculation pipeline over Sentinel-2 L2A imagery bands for a set of 75 MGRS tiles covering Italy and surrounding Mediterranean areas (UTM zones 32S, 32T, 33S, 33T, 34T).

We have verified, tile by tile, which scenes are present on s3://sentinel-cogs/sentinel-s2-l2a-cogs/ and which of those are discoverable via the STAC API at https://earth-search.aws.element84.com/v1 (collection sentinel-2-l2a). The gap is significant and is blocking part of our operational workflow, since out of 43194 scenes confirmed present on S3 across our 75 tiles: on STAC 28800 (66.7%), not on STAC 14394 (33.3%).

Our current pipeline is the following (we would like to keep it like that).
We have two distinct ingestion paths:

1. New scene ingestion (primary): triggered by the cirrus-v0-publish SNS topic, which fires when a new scene lands on s3://sentinel-cogs/sentinel-s2-l2a-cogs/. This path is unaffected by STAC availability — we consume the S3 path directly from the SNS message.
2. Recalculation (error recovery, reprocessing): driven by a Lambda, which queries the earth-search STAC API, to discover which scene IDs to process, finally dispatching calculation jobs.

We understand from the README that you are aware of indexing gaps and are working on them. We open this issue to:

1. Confirm that this gap is still open as of April 2026, in case it helps prioritize specific tiles or date ranges.
2. Ask what the recommended workaround is for pipelines that depend on STAC for recalculation

Thank you for your assistance and for maintaining this infrastructure.

[tylanderson]

Thanks for reaching out and glad to hear the data has been helpful.

To clarify, both the scenes and stac items are missing during these time periods as a result of ESA's reprocessing campaign, so using the v0 topic won't show additional scenes that aren't indexed in STAC. We're actively ingesting the missing periods, as well as newly published data, but due to some changes on how this data is sourced we're planning on releasing a updated v2 endpoint, so even though we've made significant progress in ingestion you won't see it on the V1 or V0 topics yet.

Using the v1 sns topic may help you with your recalcation issue if I understand it. There a "status" attribute is set to updated if the scene already existed but was reprocessed by ESA or fixed from our end.

[GioZadig]

Thank you for the answer, Tyler.
I'm not sure I was clear, so I will try to make you an example of a typical situation where we encounter the problem using our workflow.

• some time ago we received, via the cirrus-v0-publish SNS topic, the notification that a new scene has been loaded for a tile in that date
• we performed our calculations, taking the data from your S3
• some time later we noticed that we want to remake te calculations for that scene, so we interrogate the STAC catalogoue, asking to tell us all the scenes present that are compatible with that tile and that date -> STAC doesn't find any scene

Do you have an explaination for this apparent inconsistency? And any suggestion on how to operate?

For reproducibility, here an example of tile-date combination that: has scenes in s3://sentinel-cogs/sentinel-s2-l2a-cogs/, has been notified to us by cirrus-v0-publish time ago, now we don't find in https://earth-search.aws.element84.com/v1.

S3 ls

aws s3 ls s3://sentinel-cogs/sentinel-s2-l2a-cogs/32/T/LP/2025/9/S2A_32TLP_20250917_1_L2A/ --no-sign-request

STAC interrogation

curl -s -X POST https://earth-search.aws.element84.com/v1/search \
  -H "Content-Type: application/json" \
  -d '{
    "collections": ["sentinel-2-l2a"],
    "query": {
      "mgrs:utm_zone": {"eq": 32},
      "mgrs:latitude_band": {"eq": "T"},
      "mgrs:grid_square": {"eq": "LP"}
    },
    "datetime": "2025-09-17T00:00:00Z/2025-09-17T23:59:59Z"
  }' | jq -r '.features[].id'

Thanks again.
Giovanni