summary refs log tree commit diff
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/message_retention_policies.md2
-rw-r--r--docs/structured_logging.md2
-rw-r--r--docs/workers.md2
3 files changed, 3 insertions, 3 deletions
diff --git a/docs/message_retention_policies.md b/docs/message_retention_policies.md
index 9214d6d7e9..b52c4aaa24 100644
--- a/docs/message_retention_policies.md
+++ b/docs/message_retention_policies.md
@@ -117,7 +117,7 @@ In this example, we define three jobs:
 Note that this example is tailored to show different configurations and
 features slightly more jobs than it's probably necessary (in practice, a
 server admin would probably consider it better to replace the two last
-jobs with one that runs once a day and handles rooms which which
+jobs with one that runs once a day and handles rooms which
 policy's `max_lifetime` is greater than 3 days).
 
 Keep in mind, when configuring these jobs, that a purge job can become
diff --git a/docs/structured_logging.md b/docs/structured_logging.md
index a6667e1a11..d43dc9eb6e 100644
--- a/docs/structured_logging.md
+++ b/docs/structured_logging.md
@@ -43,7 +43,7 @@ loggers:
 The above logging config will set Synapse as 'INFO' logging level by default,
 with the SQL layer at 'WARNING', and will log to a file, stored as JSON.
 
-It is also possible to figure Synapse to log to a remote endpoint by using the
+It is also possible to configure Synapse to log to a remote endpoint by using the
 `synapse.logging.RemoteHandler` class included with Synapse. It takes the
 following arguments:
 
diff --git a/docs/workers.md b/docs/workers.md
index 779069b817..5033722098 100644
--- a/docs/workers.md
+++ b/docs/workers.md
@@ -1,6 +1,6 @@
 # Scaling synapse via workers
 
-For small instances it recommended to run Synapse in the default monolith mode.
+For small instances it is recommended to run Synapse in the default monolith mode.
 For larger instances where performance is a concern it can be helpful to split
 out functionality into multiple separate python processes. These processes are
 called 'workers', and are (eventually) intended to scale horizontally