Your scheduler
Starts the job, sets its time zone, prevents overlap, and reports failures.
RECURRING REPORTS / ONE PLACE TO CHECK
Your weekly report.
Always at the same link.
New week. New information. No “which attachment is the latest?”
Your scheduled agent prepares the report. share/artifacts publishes the approved HTML at a URL you can keep using. Readers see the latest successful update when they open or refresh the page.
Bring your own scheduler. share/artifacts does not schedule jobs or automatically refresh source data.
A REPEATABLE HANDOFF
- WEEK 01Publish the first report.Save its page ID and URL.
- WEEK 02Update the same page.Replace last week’s snapshot.
- WEEK 03Keep the link in circulation.Verify the latest successful update.
THE SHORT ANSWER
How do you automate a recurring HTML report?
Use your agent’s scheduler to gather approved information and create a static HTML report. Publish it once through share/artifacts, save the returned page ID, and update that page on later runs. Set the audience deliberately, keep credentials in private configuration, and verify each update. Scheduling, source access, and failure notifications belong to your agent or scheduler.
01 / WHO DOES WHAT
Three jobs. No mystery about who runs them.
Your agent
Uses permitted sources, checks the snapshot, and writes the complete report.
share/artifacts
Sanitizes and hosts the submitted HTML, keeps its URL, and applies page access settings.
This guide describes a workflow you configure. It does not turn on a schedule or grant an agent access to your accounts.
02 / START WITH A REPORT WORTH REPEATING
Keep the structure.
Refresh the evidence.
A useful weekly update answers the same questions each time: what changed, what is at risk, and what needs a decision. Give every snapshot a reporting period so an old report cannot masquerade as a current one.
Open the complete weekly report example ↗The example includes fictional source notes and the finished HTML report.
WHAT EACH SNAPSHOT SHOULD SAY
- Reporting period
- Which week does this cover?
- Source cutoff
- How recent is the information?
- Changes and decisions
- What should the reader do next?
- Missing information
- What could not be checked?
03 / PUBLISH ONCE. UPDATE AFTER THAT.
Set up a reliable weekly rhythm.
Decide what the recurring job may do
Choose the audience, approved sources, reporting period, schedule and time zone. Decide whether each draft needs your review or whether you authorize unattended updates within clear limits. Missing sources, unusual results, and audience changes should stop for review.
Connect the agent that will run the job
Set up a compatible background agent with a personal access token. Use the background-agent setup page and store the token in private configuration on the machine running the job. The job needs page read and write permissions; saved styles need their own permissions.
Publish and check the first report
Create a complete HTML report from the approved sources. Review the facts and layout, approve publishing, and choose access. New pages are owner-only unless you choose otherwise. Save the returned page ID and share URL in the job’s private configuration, then test the recipient experience.
Update that page on later runs
On each scheduled run, collect the new approved snapshot and create the complete replacement HTML. Include the reporting period and source cutoff. Ask the agent to update the saved page ID—not publish a new page. Run only one update at a time and keep the existing audience unless you approve a change.
Verify the result and handle failures
Ask the agent to confirm the update succeeded, then open the same URL to review the new report. If an update result is uncertain, check whether the new content was saved before retrying. If a run fails before updating, keep the last good report and have your scheduler notify you.
04 / MAKE FAILURES OBVIOUS
Do not let an old report look like a new one.
- A source is unavailable
- Do not invent fresh numbers or silently reuse old ones. Stop for review, or publish an explicitly incomplete snapshot only if your approved workflow allows it.
- The publishing result is uncertain
- Ask the agent to check whether the new content was saved before retrying. If the first publish was uncertain, check recent pages first to avoid creating a duplicate.
- Two runs overlap
- Configure one run per page at a time. Discard stale snapshots before writing; an older run can otherwise overwrite a newer result.
- The reader cannot open it
- Check the page’s audience, expiration, and published status. Updating the HTML does not change access, extend expiration, or bring an unpublished page back online.
Every successful update uses publishing allowance. Check your plan limits before choosing a schedule. For an existing tab, readers may need to refresh; this is not a live dashboard.
05 / KNOW HOW TO STOP
Stop the job. Control the link separately.
To stop future runs
Pause the schedule in the system that runs your agent. Revoke its personal token if it should no longer access share/artifacts. Tokens are credentials, not passwords for your readers: never paste them into chats, prompts, URLs, HTML, or a repository.
To stop people reading
Change page access to Only me, set an expiration, or unpublish it. Revoking an agent token does not remove recipient access. Choose the right private-sharing settings.
ONE LESS REPEATED HANDOFF
Give your report one place to land.
Start with one reviewed report and one scheduled job. Keep the source checks and audience explicit as you repeat it.