## How to interpret timestamps URL: https://docs.atlan.com/product/capabilities/discovery/concepts/how-to-interpret-timestamps > Learn about how to interpret timestamps. Atlan displays timestamps for assets in local timezones based on the location of your browser. The date and time display includes a combination of the following components: - Relative time - for example, _2 hours ago_, _1 day ago_, _3 months ago_ - Absolute time - for example, _Mar 14, 2024, 9:40:01 AM_ Atlan displays the following timestamps in the asset sidebar: ## Overview tab - **Usage** - timestamp for the number of read queries on an asset at [source](https://docs.atlan.com/llms/catalog/connector-capabilities/supported-sources/llms.txt) within a specific date range, as fetched from the miner run. This also includes an absolute time value for _Last usage data updated (in Atlan)_. Only applicable to data sources for which Atlan supports mining query history. - **Last queried** - timestamp for the latest read query on an asset at [source](https://docs.atlan.com/llms/catalog/connector-capabilities/supported-sources/llms.txt) as fetched from the miner run or in Atlan within a specific date range. Only applicable to data sources for which Atlan supports mining query history. - **dbt run status** - status and timestamp for the last run of the dbt job updating an asset in dbt, as fetched from a [dbt crawler](https://docs.atlan.com/llms/connectors/dbt/crawl-dbt/llms.txt) run. ## Usage tab - **Row update frequency** - timestamps for recent row updates on an asset at [source](https://docs.atlan.com/llms/catalog/connector-capabilities/supported-sources/llms.txt) within a specific date range, as fetched from the miner run. Only applicable to data sources for which Atlan supports mining query history. Up to five recent row updates will be displayed, if available. ## Properties tab - **Last updated (in Atlan)** - timestamp for when any metadata attribute of the asset was last updated in Atlan. For example, when you [linked a term](https://docs.atlan.com/llms/governance/glossary/link-terms-to-assets/llms.txt) or [added a certificate](https://docs.atlan.com/llms/catalog/discovery/add-certificates/llms.txt) to an asset in Atlan. - **Last synced with source**  - timestamp for when a workflow run last checked for this asset at [source](https://docs.atlan.com/llms/catalog/connector-capabilities/supported-sources/llms.txt). This timestamp also includes a link to the connection workflow. - **Created (in Atlan)** - timestamp for when this asset was first created and published in Atlan during a crawler run. If the asset was previously archived and then reactivated (because the table was recreated at source), this timestamp reflects the original creation date, not the reactivation date. This is expected behavior. - **Last updated (on source)** - timestamp for when any metadata for the asset was last altered at [source](https://docs.atlan.com/llms/catalog/connector-capabilities/supported-sources/llms.txt), as fetched from the crawler run. - **Created at (on source)** - timestamp for when the asset was first created at [source](https://docs.atlan.com/llms/catalog/connector-capabilities/supported-sources/llms.txt), as fetched from the crawler run. ## Frequently asked questions #### Why are metrics missing after miner runs? If you notice a time lag from when your miner workflows last ran, note that Atlan requires a minimum lag of 24 to 48 hours to capture all the relevant transformations that were part of a session. (Read more about miner logic [here](https://docs.atlan.com/llms/catalog/lineage/troubleshooting-lineage/llms.txt).) This may also depend on when your miner workflow was scheduled to run, which you can [modify](https://docs.atlan.com/llms/catalog/connector-capabilities/manage-connectivity/llms.txt) at any time. #### Why do some timestamps have variable time ranges? Miners have a configurable property that governs the window of time for which metrics are reported. If a miner has been failing consistently, Atlan may reduce this window from 30 to only 14 days for reporting metrics. This is applicable to all date and time properties populated by miners. #### Is last updated in Atlan the same as last synced with source? No, _Last updated (in Atlan)_ records the time when any metadata is updated on the asset in Atlan while _Last synced with source_ records the time when a workflow ran successfully updating the asset with changes from source, if any. If no metadata updates were made on the asset in Atlan before the next scheduled workflow run, _Last synced with source_ may be considered as the more current timestamp reflecting any or no changes on the asset as fetched from source. #### Why are there discrepancies in time for some miner-related timestamps? For timestamps related to miner runs: - If no one has queried the asset at source, the timestamp for _Last queried_ may be older than the date range recorded for _Usage_. - If no one has used the asset at source for the duration of time that query history was mined, _Row update frequency_ may not display any time value. - Even when a miner run fails, it partially publishes assets, resulting in inconsistencies. For example, the date range in the _Last queried_ tooltip may be for a successful miner run but the absolute time may be a different value if the asset had been partially published. ---