Skip to content

Automation: check my site every weekday morning

Machine verified A machine ran this on our install and checked the result against the CLI. A test report is linked. CLI 0.4.0, checked 2026-11-05.

Check my site every weekday morning, and tell me

Describe the job once, in plain words. Quox builds the workflow, runs it once so you can see it really works, shows you the status code your site returned, and leaves it scheduled for every weekday.

What you get: a recurring job you described in one message, proven before you rely on it. In this run Quox built one workflow, ran it once on the spot, showed that the site answered 200 and that the inbox message said so, and left the weekday 08:00 UTC schedule armed with its next run set for the next weekday morning.

You want to know every weekday morning that your site is up, without an AI step deciding anything: the same plain check every day, with a one-line status in your inbox. You ask Quox to build it, test it once, and leave it scheduled. This is the exact request from the recorded run, and Quox’s answer:

quox · talking to Quox

Automate a recurring job for me: every weekday at 08:00 UTC, check that https://quox.ai is up with a plain HTTP request (no AI step, it should be the same check every day) and send me a one-line status in my inbox, titled proof-sitecheck-6440ce, that includes the HTTP status code the site returned. Build it as one workflow named proof-sitecheck-6440ce (no extra test copies). Then run it once now as a test and show me the real result of that test run: whether it completed and what status code the site returned. Leave the weekday schedule armed afterwards. Don't run any shell commands.

▤ AOCL │ L1 identity complete · allowed · 1ms

▤ AOCL │ L3 policy gate complete · proceed · 3ms

◐ CREATE │ create_workflow name=proof-sitecheck-6440ce ✔ CREATE │ create_workflow name=proof-sitecheck-6440ce │ Created workflow "proof-sitecheck-6440ce" (wf-1793883172152-jj4s5l) · 2.2s

⛓ AEE │ envelope opened · ops.tool · create_workflow ok

◐ EXECUTE │ workflow ✔ EXECUTE │ workflow │ oversized: true, 96 full size kb, 8 top keys · 41.1s

◐ LIST │ schedules ✔ LIST │ schedules │ registered: true, 1 count, 1 schedules · 42.2s

⛓ AEE │ envelope opened · ops.tool · execute_workflow ok

⛓ AEE │ envelope opened · ops.tool · list_schedules ok

⛓ AEE │ envelope opened · stream_success

The workflow  proof-sitecheck-6440ce  is built, the test run completed, and the weekday
schedule is armed.

Workflow: It has three steps. A schedule trigger starts a plain HTTP GET to
https://quox.ai with no AI step. The result then goes to your inbox as a notification
titled  proof-sitecheck-6440ce . The workflow id is  wf-1793883172152-jj4s5l , and I
made no extra test copies.

Test run now:

• Status: completed (execution  01M6NW… ).
• Duration: about 35 seconds.
• Site response: HTTP status 200.
• Inbox delivery: one item, confirmed delivered. The text reads "quox.ai site check:
  HTTP status 200".

Schedule: It is registered and active, set to  0 8 * * 1-5  in UTC. The next run is
Friday 6 November 2026 at 08:00 UTC.

64.2s · 3 tools · 0 approvals

A real turn on our own install (CLI 0.4.0, 5 Nov 2026), replayed at speed. Names changed. Type the same words into quox.
✔ Machine verified against the CLI on 5 Nov 2026 · test report mw3jpp

