diff --git a/.github/workflows/website.yml b/.github/workflows/website.yml
index 410ee5e4..8371508c 100644
--- a/.github/workflows/website.yml
+++ b/.github/workflows/website.yml
@@ -23,4 +23,6 @@ jobs:
       - name: Build website (${{ env.DOCSPELL_VERSION }})
         run: nix-shell website/shell.nix --run "sbt make-website"
       - name: Publish website (${{ env.DOCSPELL_VERSION }})
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         run: sbt publish-website
diff --git a/Changelog.md b/Changelog.md
index 0e40338f..1f628076 100644
--- a/Changelog.md
+++ b/Changelog.md
@@ -73,6 +73,10 @@ state (the master branch). The `latest` tag points to the latest
 release. Each release is also tagged with its version number, like
 `v0.24.0`.
 
+The images changed slightly in that there is no assumption on where
+the config file is placed. Now you need to pass the docspell config
+file explicitely when using the images.
+
 Multiarch: Images are now build for `amd64`, `arm64` and `armv7`.
 
 The consumedir is being replaced by the more generic `docspell/tools`
@@ -92,7 +96,10 @@ The docker-compose setup is now at `docker/docker-compose`. Please
 look at the new [compose
 file](https://github.com/eikek/docspell/blob/master/docker/docker-compose/docker-compose.yml)
 and do the corresponding changes at yours. Especially the consumedir
-container changed significantly.
+container changed significantly. Then due to the fact that the config
+file must be given explicitely, you need to add this argument to each
+docspell component (restserver and joex) via a `command` section (see
+the compose file referenced above).
 
 The `.envrc` has been cleaned from some settings. Since the config
 files is mounted into the image, you can just edit this file instead.
@@ -924,7 +931,7 @@ improvements for processing files.
   upload the file into memory for nothing if something fails (e.g. the
   source doesn't exist)
 - Re-process files. A
-  [route](https://docspell.org/openapi/docspell-openapi.html#api-Item-secItemItemIdReprocessPost)
+  [route](https://docspell.org/openapi/docspell-openapi.html#operation/sec-item-start-reprocess)
   has been added that submits files for re-processing. It is possible
   to re-process some files of an item or all. There is no UI for this
   for now. You'd need to run `curl` or something manually to trigger
diff --git a/website/site/content/docs/faq/_index.md b/website/site/content/docs/faq/_index.md
index fa25bcc1..84ee520f 100644
--- a/website/site/content/docs/faq/_index.md
+++ b/website/site/content/docs/faq/_index.md
@@ -117,8 +117,7 @@ Please see this [issue](https://github.com/eikek/docspell/issues/358).
 ## Why another DMS?
 
 Back when Docspell started, there weren't as many options as there are
-now. I wanted to try out a different approach. You can read more about
-that [here](@/docs/intro/_index.md#rationale).
+now. I wanted to try out a different approach.
 
 ## Wh…?
 
diff --git a/website/site/content/docs/webapp/processing.md b/website/site/content/docs/webapp/processing.md
index e20ad5ba..06cf9740 100644
--- a/website/site/content/docs/webapp/processing.md
+++ b/website/site/content/docs/webapp/processing.md
@@ -7,13 +7,13 @@ mktoc = true
 
 
 The page *Processing Queue* shows the current state of document
-processing for your uploads.
+processing for your uploads. The page currently only shows at most the
+80 newest jobs. There is a maximum of 40 done jobs (successful,
+cancelled or failed) and 40 not done jobs.
 
-At the top of the page a list of running jobs is shown. Below that,
-the left column shows jobs that wait to be picked up by the job
-executor. On the right are finished jobs. The number of finished jobs
-is cut to some maximum and is also restricted by a date range. The
-page refreshes itself automatically to show the progress.
+The sidebar lets you filter for a specific job state. The *Currently
+Running* tab shows all jobs that are currently executing and their log
+output. The page refreshes automatically to show the progress.
 
 Example screenshot:
 
@@ -32,8 +32,9 @@ Since job executors are shared among all collectives, it may happen
 that a job is some time waiting until it is picked up by a job
 executor. You can always start more job executors to help out.
 
-If a job fails, it is retried after some time. Only if it fails too
-often (can be configured), it then is finished with *failed* state.
+If a job fails it first enters "stuck" state and is retried after some
+time. Only if it fails too often (can be configured), it then is
+finished with *failed* state.
 
 For the document-processing task, if processing finally fails or a job
 is cancelled, the item is still created, just without suggestions.