agent parsed the maintenance iCalendar feed with the wrong year and an

Not specified by the original author.

TL;DR

Fix the iCalendar parsing to use the event's full date including year (and its timezone), correct the announced window, and add a sanity check that rejects maintenance dates implausibly far in the future, because announcing a window a year early destroys trust in every later announcement. Prove it on one test incident before rolling it to the rest of updates on the live incident, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

agent parsed the maintenance iCalendar feed with the wrong year and announced the window a year early

Use this when

• You see this exact error or symptom: agent parsed the maintenance iCalendar feed with the wrong year and announced the window a year early.
• The failure is in the status page agent and the status provider named in the title, and it repeats on the same action rather than happening once and clearing.
• Other items on the same path are working, so the path itself is up and this specific condition is the blocker.

Not for this skill when

• A different error code, message, or tool is involved. Work that error's own skill, because the fix here targets this specific condition.
• The whole service or platform is down. Restore the service first; this skill fixes the named condition, not an outage.
• You cannot identify one affected item to test on. Find one first, because an untested fix rolled out broadly is how this fault gets worse.

Steps

1. Confirm the fault on one test incident first and capture the evidence before changing anything: check the agent run log for the incident, the provider API response it acted on, and the public page as a logged-out visitor sees it, and record the exact error text, the record or host involved, and the time it happened. Verify: you can point to the exact error and the exact item it belongs to, not just the symptom
2. Fix the iCalendar parsing to use the event's full date including year (and its timezone), correct the announced window, and add a sanity check that rejects maintenance dates implausibly far in the future, because announcing a window a year early destroys trust in every later announcement. Verify: the specific fault named in the title no longer occurs on that item when you repeat the action that produced it
3. Add an identity check before the action is taken: the acting step must confirm it is operating on the intended record using a stable identifier, not a display value, amount, or time proximity. Verify: the guard or check is in place and is visible in the run, log, or configuration you changed
4. Retest end to end: rerun the agent against a test incident or draft and confirm the public page, the component statuses and the notifications match what the agent intended. Verify: the retest completes without the original error and the resulting state matches what a manual check shows
5. Roll the fix out to the rest of updates on the live incident in the same way, watching the first few for the same error, and note the root cause and the change in the run or incident record. Verify: the remaining items complete without the error recurring, or the ones that still fail are listed individually with their own evidence

Variant phrasings

agent parsed the maintenance iCalendar feed with the wrong fix

The verbatim error or code phrasing for this fault in the status page agent; the fix is the same one in the steps above.

agent parsed the maintenance iCalendar feed with the wrong year and

The full symptom phrasing as it appears in the console, log, or report where this failure surfaces.

how to fix agent parsed the maintenance iCalendar feed with the

The how-to phrasing for the same fault; start with the TL;DR fix, then work the steps in order.

Compatibility: Statuspage, Instatus, Better Stack, Cachet and PagerDuty integrations used by status page agents, as named in the title.

Why it happens

This fault happens because matching on display values, amounts, or timing works until two real records share them, which happens routinely at fleet, campaign, or month-end scale. In this case the condition is the one named in the title, in the status page agent and the status provider named in the title: the receiving or acting side reports the failure faithfully, but the underlying state (a record, a setting, a credential, a file, or a mapping) does not match what that action assumes. Fixing the state, as in step 2, clears it; retrying the action without changing the state returns the same error every time, which is why this failure looks stubborn until the state itself is corrected.

Provenance

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

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

Thread query: agent parsed the maintenance iCalendar feed with the wrong year and announced the window a year early

TL;DR: Fix the iCalendar parsing to use the event's full date including year (and its timezone), correct the announced window, and add a sanity check that rejects maintenance dates implausibly far in the future, because announcing a window a year early destroys trust in every later announcement. Prove it on one test incident before rolling it to the rest of updates on the live incident, because this fault repeats identically wherever the same condition holds and a fleet-wide or batch-wide first attempt multiplies the damage when the diagnosis is wrong.

Not specified by the original author.

TL;DR

Fix this in the maintenance calendar by acting on the exact message first: parse calendar times with their timezone attached, convert once to the detector timeline, and test the suppression against one known past maintenance window before relying on it. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

agent failed to suppress known maintenance window alerts after calendar parse error failure

Use this when

• The operation in the maintenance calendar fails with this exact message: agent failed to suppress known maintenance window alerts after calendar parse error failure.
• The same failure repeats on retry with unchanged inputs.
• A review, export or check is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in the maintenance calendar, and copy the full message plus the item, user or metric involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: parse calendar times with their timezone attached, convert once to the detector timeline, and test the suppression against one known past maintenance window before relying on it. Verify: the known window is suppressed and alerts outside windows still fire.
3. Check the neighbouring items that share the same config, ontology, baseline or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in the maintenance calendar on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, decisions or alerts against the source in the maintenance calendar so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

A window parsed in the wrong timezone suppresses the wrong hours, so real alerts inside the actual window still page.

Variant phrasings

agent failed to suppress known maintenance window alerts after calendar parse error failure

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix: agent failed to suppress known maintenance window alerts after calendar parse error failure

The how-to phrasing for the same failure in the maintenance calendar. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

the maintenance calendar troubleshooting for this failure

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

Compatibility: the maintenance calendar at current versions, plus the platform API or console the query names; no extra tooling beyond a text editor and the source system access needed to verify counts.

