Aglet

How to triage a failed project setup check for a clear scope

The built-in check is a local first-use path, so its failure should be triaged through the application states it controls. Record the project, test-key metadata, intake action, queued or saved result, and visible status. Keep a failed local sample distinct from any claim about customer or external event intake.

Establish what is happening

  1. Capture the setup context

    Record the synthetic workspace and project, test-key environment, key metadata, setup role, event-intake action, and page message. Never include a test-key secret after its one-time display. Note whether the attempt was queued, saved, rejected, or left with no observable status.

  2. Follow the sample result

    Run the built-in check once, refresh, revisit the project overview, and open any linked Signal or Work Item. Compare request status, saved sample record, labels, and links. Keep timing observations separate from a confirmed persistence failure when the harness cannot control processing.

  3. Reproduce controlled failures

    Use an invalid or missing test key, wrong project context, repeated check, and interrupted request where the local workflow supports them. Record status and recovery action for each. Do not send customer data or assert that an external producer was tested by the built-in sample.

What to carry forward

Triage is complete when the failed check has a known project and key context, an observed request or status, and a clear saved-result outcome. If processing cannot be observed, mark it partial and preserve the exact last application state rather than calling it a timeout defect.

Keep the decision with the work.

Use a Work Item in Aglet to record the problem, the evidence you have, and the next decision. Add an owner and priority, then keep updates in the discussion so the next person can follow the reasoning.

Create an account See the product workflow