Noticed Cortex Query Timeout and Data Inconsistency Issues

Cortex returns inconsistent results for the same query.

Repeatedly executing the same query (or refreshing the dashboard) returns different data without any changes to the query parameters.

Ideally, the query should either:

Return the same data if no new data has been ingested, or

Return updated data only when new data is available.

Instead, the results intermittently alternate between older and newer data, indicating possible inconsistency in query execution or data availability.

Seeing gaps when we query for 1 hour and when same query for 3 hours shows data in the grafana

Cortex version used is 1.21.0 with regex matcher enabled.

@friedrichg

@friedrichg @yeya24 can you please take a look at it ?

@rmhaisane

@rmhaisane
Can you share a Cortex config?

@SungJin1212

Please find config below @SungJin1212

  cluster:
    listen_address: 0.0.0.0:9094
  enable_api: false
  external_url: /api/prom/alertmanager
  sharding_ring:
    kvstore:
      consul:
        host: 'customer-cortex-consul-server:8500'
      store: memberlist
alertmanager_storage:
  backend: s3
  gcs:
    bucket_name: ""
  s3:
    bucket_name: xxxx
    endpoint: xxxx
    region: uxxx
api:
  prometheus_http_prefix: /prometheus
  response_compression_enabled: true
auth_enabled: true
blocks_storage:
  backend: s3
  bucket_store:
    bucket_index:
      enabled: true
      max_stale_period: 2h
    chunks_cache:
      backend: memcached
      max_get_range_requests: 6
      memcached:
        addresses: xxxxxx
        max_async_buffer_size: 17000
        max_async_concurrency: 100
        max_get_multi_batch_size: 500
        max_get_multi_concurrency: 150
        max_idle_connections: 300
        max_item_size: 10485760
        timeout: 5s
    ignore_deletion_mark_delay: 2h
    index_cache:
      backend: memcached
      memcached:
        addresses: xxxxxx
        max_async_buffer_size: 17000
        max_async_concurrency: 100
        max_get_multi_batch_size: 500
        max_get_multi_concurrency: 150
        max_idle_connections: 300
        max_item_size: 10485760
        timeout: 5s
    index_header_lazy_loading_enabled: true
    index_header_lazy_loading_idle_timeout: 60m
    lazy_expanded_posting_group_max_key_series_ratio: 50
    lazy_expanded_postings_enabled: true
    matchers_cache_max_items: 10000
    max_chunk_pool_bytes: 6442450944
    metadata_cache:
      backend: memcached
      bucket_index_content_ttl: 30m
      memcached:
        addresses: xxxxxxxx
        max_async_buffer_size: 10000
        max_async_concurrency: 50
        max_get_multi_batch_size: 500
        max_get_multi_concurrency: 100
        max_idle_connections: 100
        max_item_size: 5242880
        timeout: 2s
      metafile_content_ttl: 48h
      metafile_doesnt_exist_ttl: 30m
      metafile_exists_ttl: 6h
      tenant_blocks_list_ttl: 1h
      tenants_list_ttl: 30m
    partitioner_max_gap_bytes: 1048576
    series_batch_size: 15000
    sync_dir: /data
  gcs:
    bucket_name: ""
  s3:
    bucket_name: xxxx
    endpoint: xxxx
    region: us-east-1
  tsdb:
    dir: /data
    head_chunks_write_buffer_size_bytes: 131072
    stripe_size: 1024
    wal_compression_type: snappy
  users_scanner:
    cache_ttl: 15m
    max_stale_period: 1h
    strategy: user_index
    update_interval: 15m
compactor:
  block_deletion_marks_migration_enabled: false
  sharding_enabled: true
  sharding_ring:
    kvstore:
      consul:
        host: 'customer-cortex-consul-server:8500'
      store: memberlist
distributor:
  ha_tracker:
    kvstore:
      consul:
        host: 'customer-cortex-consul-server:8500'
      store: consul
  pool:
    health_check_ingesters: true
  ring:
    kvstore:
      consul:
        host: 'customer-cortex-consul-server:8500'
      store: memberlist
  shard_by_all_labels: true
  sharding_strategy: shuffle-sharding
frontend:
  log_queries_longer_than: 10s
  scheduler_address: xxxx
