Schedule an outcome
Hermes documents scheduled jobs, gateway-driven execution, run history and delivery behavior. Those mechanisms tell you how work is launched and recorded. Our recommended operating contract adds a separate definition of what the reader should actually receive: a dated file, a source-linked summary or a verified change notice.
Before enabling recurrence, complete one manual run with the intended profile and destination. Define what counts as fresh, how much missing source coverage is acceptable, and what to do when nothing changed. A quiet no-change run and an inaccessible-source run should leave distinguishable records, even if neither produces a notification.
Keep a small run receipt
Save the job identity, scheduled time with timezone, start and finish times, input window, output location and delivery result. Use a stable task identifier when maintaining a job so a repair does not create duplicate schedules. Keep the most recent valid artifact available while a failed attempt is investigated.
Test failure deliberately with a harmless unavailable input before relying on an important routine. The result should name the unavailable source and preserve previous output rather than present yesterday's material as new. Bound retries and specify when a failure becomes actionable for a person. Monitoring should make exceptions visible without generating routine noise.
Scope and limits
Current scheduler diagnostics include hermes cron status and hermes cron list. Their exact output depends on the installed release and scheduler arrangement. A healthy timer is useful evidence of scheduling infrastructure, not proof of an accurate report or a delivered message. This library has not verified an unattended run on your host merely by describing the documented mechanism.
Primary sources
Spotted something wrong or out of date? Tell us on X at @HermesWatcher (opens in a new tab) and we will fix it.
New Hermes Agent updates every day on X. Follow @HermesWatcher