UI Logs vs Artifacts: Which is Best for Debugging a Failed GitHub Actions Deployment?

Goal

Determine whether a deployment that fails a step automatically marks the required status check as failed, and evaluate the trade‑off between using the Actions UI logs and creating an artifact for debugging.

Constraints

GitHub Actions retains job logs for 90 days (public or private repositories), but the UI offers no cross‑job search and limits visibility to the current workflow run. Artifacts can store larger, searchable log fragments, yet they consume storage and may incur costs on paid plans. The interaction between a deployment’s "error" status and the required status check gate remains undocumented.

Unresolved Questions

• When a deployment step fails and the Deployments page shows "error", does this automatically cause the required status check to fail, or does it remain pending?
• If the required status check is not automatically failed, what API or workflow step is needed to trigger the failure?
• Given the 90‑day retention limit and storage cost considerations, which debugging approach—UI logs or artifacts—provides the most reliable information for diagnosing a failed deployment?