frontend_worker:
  match_max_concurrent: true
  scheduler_address: xxxxx
ingester:
  lifecycler:
    final_sleep: 30s
    join_after: 10s
    observe_period: 10s
    ring:
      kvstore:
        consul:
          host: 'customer-cortex-consul-server:8500'
        store: memberlist
      replication_factor: 3
ingester_client:
  grpc_client_config:
    grpc_compression: snappy-block
    max_recv_msg_size: 26214400
    max_send_msg_size: 26214400
limits:
  compactor_blocks_retention_period: 185d
  enforce_metric_name: true
  ingestion_tenant_shard_size: 4
  max_cache_freshness: 10m
  max_fetched_chunks_per_query: 10000000
  max_label_names_per_series: 50
  max_query_lookback: 0s
  reject_old_samples: true
  reject_old_samples_max_age: 168h
  ruler_evaluation_delay_duration: 20m
  ruler_query_offset: 20m
  store_gateway_tenant_shard_size: 3
memberlist:
  bind_port: 7946
  join_members:
  - 'customer-cortex-memberlist'
querier:
  active_query_tracker_dir: /data/active-query-tracker
  default_evaluation_interval: 30s
  max_concurrent: 50
  max_samples: 60000000
  query_ingesters_within: 5h50m
  query_store_after: 5h45m
  shuffle_sharding_ingesters_lookback_period: 6h
  store_gateway_addresses: |-
    
  timeout: 6m
query_range:
  align_queries_with_step: true
  cache_results: true
  results_cache:
    cache:
      memcached:
        expiration: 6h
      memcached_client:
        addresses: xxxxxxx
        max_idle_conns: 200
        max_item_size: 10485760
        timeout: 5s
  split_queries_by_interval: 24h
ruler:
  enable_alertmanager_discovery: false
  enable_api: true
  enable_sharding: true
  ring:
    kvstore:
      consul:
        host: 'customer-cortex-consul-server:8500'
      store: memberlist
ruler_storage:
  backend: s3
  gcs:
    bucket_name: ""
  s3:
    bucket_name: xxxx
    endpoint: xxx
    region: us-east-1
runtime_config:
  file: /etc/cortex-runtime-config/runtime_config.yaml
server:
  grpc_listen_port: 9095
  grpc_server_max_concurrent_streams: 10000
  grpc_server_max_recv_msg_size: 52428800
  grpc_server_max_send_msg_size: 52428800
  http_listen_port: 8080
storage:
  engine: blocks
store_gateway:
  sharding_enabled: true
  sharding_ring:
    kvstore:
      consul:
        host: 'customer-cortex-consul-server:8500'
      store: memberlist
  sharding_strategy: shuffle-sharding
