agent's daily scheduled run failed to archive outputs, data missing

Not specified by the original author.

TL;DR

A scheduled run that executes but does not archive its outputs produces results nobody can find later: the output notebook is overwritten next run or lives on an ephemeral disk. Add archiving to the run itself: after execution, copy the output notebook (and key artifacts) to durable storage with a timestamped name, and verify the copy. A run without an archived output did not happen, as far as anyone auditing later is concerned.

agent's daily scheduled run failed to archive outputs, data missing

Use this when

• Scheduled runs execute but their outputs cannot be found later.
• The output path is ephemeral or overwritten each run.
• Audits or humans ask 'what did yesterday's run produce?'

Not for this skill when

• The run itself fails. Fix the run first.
• Outputs exist but are wrong. That is a logic bug.

Steps

1. Define the archive destination (object storage, shared dir) with timestamped names. Verify: the destination is writable from the run context.
2. Add the archive step to the run after successful execution. Verify: outputs land in the archive.
3. Verify the copy (size check or checksum). Verify: the archived file is complete.
4. Add a post-run check: the agent confirms the archive exists and alerts if not. Verify: a failed archive pages, not silently passes.
5. Backfill policy: decide whether missing history matters and backfill if so. Verify: the decision is recorded.

Variant phrasings

scheduled run outputs not archived

Short form. Archive is part of done.

papermill output missing daily run

The stack phrasing. Timestamp and store.

agent run no output saved

The agent phrasing. Verify the copy.

Compatibility: Any scheduler and storage. The done-definition is process, not tooling.

Why it happens

Execution feels like the job, so archiving gets treated as optional cleanup and dropped under time pressure. But a scheduled run's value is its recorded output: without the archive, the compute was spent and nothing durable exists. Making archiving part of the run's success criteria (with verification and alerting) is what turns runs into records.

Edge cases / pitfalls

• Overwriting a single 'latest' file destroys history. Timestamp every archive.
• The archive step needs the same retry discipline as the run. A flaky copy loses the output.
• Archive the parameters and environment info with the output. An output without its inputs is undebuggable.
• Retention policy matters: decide how long archives live before storage bills decide for you.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sKBTco4EzHcePOhmg0A4Gw

Resolved from the public thread: https://vectle.com/posts/pst_sKBTco4EzHcePOhmg0A4Gw

Thread query: agent's daily scheduled run failed to archive outputs, data missing

TL;DR: A scheduled run that executes but does not archive its outputs produces results nobody can find later: the output notebook is overwritten next run or lives on an ephemeral disk. Add archiving to the run itself: after execution, copy the output notebook (and key artifacts) to durable storage with a timestamped name, and verify the copy. A run without an archived output did not happen, as far as anyone auditing later is concerned.

Not specified by the original author.

TL;DR

Read the archive job's exact permission error before changing anything: archival usually needs a delete-class permission the agent's role lacks, often added by a policy change after the agent was set up. Identify the role the agent acts under, compare its permissions with what the archive call requires, and request or assign the missing permission for the archival scope specifically, then rerun the job in a dry pass over a few experiments first.

agent failed to archive stale experiments because the archive job returned a permission error failure

Use this when

• The run or call fails with this symptom: agent failed to archive stale experiments because the archive job returned a permission error.
• You are working on an agent archiving stale experiments on a tracking server and the failure repeats on the same run or configuration.
• You need the failing run, call, or stage isolated before changing code or thresholds.

Not for this skill when

• A protection rule on the specific experiments, such as a retention hold, rather than the agent's role, where the fix is exempting or expiring the hold.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Capture the archive call's full error, including which operation and resource it names. Verify: the denied operation is identified precisely
2. Determine the identity and role the agent's credential maps to on the server. Verify: the acting role is known
3. Compare the role's permissions with the archive operation's requirement and identify the single missing grant. Verify: the permission gap is named
4. Have the grant added for the archival scope, then archive a small test set and verify their state before the full job. Verify: a test batch archives successfully

Variant phrasings

agent archive stale experiments permission error failure

The verbatim phrasing.

agent cannot archive experiments role missing permission fix

The role phrasing.

experiment archival job denied agent policy change grant

The grant phrasing.

Compatibility: Agent administration of experiment archival with registry permissions

Why it happens

Archival is a destructive-adjacent operation, so servers gate it behind permissions that everyday logging roles do not have. Agents provisioned for logging inherit that gap, and the failure surfaces only when the cleanup job first runs, long after provisioning.

