refactor: some small changes before PR

docs/api/source/includes/_jobs.md

@@ -40,8 +40,8 @@ meaning manual requests can cause builds to be skipped.
 
 ```shell
 curl \
-  -H 'x-api-key: secret' \
-  'https://example.com/api/v1/jobs/poll?arch=x86_64&max=2'
+  -H 'X-Api-Key: secret' \
+  https://example.com/api/v1/jobs/poll?arch=x86_64&max=2
 ```
 
 > JSON output format

docs/content/configuration.md

@@ -59,7 +59,7 @@ configuration variable required for each command.
       ([GitHub](https://github.com/Menci/docker-archlinuxarm)). This is the
       image used for the Vieter CI builds.
 * `max_log_age`: maximum age of logs (in days). Logs older than this will get
-  cleaned by the log removal daemon . If set to a negative value, no logs are
+  cleaned by the log removal daemon. If set to a negative value, no logs are
   ever removed. The age of logs is determined by the time the build was
   started.
     * Default: `-1`

docs/content/usage/builds/cleanup.md

@@ -5,15 +5,15 @@ weight: 20
 # Cleanup
 
 Vieter stores the logs of every single package build. While this is great for
-debugging why builds fails, it also causes an active or long-running Vieter
+debugging why builds fail, it also causes an active or long-running Vieter
 instance to accumulate thousands of logs.
 
 To combat this, a log removal daemon can be enabled that periodically removes
 old build logs. By starting your server with the `max_log_age` variable (see
-[Configuration](/configuration#vieter-server) for more info), a daemon will
-get enabled that periodically removes logs older than this setting. By default,
-this will happen every day at midnight, but this behavior can be changed using
-the `log_removal_schedule` variable.
+[Configuration](/configuration#vieter-server)), a daemon will get enabled that
+periodically removes logs older than this setting. By default, this will happen
+every day at midnight, but this behavior can be changed using the
+`log_removal_schedule` variable.
 
 {{< hint info >}}
 **Note**  
@@ -21,4 +21,3 @@ The daemon will always run a removal of logs on startup. Therefore, it's
 possible the daemon will be *very* active when first enabling this setting.
 After the initial surge of logs to remove, it'll calm down again.
 {{< /hint >}}
-