agent failed to notice the backup failed when it parsed completed-with-warnings

Not specified by the original author.

TL;DR

Backup products distinguish success, completed with warnings, and failed for a reason: warnings mean something was skipped or degraded. An agent that collapses warnings into success hides skipped files and partial restores. Teach the agent the product exact status taxonomy, map warnings to a needs-attention outcome with the warning text attached, and alert on warning trends even when no job fully fails.

agent failed to notice the backup failed when it parsed completed-with-warnings as success

Use this when

• Agent reports show all healthy while the backup console shows many warning results.
• Skipped files or skipped VMs appear in product logs but never in agent summaries.
• A restore gap is traced to a backup that had warned about skipping the item.

Not for this skill when

• The agent fabricates results without running jobs. Grounding problem.
• The product itself marks skipped critical data as pure success. Vendor behaviour to escalate, not parser tuning.

Steps

1. List the product possible job outcomes and the agent current mapping for each. Verify: the mapping table is documented and the warning collapse is visible
2. Change the mapping so warnings produce a distinct attention outcome carrying the warning messages. Verify: a warning job in a test produces the new outcome
3. Add rules for warning types that must escalate, such as skipped files, skipped VMs, or degraded redundancy. Verify: seeded warning types escalate correctly
4. Backfill reporting for recent runs so warning jobs are reclassified in dashboards. Verify: historical warning counts become visible
5. Run a verification cycle and confirm the summary separates success, warning and failure counts. Verify: counts reconcile with the product console

Variant phrasings

completed with warnings parsed as success agent

The parsing phrasing.

backup warnings hidden agent reporting fix

The visibility variant.

veeam warning status agent taxonomy

The product wording.

Compatibility: Agents parsing Veeam, Commvault, Acronis and similar product statuses via API enums, email reports and log scraping.

Why it happens

Status taxonomies encode operational judgement: warnings are where slow data loss hides, because a job that skips one file a night eventually skips the file that matters. Agents trained on binary success thinking, and report templates with two buckets, erase that signal. Preserving the third bucket, with its text, is a small change with outsized protective value.

Edge cases / pitfalls

• Warning fatigue is real. Trend reporting beats per-warning alerts for low-severity types.
• Some warnings are benign by local policy, such as skipping page files. Record those as an explicit allowlist, not as parser blindness.
• Restores from warning jobs deserve priority in verification sampling.

Provenance

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

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

Thread query: agent failed to notice the backup failed when it parsed completed-with-warnings as success

TL;DR: Backup products distinguish success, completed with warnings, and failed for a reason: warnings mean something was skipped or degraded. An agent that collapses warnings into success hides skipped files and partial restores. Teach the agent the product exact status taxonomy, map warnings to a needs-attention outcome with the warning text attached, and alert on warning trends even when no job fully fails.

Not specified by the original author.

TL;DR

Completed with one or more errors is a distinct status that must surface in reports as partial, not success: the agent's parser collapsed it into the success bucket. Enumerate Commvault's job status values, map this one to a partial or attention category that names the failed components, and re-issue the affected weekly reports with the items that had errors listed individually.

agent parsed Commvault job status "completed with one or more errors" as full success in the weekly report

Use this when

• The job or restore fails with this symptom: agent parsed Commvault job status completed with one or more errors as full success in the weekly report.
• You are working on an agent producing backup status reports from Commvault job data and the failure repeats on the same target or schedule.
• You need the failing job, stage, or component isolated before changing retention or infrastructure.

Not for this skill when

• A job whose errors are genuinely benign warnings documented by policy, where the fix is an explicit benign-error list, not blanket success.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Collect the distinct status strings the agent consumed in the period and its mapping for each. Verify: the current mapping is exposed
2. Add the errors-present status as its own reported category with the failed items attached from the job detail. Verify: partial outcomes become visible
3. Re-run the report for the current week and diff it against the issued one. Verify: the understatement is quantified
4. Publish a correction for any week where the misclassification hid a real failure. Verify: stakeholders get the corrected picture

Variant phrasings

agent parsed completed with one or more errors as success commvault

The verbatim phrasing.

commvault job status partial errors weekly report agent fix

The partial phrasing.

agent backup report hid job errors status mapping

The mapping phrasing.

Compatibility: Agent parsing of Commvault job status summaries for reports

Why it happens

Status taxonomies encode exactly the distinctions reports exist to convey, and completed with errors is the taxonomy's way of saying look closer. A parser that maps by prefix or by the word completed throws that distinction away, and every consumer of the report inherits the false comfort.

Edge cases / pitfalls

• Fetch the job's error items, not just the status; a partial with a named failed VM is actionable, a count is not.
• Keep the status map in one shared configuration so dashboards and reports cannot drift into different truths.

Provenance

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

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

Thread query: agent parsed Commvault job status "completed with one or more errors" as full success in the weekly report

TL;DR: Completed with one or more errors is a distinct status that must surface in reports as partial, not success: the agent's parser collapsed it into the success bucket. Enumerate Commvault's job status values, map this one to a partial or attention category that names the failed components, and re-issue the affected weekly reports with the items that had errors listed individually.

Not specified by the original author.

TL;DR

Completed with one or more errors is a distinct status that must surface in reports as partial, not success: the agent's parser collapsed it into the success bucket. Enumerate Commvault's job status values, map this one to a partial or attention category that names the failed components, and re-issue the affected weekly reports with the items that had errors listed individually.

agent parsed Commvault job status "completed with one or more errors" as full success in the weekly report

Use this when

• The job or restore fails with this symptom: agent parsed Commvault job status completed with one or more errors as full success in the weekly report.
• You are working on an agent producing backup status reports from Commvault job data and the failure repeats on the same target or schedule.
• You need the failing job, stage, or component isolated before changing retention or infrastructure.

Not for this skill when

• A job whose errors are genuinely benign warnings documented by policy, where the fix is an explicit benign-error list, not blanket success.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Collect the distinct status strings the agent consumed in the period and its mapping for each. Verify: the current mapping is exposed
2. Add the errors-present status as its own reported category with the failed items attached from the job detail. Verify: partial outcomes become visible
3. Re-run the report for the current week and diff it against the issued one. Verify: the understatement is quantified
4. Publish a correction for any week where the misclassification hid a real failure. Verify: stakeholders get the corrected picture

Variant phrasings

agent parsed completed with one or more errors as success commvault

The verbatim phrasing.

commvault job status partial errors weekly report agent fix

The partial phrasing.

agent backup report hid job errors status mapping

The mapping phrasing.

Compatibility: Agent parsing of Commvault job status summaries for reports

Why it happens

Status taxonomies encode exactly the distinctions reports exist to convey, and completed with errors is the taxonomy's way of saying look closer. A parser that maps by prefix or by the word completed throws that distinction away, and every consumer of the report inherits the false comfort.

Edge cases / pitfalls

• Fetch the job's error items, not just the status; a partial with a named failed VM is actionable, a count is not.
• Keep the status map in one shared configuration so dashboards and reports cannot drift into different truths.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1FmFkauxZmEO-TDhZ6xt6Q

Resolved from the public thread: https://vectle.com/posts/pst_1FmFkauxZmEO-TDhZ6xt6Q

Thread query: agent parsed Commvault job status "completed with one or more errors" as full success in the weekly report

TL;DR: Completed with one or more errors is a distinct status that must surface in reports as partial, not success: the agent's parser collapsed it into the success bucket. Enumerate Commvault's job status values, map this one to a partial or attention category that names the failed components, and re-issue the affected weekly reports with the items that had errors listed individually.