diff --git a/docs/03-scanner.md b/docs/03-scanner.md
index 9eea638..1b79400 100644
--- a/docs/03-scanner.md
+++ b/docs/03-scanner.md
@@ -63,9 +63,14 @@ flowchart TD
     S --> F{"Intervall seit<br/>letztem Lauf um?"}
     F -->|nein| STOP5["nichts tun"]
     F -->|ja| G["Pipeline starten"]
-    G --> W["last_scan_at schreiben"]
+    G --> W["last_scan_at = Beginn des Laufs"]
 ```
 
+Geschrieben wird der **Beginn** des Laufs, nicht sein Ende. Das Intervall ist ein
+Takt: mit dem Endzeitpunkt kam die Laufzeit von drei bis vier Minuten jedes Mal
+obendrauf, aus 15 Minuten wurden 19 - rund ein Fuenftel weniger Durchgaenge pro
+Tag, und die Trefferliste der Boersen zeigt nur die neuesten Projekte.
+
 Die **Sperrfrist** ist die Antwort auf ein konkretes Problem: beide Instanzen
 benutzen dieselben Portal-Cookies. Beim ersten Start ziehen sonst beide
 gleichzeitig los, was Rate-Limits und CAPTCHAs provoziert - und zwei Chromium
diff --git a/docs/09-quellcode.md b/docs/09-quellcode.md
index d0a9f5b..a171e3e 100644
--- a/docs/09-quellcode.md
+++ b/docs/09-quellcode.md
@@ -168,8 +168,10 @@ Zusagen, auf die sich der Rest verlässt:
 
 * `runMatchingPipeline()` läuft **nie zweimal gleichzeitig** und gibt `false`
   zurück, wenn schon einer läuft. `isPipelineRunning()` fragt den Zustand ab.
-* Der Zeitpunkt landet im `finally` in `settings.last_scan_at` - auch nach einem
-  Abbruch, damit sich ein gescheiterter Lauf nicht sofort wiederholt.
+* Der **Beginn** des Laufs landet im `finally` in `settings.last_scan_at` - im
+  `finally`, damit sich ein gescheiterter Lauf nicht sofort wiederholt, aber mit
+  dem Startzeitpunkt, weil das Intervall ein Takt ist und keine Pause zwischen
+  zwei Läufen. Mit dem Endzeitpunkt wurden aus 15 Minuten 19.
 * `cleanup.js` benutzt `sequelize.col('created_at')` statt des Attributnamens:
   `Project` benennt die Spalte um, und in `where` greift die Zuordnung nicht.
 
diff --git a/server/src/scanner/services/pipeline.js b/server/src/scanner/services/pipeline.js
index 949e956..f008f2b 100644
--- a/server/src/scanner/services/pipeline.js
+++ b/server/src/scanner/services/pipeline.js
@@ -93,6 +93,16 @@ export const runMatchingPipeline = async () => {
     return false;
   }
   pipelineRunning = true;
+
+  /*
+   * Der BEGINN des Laufs, nicht sein Ende. Das Suchintervall ist ein Takt und
+   * keine Pause: mit dem Endzeitpunkt kam die Laufzeit von drei bis vier Minuten
+   * jedes Mal obendrauf, aus 15 Minuten wurden 19 und damit rund ein Fuenftel
+   * weniger Durchgaenge pro Tag. Bei einer Trefferliste, die nur die neuesten
+   * Projekte zeigt, kostet jeder ausgelassene Durchgang echte Funde.
+   */
+  const startedAt = new Date().toISOString();
+
   try {
     return await executePipeline();
   } finally {
@@ -103,9 +113,10 @@ export const runMatchingPipeline = async () => {
      * Scan zaehlt: er hat die Boersen ja gerade abgefragt.
      *
      * Im finally, also auch nach einem Abbruch: ein gescheiterter Lauf soll sich
-     * nicht sofort wiederholen.
+     * nicht sofort wiederholen. Dauert ein Lauf laenger als das Intervall, ist
+     * der naechste sofort faellig - die Sperre oben verhindert die Ueberlappung.
      */
-    await Setting.setVal('last_scan_at', new Date().toISOString()).catch(() => {});
+    await Setting.setVal('last_scan_at', startedAt).catch(() => {});
   }
 };