title: Azure cosmosDB does not delete documents with expired TTL
body: <p>I have a collection in an Azure cosmosDB, where I enabled the Time To Live (TTL) feature with no defaults.</p>
  
  <p>As per the <a href="https://docs.microsoft.com/en-gb/azure/cosmos-db/time-to-live#ttl-and-index-interaction" rel="nofollow noreferrer">documentation</a>, which I will refer to in this question, everything seems crystal clear but there is still something I am missing, because after 5 days I still can see documents with a TTL of 300 seconds.</p>
  
  <p>Below the screenshot showing the collection settings, where the TTL is enabled with no default.
  <a href="https://i.stack.imgur.com/yCa1E.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/yCa1E.png" alt="enter image description here"></a></p>
  
  <p>According with the documentation:</p>
  
  <blockquote>
    <p>Azure Cosmos DB will automatically remove these items after the time period, since the time they were last modified. Time to live value is configured in seconds. When you configure TTL, the system will automatically delete the expired items based on the TTL value, without needing a delete operation that is explicitly issued by the client application.</p>
  </blockquote>
  
  <p>But this doesn't seem to apply in my case, where on the 17/07/2019 I can see a document oder than 5 days, using a TTL of 300 seconds (5 minutes).</p>
  
  <pre><code>{
      "ClientEnqueuedUtcTime": "2019-07-12T06:49:53.844",
      "ClientDispatchedUtcTime": "2019-07-12T06:49:53.844",
      "ServerEnqueuedUtcTime": "2019-07-12T06:49:53.8949771",
      "ServerDispatchedUtcTime": "2019-07-12T06:49:54.3659741",
      "TTL": 300,
      "EventProcessedUtcTime": "2019-07-12T06:49:55.3583521Z",
      "PartitionId": 2,
      "EventEnqueuedUtcTime": "2019-07-12T06:49:55.25Z",
      "id": "4a0edf24-6a86-4a59-f55d-d7dfe47c30fa",
      "_rid": "SBk4AJadUE6gAgEAAAAAAA==",
      "_self": "dbs/SBk4AA==/colls/SBk4AJadUE4=/docs/SBk4AJadUE6gAgEAAAAAAA==/",
      "_etag": "\"00008f1d-0000-0200-0000-5d282d930000\"",
      "_attachments": "attachments/",
      "_ts": 1562914195
  }
  </code></pre>
  
  <p><strong>UPDATE After the answer</strong></p>
  
  <p><s>I tried to salve the TTL in lower case format, but it was transformed uppercase automatically, so I don't think it is a case mismatch with the expected TTL key.</s></p>
  
  <p>Am I supposed to do or try anything else?</p>
  
  <p><strong>SOLUTION:</strong></p>
  
  <p><strong>ttl is indeed case sensitive</strong>, and you can set it lowercase, in the test I done for some reason the ttl was still uppercase, when I was expecting it to be lower, so I tough incorrectly that was some kind of reserved key.</p>