A required check waits forever or never appears

Understand the likely causes

• Event filters, path filters, conditional job rules, and mismatched required status names can prevent the expected evidence from being created. A duplicate pipeline can publish a similarly named status for the wrong event or revision.
• A created job can also be blocked by an upstream dependency, manual decision, unavailable runner label, concurrency group, or capacity limit. Extending the test timeout does not fix a job that never starts.

Identify the expected evidence

Write down the exact required status name, intended revision, event class, and policy that requires it. Compare those with the run that actually exists. A check on a source branch may not satisfy a gate for a synthesized merge result. Do not temporarily remove the requirement merely because a user is waiting; first establish whether the process failed to create evidence or is correctly waiting for an unmet condition.

Classify the waiting boundary

Use retained platform metadata to distinguish no pipeline, no job, queued job, running job, and completed job with a mismatched status. The following diagnostic tree is a conceptual decision aid. It does not claim that every CI product uses the same state names or that one API field is enough to identify the cause.

No pipeline -> inspect event and pipeline-creation rules
Pipeline, no job -> inspect job conditions and required names
Queued job -> inspect dependencies, approval, labels, capacity
Completed job -> inspect revision and published status relationship

Review the event matrix and exclusions

Trace proposal, push, tag, and schedule behavior together. If path filtering suppresses the entire workflow, a required status may never be reported. If the product supports a lightweight decision job, it may explicitly evaluate whether deeper tests are required while retaining a consistent gate; implement that only with dependency-aware exclusions. Shared build or policy changes must not be classified as harmless merely because application directories were untouched.

Investigate actual queueing separately

When a job exists and is queued, compare its required runner labels and environment with available authorized capacity. Read dependency and concurrency reasons before changing the script. A lock held by another deployment is different from an unavailable worker. Coordinate any platform correction with its owner. Re-running identical jobs can increase the backlog and obscure the original queue cause rather than improve feedback.

Correct one cause and preserve policy

For a naming mismatch, align published and required status identity. For an event gap, make the relevant check appear on every supported merge path. For legitimate exclusions, publish explicit reviewed evidence of the decision where the platform supports it. For capacity, change scheduling or resources through the platform owner. Avoid a blanket success job that reports green without evaluating the risk the original gate was meant to cover.

Keep it from recurring

• Keep trigger tables, required status names, and dependency-aware filters reviewed together. Retain a small set of negative event cases and monitor missing-status or queue-age symptoms separately from test failures. Give platform scheduling and application checks clear owners.