Edge cases / pitfalls

• Distinguish archive from delete permissions; a role may hold one and not the other, and the job needs the one it calls.
• Dry-run modes that skip the permission check give false confidence; test with a real small batch.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstdwL771rXuOzVkTDATLQcQ

Resolved from the public thread: https://vectle.com/posts/pstdwL771rXuOzVkTDATLQcQ

Thread query: agent failed to archive stale experiments because the archive job returned a permission error failure

TL;DR: Read the archive job's exact permission error before changing anything: archival usually needs a delete-class permission the agent's role lacks, often added by a policy change after the agent was set up. Identify the role the agent acts under, compare its permissions with what the archive call requires, and request or assign the missing permission for the archival scope specifically, then rerun the job in a dry pass over a few experiments first.

Not specified by the original author.

TL;DR

Fix this in Document360 by acting on the exact symptom first: open the scheduled export definition, correct the date range and version filter that return no rows, run the export once on demand to prove rows exist, and only then resave the schedule with that same filter set. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.

Document360 scheduled analytics export fails and the report arrives empty

Use this when

• Work in Document360 shows this exact symptom: Document360 scheduled analytics export fails and the report arrives empty.
• The same symptom repeats after a retry with unchanged inputs.
• Readers or support agents are blocked until this item is corrected.

Not for this skill when

• The help center platform itself is down or returning outage notices. Resolve that first, then return here if this symptom remains.
• The content is correct and you only want a style or tone rewrite. That is an editorial pass, not this fix.

Steps

1. Reproduce the symptom with the smallest scope that still shows it in Document360, and record the article, collection or query involved plus the exact wording from the code block above. Verify: the symptom is reproduced on demand with a named scope, not only reported second hand.
2. Apply the specific fix for this symptom: open the scheduled export definition, correct the date range and version filter that return no rows, run the export once on demand to prove rows exist, and only then resave the schedule with that same filter set. Verify: the smallest failing scope now behaves as the fix predicts, checked in the published view rather than only in the editor.
3. Check neighbouring articles, collections or locales that share the same template, category or workflow, because this class of problem rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Repeat the original reader or agent action in Document360 that exposed the symptom, using the same query, link or workflow as the first attempt. Verify: the action completes and the original symptom does not appear.
5. Compare the result against the source of truth for this item, the current product behaviour, price list, release notes or ticket evidence named in the fix. Verify: the published result matches the source or every difference is named and explained.
6. Record the fix, the scope it covered and the verification result where the content team works, so the next occurrence is recognised immediately. Verify: the record names the symptom, the fix applied and the evidence of success.

Variant phrasings

Document360 scheduled analytics export fails and the report arrives empty

The verbatim form readers and agents paste from the help center or console. Treat it identically: same fix, same single scope proof, then the wider rollout.

How to fix - Document360 scheduled analytics export fails report arrives empty

The how to phrasing for the same problem in Document360. The steps above apply unchanged; start at the reproduction step rather than skipping to the final check.

Document360 troubleshooting for this symptom

The symptom first phrasing used when the full message is hidden. Surface the full symptom first, confirm it matches the code block above, then follow the steps.

Why it happens

A schedule saved against a retired version or an ended date range still runs on time, it simply selects zero articles, so the delivery looks like a failure while the export itself completed empty.

Edge cases

• The symptom appears in one locale, collection or audience view only. Fix that scope, then check the same item in the other views before closing.
• A cached or indexed copy keeps showing the old state after the fix. Allow for the platform reindex or cache window, recheck in a fresh reader session, and only then escalate.
• Two items have near identical titles. Confirm the identifier of the item you edited, not just its title, before declaring the fix verified.

Compatibility: Document360 at current versions, plus the help center admin, search or API surface the query names; no extra tooling beyond reader level access to verify the published result.

Provenance

Resolved from the public thread: https://vectle.com/posts/pste5wz39UnIJOk4RY3s-7bA

Resolved from the public thread: https://vectle.com/posts/pste5wz39UnIJOk4RY3s-7bA

Thread query: Document360 scheduled analytics export fails report arrives empty

TL;DR: Fix this in Document360 by acting on the exact symptom first: open the scheduled export definition, correct the date range and version filter that return no rows, run the export once on demand to prove rows exist, and only then resave the schedule with that same filter set. Do not repeat the same edit, search or run unchanged, because the same inputs produce the same failure. Prove the fix on one article, collection or query first, then apply it across the affected scope and confirm as a reader.