tenant_federation:
  enabled: true
  max_concurrent: 128
  regex_matcher_enabled: true```

@rmhaisane

@rmhaisane
I think your result cache is poisoned in the last 1h query.
To confirm this is the cause, try disabling the result cache temporarily:

query_range:
  cache_results: false

@SungJin1212

@SungJin1212 But if I disable this cache will it increase the load on the other components like store gateway and ingestor etc..?

Also is there any issue with this cache results getting poisoned and can we have a fix for this?

I had reduced it to 10min TTL after which data is only showing inconsistency for smaller time earlier it used to show for 6hr

@rmhaisane

@rmhaisane

But if I disable this cache will it increase the load on the other components like store gateway and ingestor etc..?

Right, disabling the cache entirely (cache_results: false) will increase load on ingesters/store-gateway. It is just a temporary action to confirm the cause.

Interesting... with RF=3, it's unlikely that all 3 ingesters simultaneously returned empty data for the same range.
Are there any suspicious logs or repeating patterns around the time the gap first appeared?

@SungJin1212

@SungJin1212 No actually Its happening intermittently...Actually sometime it loads sometime it won't.

Are we having any fix for the cache thing if we want to enable that ?? Is it fixed in later version ?

@SungJin1212

@SungJin1212 Any update on this issue as this is blocking our upgrade?

@rmhaisane

Thanks SungJin1212 for digging into the result-cache angle, that lines up with what I found.

Likely root cause: your config has tenant_federation.enabled: true and tenant_federation.regex_matcher_enabled: true. Under that setting, the query-frontend's results cache key was built from the raw X-Scope-OrgID header value (e.g. a regex), not from the actual set of tenant IDs that regex resolves to. If the resolved tenant set changes, the cache key stays the same, so the frontend keeps serving a stale cached extent until it expires. Your query_range.results_cache.cache.memcached.expiration: 6h matches the "sometimes 10 minutes, sometimes longer" pattern you described.

The resolved tenant set can change for two reasons:

A tenant is genuinely added or removed.
The regex resolver's user-discovery scan fails transiently (e.g. a slow/failed bucket list call) and clears its known-user list, then repopulates it on the next successful scan. This does not require any real tenant change on your side, and better explains "sometimes it loads, sometimes it won't."

Fixes on master, not yet released (not in v1.21.0 or v1.21.1):

include resolved tenant fingerprint in result cache keys to prevent stale data after tenant changes #7562: hashes the resolved tenant set into the results-cache key, so a tenant-set change invalidates the cache instead of serving stale data
Add continue on error when user discovery fail in regex resolver #7534: stops the regex resolver from clearing its known-user list on a failed scan
update regex resolve cache only if known user changed #7489: only purges the resolver's internal cache when the known-user set actually changed

To help confirm this is your issue: do you see cortex_regex_resolver_last_update_run_timestamp_seconds failing to advance, or any errors/warnings from the regex resolver, around the times the gaps appear? That would confirm trigger #2 above.

@rmhaisane do you think you could run cortex with this image to confirm the bug you have is fixed

❯ docker run cortexproject/cortex:master-e5eadb1 -version                                                                                                                                                                                           
  2026/08/07 19:02:09 maxprocs: Leaving GOMAXPROCS=8: CPU quota undefined                                                                                                                                                                           
  Cortex, version 1.21.0 (branch: master, revision: e5eadb1)                                                                                                                                                                                        
    build user:                                                                                                                                                                                                                                     
    build date:                                                                                                                                                                                                                                     
    go version:       go1.26.2                                                                                                                                                                                                                      
    platform:         linux/arm64                                                                                                                                                                                                                   
    tags:             netgo,slicelabels

@friedrichg

@friedrichg I will try to run this with master image version but then its not feasible for me to push that to prod unless we have the proper release of cortex. Could you please help me with the release which is stable which I can use for upgrading the prod with regex enabled as i have usecases which needs regex ?

I could try this on lower clusters for time being.

@rmhaisane

@rmhaisane
Can you try quay.io/cortexproject/cortex:master-e450d52?
I'm using it in my cluster and haven't yet found any issues.

@friedrichg

@friedrichg @SungJin1212 Do we have any timeline for this release ?

@CharlieTLe

@CharlieTLe Do we have any date by when we should be releasing the cortex 1.22.0 version ?

@friedrichg

@friedrichg @CharlieTLe Any ETA for the new release ?

@rmhaisane

Any ETA for the new release ?

@rmhaisane I can't speak to the final release date, but the three fixes listed above (#7562, #7534 and #7489) are already in the 1.22.0 release candidates, the latest being v1.22.0-rc.3 from 2026-10-06 (https://github.com/cortexproject/cortex/releases/tag/v1.22.0-rc.3, image quay.io/cortexproject/cortex:v1.22.0-rc.3). So you can validate the fix on a tagged build instead of a master image while the final 1.22.0 is being prepared.

Navigation Menu

Repository navigation

Noticed Cortex Query Timeout and Data Inconsistency Issues #7733

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Noticed Cortex Query Timeout and Data Inconsistency Issues #7733

Description

Activity

rmhaisane commented on Jul 27, 2026

SungJin1212 commented on Jul 29, 2026

rmhaisane commented on Jul 30, 2026

SungJin1212 commented on Jul 30, 2026

rmhaisane commented on Jul 31, 2026

SungJin1212 commented on Jul 31, 2026

rmhaisane commented on Aug 3, 2026

rmhaisane commented on Aug 6, 2026

friedrichg commented on Aug 7, 2026

rmhaisane commented on Aug 10, 2026

SungJin1212 commented on Aug 11, 2026

rmhaisane commented on Aug 20, 2026

rmhaisane commented on Oct 13, 2026

rmhaisane commented on Oct 27, 2026

sandy2008 commented on Oct 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions