Run the canary's paid job weekly; free jobs stay daily

.github/workflows/canary.yml

@@ -23,7 +23,8 @@ name: canary
 #                            still fails. This job is NOT the data test.
 #
 #   production-like        — THE data test. Needs the FARFETCH_PROXY secret
-#                            (a residential exit) and is strict about
+#                            (a residential exit), so it bills, and runs
+#                            weekly (Mondays) and on dispatch only. Strict about
 #                            everything, a block included. When the secret is
 #                            absent the job FAILS with an error naming it:
 #                            a canary that never reaches the site must not
@@ -43,6 +44,9 @@ on:
     # Once a day, off the hour, so it isn't competing with everyone else's
     # on-the-hour cron jobs for runner availability.
     - cron: "17 6 * * *"
+    # Mondays only: the paid job (production-like) runs on this
+    # schedule (each run bills); the free jobs keep the daily one above.
+    - cron: "17 6 * * 1"
   workflow_dispatch:
 
 jobs:
@@ -125,6 +129,8 @@ jobs:
 
   production-like:
     name: production-like (residential proxy)
+    # Paid path: weekly schedule or a manual dispatch only.
+    if: github.event_name != 'schedule' || github.event.schedule == '17 6 * * 1'
     runs-on: ubuntu-latest
     # `secrets` is not available in a job-level `if`, so presence is tested
     # through the job env and read in each step's `if` — the same shape the

CHANGELOG.md

@@ -8,6 +8,12 @@ a promise that every flag and exit code is contractually frozen.
 
 ## [Unreleased]
 
+### Changed
+
+- CI only: the canary's paid `production-like` job now runs weekly (Mondays
+  06:17 UTC) and on a manual dispatch; the free `reachability-no-proxy` job still
+  runs daily.
+
 ## [0.6.0] — 2026-10-15
 
 > **Behaviour changes.** (1) The pyppeteer and Selenium engines now report an