Provenance

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

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

Thread query: agent failed to suppress known maintenance window alerts after calendar parse error failure

TL;DR: Fix this in the maintenance calendar by acting on the exact message first: parse calendar times with their timezone attached, convert once to the detector timeline, and test the suppression against one known past maintenance window before relying on it. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Not specified by the original author.

TL;DR

A swapped date never looks broken, the thirteenth of a month is impossible and gets caught, but the fifth of June read as May the sixth sails through every validation and quietly moves a renewal by a month. Contracts mix date conventions by counterparty and country, and an agent parsing all of them with one assumed order will swap every ambiguous date it meets. Detect the pattern from the impossible dates it rejected, parse with the documents own locale evidence, route true ambiguity to humans, and rebuild the forecast from corrected dates.

agent extracted renewal dates from contracts with day and month swapped: forecast off by months

Use this when

• Extracted renewal dates are systematically off by weeks or months, clustering where day and month values are both small
• Some contracts failed extraction with invalid dates, the visible tip of the same problem
• The contract set spans countries or counterparties with different date conventions

Not for this skill when

• The agent reads dates correctly and the forecast error comes from amendments changing the real dates later
• Contracts use one consistent format and the errors are random OCR misreads of digits, a different defect

Steps

1. Measure the swap pattern from evidence. Gather extracted renewal dates and their source contract texts for a sample, compare each against the date as written in the document, and count how many match a day month swap exactly, how many are correct, and how many failed as impossible. The impossible ones, where the day value exceeds twelve in the written order, prove which convention those documents used. Verify: the sample is classified into swapped, correct, and previously impossible with counts
2. Find the parsing assumption in the agent. Locate where extracted date strings become dates, identify the single format or locale the parser assumes, and check whether anything upstream, OCR, a template, or a language model extraction step, normalises the written date before parsing, because a helpful normalisation to one format is often where the original convention information is destroyed. Verify: the parsing assumption and any normalising step are pinpointed
3. Rebuild parsing on document evidence. Determine each contracts convention from unambiguous clues in the document itself, dates written in words, a governing law or address country, the contracts own date format elsewhere, or an impossible value that reveals the order, and only then parse the renewal date with that convention, recording which evidence decided it alongside the extracted value. Verify: the rebuilt parser classifies the sample correctly with the deciding evidence logged per contract
4. Route genuine ambiguity to people. Where a date is ambiguous and no document evidence resolves it, the agent must flag the contract for human reading instead of guessing, and the forecast should show that renewal as date uncertain within a range, because a guessed date presented as fact is worse than an honest range a rep can plan around. Verify: ambiguous test contracts are flagged with a range rather than assigned a guessed date
5. Repair the forecast and its history. Re-extract renewal dates across the contract base with the corrected parser, list every date that changed and by how much, rebuild the renewal forecast, and brief the owners of accounts whose renewal moved materially, since some renewals are now months sooner than the plan they are working to. Verify: changed dates are listed and owners of materially moved renewals are briefed
6. Add date extraction tests and monitoring. Keep contracts covering each convention and the ambiguous case as regression fixtures, and monitor extracted dates for sanity, renewal dates in the past for active contracts, impossible clustering on the first of a month, and report extraction confidence per contract so forecast consumers can see which dates are solid and which are inferred. Verify: the regression fixtures pass and the sanity report runs on the live extraction

Why it happens

Most of the world writes day before month and one large market writes month before day, and both produce identical looking short dates for most of the month. A parser must choose, and a single global choice is wrong for a mixed contract base roughly whenever the day is twelve or under, which is most renewals. The errors are worst precisely because they are small and plausible, shifting quarters and cohorts without ever triggering a sanity check that looks for broken values rather than wrong ones.

Compatibility: Contract date extraction by agents, OCR and document parsing, locale date conventions, and renewal forecasting, in current document processing tooling.

Variants and edge cases

renewal dates day month swapped contract parsing

['The direct phrasing. Impossible dates in the rejection pile are diagnostic treasure, they reveal the documents true convention without guessing.']

agent extracted wrong renewal dates locale format

['The locale variant. Evidence based per document parsing beats a global setting, mixed portfolios guarantee any single setting is wrong for someone.']

forecast off months contract date extraction

['The forecast variant. List every changed date when you repair it, a silently rebuilt forecast leaves reps working from memorised wrong dates.']

Edge cases to work through before you close the incident:

• Dates written in words are the gold standard in a contract. Where they exist, extract them preferentially and use them to calibrate the numeric dates in the same document.
• A two digit year adds a second ambiguity layer. Handle it explicitly in the parser rules rather than inheriting a library pivot year silently.
• Amendments can carry dates in a different convention from the master agreement if the parties differ. Parse each document on its own evidence, never inherit the account level assumption blindly.

Provenance

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

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

Thread query: agent extracted renewal dates from contracts with day and month swapped: forecast off by months

TL;DR: A swapped date never looks broken, the thirteenth of a month is impossible and gets caught, but the fifth of June read as May the sixth sails through every validation and quietly moves a renewal by a month. Contracts mix date conventions by counterparty and country, and an agent parsing all of them with one assumed order will swap every ambiguous date it meets. Detect the pattern from the impossible dates it rejected, parse with the documents own locale evidence, route true ambiguity to humans, and rebuild the forecast from corrected dates.