/pro/errors shows recorded incidents, occurrence counts and resolution state. It does not detect an external service failure between refreshes.
A fatal failure before the commit leaves the last published SVG intact. A handled asset failure can publish a new SVG with a placeholder or fallback and report degraded health. A successful commit therefore does not prove that every remote widget rendered successfully.
What an incident identifies
The telemetry endpoint creates generic IDs such asexternal-widget-1 and labels such as External Asset (hostname). It currently categorizes failed URLs as FETCH_TIMEOUT; that label does not prove the underlying cause was a timeout. Use the URL and workflow log to diagnose the failure.
Resolve incidents in the console after repairing the configuration and checking a subsequent run. The simulator creates real stored incidents, so simulated records should also be resolved.
Email alert limitation
The error-alert path checks Pro eligibility, email preferences and a one-hour cooldown. However, the currentsendWidgetErrorAlertEmail implementation calls only logSentEmail with a sent status. That store persists the record; this path does not invoke an email provider.
Consequently, an error-alert entry in /pro/emails is not evidence that a notification reached an inbox. This limitation concerns the widget-error path specifically, not every transactional email in GitAscii. Use the errors console and GitHub Actions logs to inspect publication failures.
Sources: error tracker, email log store. See also health monitoring.