ILLUSTRATIVE REPORT · NOT CUSTOMER DATA
Evidence a client can understand without reading cron logs.
This sample shows how CronClaw separates a successful HTTP request from a verified business result. Every number below is fictional and demonstrates the report format only.
ACME COMMERCE · 30-DAY SAMPLE
Inventory sync outcome assurance
Hourly catalog synchronization from the store system to the warehouse platform.
28
Required value and freshness passed1
HTTP 200 rejected by outcome proof18 min
From failed evidence to verified result0
No unresolved event in this samplePROOF CONTRACT
What “completed” means for this workflow
Business valuedata.status = completed
Freshnessdata.completed_at ≤ 90 minutes old
Evidence source
Separate read-only verification endpoint
RECENT OUTCOME EVIDENCE
| Observed UTC | Transport | Business result | Decision |
|---|---|---|---|
| Sep 10, 09:00 | HTTP 200 | status=completed, fresh | Verified |
| Sep 10, 08:00 | HTTP 200 | completed_at was stale | False-green caught |
| Sep 10, 08:18 | HTTP 200 | status=completed, fresh | Recovered |
What this report proves—and what it does not
It records
The response CronClaw observed, whether the configured proof rule passed, when a false-green response occurred, and when recovery was observed.
It does not certify
Financial accuracy, backup restorability, or source-system truth unless the verifier explicitly performs those checks. Signed evidence is tamper-evident operational history, not an external audit.
Replace the illustrative evidence with one real client workflow.
The founding pilot includes setup, a controlled failure rehearsal, alert routing, and a 30-day report.