A required Actions status remains pending or never appears

Understand the likely causes

• Workflow-level branch or path filters can prevent creation of the run that would publish a required status. A renamed job, event-specific omission, or unsupported merge path can leave protection expecting a different check.
• Job conditions and needs can skip work inside an existing run, while runner labels, concurrency, and approval can delay an existing job. These are distinct boundaries; changing the test command cannot repair a workflow that was never selected.

Write down the expected status and revision

Capture the exact status required by repository protection, the intended event and revision, and the job identity actually published. Use the repository’s existing authorized metadata, not a guess based on the workflow filename. A friendly display name can differ from the identifier used in an expression or protection rule. Check whether a matrix changes the visible job name and whether multiple workflows publish confusingly similar names.

Separate absent runs from absent jobs

Inspect the event declaration and effective policy first. For a pull request, branch filtering concerns the base branch; path exclusions can prevent the whole workflow. If merge queues are used, review the documented merge-group event requirements for the repository’s check path. Do not add every event blindly: duplicate push and pull-request runs can consume capacity and publish conflicting evidence. The diagnostic map below distinguishes the next review boundary.

No matching run -> event, filters, policy, tested revision
Run exists, job absent or skipped -> job condition and needs
Job queued -> runner selection, concurrency, approval
Job completed -> published identity and protected revision

Review skip behavior without weakening the contract

For an existing run, trace job-level if, dependency conclusions, and matrix expansion. A required check should have a meaningful terminal outcome on every supported merge path. A lightweight decision job can sometimes preserve a consistent gate while deciding whether deeper checks are necessary, but only when exclusions model dependency impact accurately. A shared build or policy file must not bypass validation merely because it sits outside an application directory.

Change the smallest inconsistent relationship

Align a renamed published status with the intended protection contract, or correct the event gap and filter logic under the repository’s review process. For queueing, involve the platform owner and inspect actual eligible capacity. Avoid a print-only success job that satisfies the name while abandoning the original risk coverage. Preserve the original missing case so the correction can be reviewed against a concrete example rather than a general impression that checks now look green.

Keep it from recurring

• Maintain an event-to-check table, stable required-check names, dependency-aware exclusions, and explicit ownership for merge-path changes. Review callers and protection rules when renaming jobs or restructuring matrices. Monitor missing status and queue age separately from failing test assertions.