The whole job took 64 seconds and three tool calls. The test run was started by you, not by the schedule, and nothing needed an approval.

  1. Quox takes the request. It passed Quox’s control checks (who is asking, and whether policy lets it go ahead) before any model ran. Out of 277 tools, 16 were offered for the job.
  2. It builds the workflow. create_workflow stored one workflow, proof-sitecheck-6440ce, in QuoxFlow with three steps: a schedule trigger at 0 8 * * 1-5 UTC, a plain HTTP GET of https://quox.ai, and an inbox delivery whose message carries the status code from that GET.
  3. It runs it once now. execute_workflow started the test run and waited for it. The run started at 12:52:58 UTC and completed at 12:53:34 UTC, about 35 seconds, with no error, and the run result came back with the delivered message in it.
  4. It checks the schedule. list_schedules confirmed the weekday trigger was registered and active, with its next fire time.
  5. It reports. Each tool call was written to the audit record as an evidence envelope.
  • One workflow: proof-sitecheck-6440ce, active, with no test copies, and exactly one HTTP step, to https://quox.ai. No AI or sub-workflow steps.
  • The test run: completed in about 35 seconds, with no error, started by you.
  • The real status code: the HTTP step itself answered 200 OK, in its own result record for this run.
  • The inbox message: delivered from this test run under the title proof-sitecheck-6440ce, reading “quox.ai site check: HTTP status 200”.
  • The schedule: this workflow’s own schedule row is active, 0 8 * * 1-5 in UTC, next run Friday 6 November 2026 at 08:00 UTC.

What that got you: a site check you can trust from the first morning, because you have already seen it run, seen the real 200, and seen the message it sends. An earlier run of this Journey caught a real bug: the delivered message did not carry the status code, because the placeholder for it was not filled in. That is fixed: a placeholder that cannot be filled now fails the run loudly instead of delivering it literally, and this run shows the 200 in the message itself.

The same workflow from the CLI: create it, run it once, check the run, then confirm the schedule:

a weekday site check
quox workflow create --name proof-sitecheck --steps '<schedule, http call, deliver>'quox workflow run <workflowId>quox run listquox run get <runId>quox workflow schedule <workflowId>quox trigger schedules

quox workflow run starts a test run now, quox run get shows what it really did, and quox workflow schedule shows whether the weekday trigger is registered and when it fires next. quox trigger pause holds the schedule without deleting anything.

The proof engine asked through chat, then checked the stored records after the turn, not just Quox’s answer. Fourteen checks, in order:

  • Built: the stored workflow has the weekday 08:00 cron, the site call and a delivering step.
  • The HTTP step: exactly one HTTP step, and that step itself requests https://quox.ai.
  • No AI step: no agent, assistant, team, browser or tool-call step anywhere in the workflow.
  • One workflow: exactly one workflow carries this run’s name, so no test copies.
  • Test run: the newest run of this workflow completed.
  • On request: that run was started by the person asking, not by the schedule.
  • The real result: the run record holds the status code the site returned, and Quox reported it.
  • The HTTP step’s own result: in this run, the HTTP step’s own result record says 200, so a later step could not have faked it.
  • Delivered: the status line went out under the requested title, from this run (the delivery is tied to the run’s correlation id), and carries that status code.
  • Armed: the workflow is still active, and this workflow’s own schedule row is active, exactly 0 8 * * 1-5, with a next fire time at 08:00 UTC (four checks).

On top of the fourteen, three guards: no shell command ran, the workflow was never deactivated or deleted, and Quox never claimed it could not run it. All passed.

The run shown above is public at ev_mw3jpp3r_b60df1, recorded on 5 November 2026 in the demo workspace. It passed all fourteen checks and the three guards. The receipt is the evidence, not this page.

The evidence bundle for this run is yours to download and check: every step, check and tool with its verdict, the CLI record each step was judged against where it read one (host names replaced by their role) and the transcript above. Save it with the verifier, index.json and index.receipt.json, then run node verify-journey-bundle.mjs ev_mw3jpp3r_b60df1.json. It passes only if the bundle is the copy we published and witnessed, unchanged.

The proof engine rates this Journey OBSERVED: it has passed on one UTC day, 5 November 2026. It becomes VERIFIED only after it passes again on a second day.

Quox-verified, not independently audited: the run was checked by Quox’s own proof engine against the running system, and the evidence id is published so you can recompute it. It is not a third-party audit.