diff --git a/docs/sources/clients/promtail/stages/drop.md b/docs/sources/clients/promtail/stages/drop.md
index 1137714209394..2592f05518815 100644
--- a/docs/sources/clients/promtail/stages/drop.md
+++ b/docs/sources/clients/promtail/stages/drop.md
@@ -106,7 +106,7 @@ Would drop this log line:
 
 #### Drop old log lines
 
-**NOTE** For `older_than` to work, you must be using the [timestamp](timestamp.md) stage to set the timestamp from the ingested log line _before_ applying the `drop` stage.
+**NOTE** For `older_than` to work, you must be using the [timestamp](../timestamp) stage to set the timestamp from the ingested log line _before_ applying the `drop` stage.
 
 Given the pipeline:
 
diff --git a/docs/sources/storage/_index.md b/docs/sources/storage/_index.md
index d4f9a9d54ee26..d0760d5f74784 100644
--- a/docs/sources/storage/_index.md
+++ b/docs/sources/storage/_index.md
@@ -138,7 +138,7 @@ Note, there are a few other DynamoDB provisioning options including DynamoDB aut
 
 When a new schema is released and you want to gain the advantages it provides, you can! Loki can transparently query & merge data from across schema boundaries so there is no disruption of service and upgrading is easy.
 
-First, you'll want to create a new [period_config](../configuration#period_config) entry in your [schema_config](../configuration.md#schema_config). The important thing to remember here is to set this at some point in the _future_ and then roll out the config file changes to Loki. This allows the table manager to create the required table in advance of writes and ensures that existing data isn't queried as if it adheres to the new schema.
+First, you'll want to create a new [period_config](../configuration#period_config) entry in your [schema_config](../configuration#schema_config). The important thing to remember here is to set this at some point in the _future_ and then roll out the config file changes to Loki. This allows the table manager to create the required table in advance of writes and ensures that existing data isn't queried as if it adheres to the new schema.
 
 As an example, let's say it's 2020-07-14 and we want to start using the `v11` schema on the 20th:
 ```yaml