Cypress Cloud Slack and GitHub alerts: failure-only notifications without losing flaky test visibility

Short answer

Yes, you can get failure-only alerting without losing flake visibility, but the pieces live in different places. Slack and GitHub notifications are configured per integration at the organization or project level, so filters apply broadly, not per spec. Flake analytics are derived from recorded run history, so muting notifications does not remove flaky specs from analytics — only skipping or excluding those specs from CI does. The clean split is: failure-only Slack scoped to main and release branches, and GitHub statuses plus PR comments on feature branches as the early-warning channel.

1. Branch and outcome filters in Slack

The Slack integration exposes both event selection (failing runs, passing runs, and similar) and branch selection, and combining them in one integration is the intended pattern — for example, "failed runs on main and release/* only." The exact set of combinable options is UI- and plan-dependent, so confirm against your own project's integration settings rather than assuming the documentation matches your tier.

If feature-branch failures must also reach Slack, don't widen the main integration. Add a second Slack integration pointing at a separate channel or webhook scoped to feature branches, so the low-noise channel stays low-noise and the noisy channel is opt-in.

2. Muting versus flake analytics

Muting a known-flaky spec affects notifications, not data. Flake detection is computed from recorded run history — the same spec passing and failing across runs without code changes — and that history is not deleted when you mute. Flake analytics generally survive muting.

What does degrade flake signal is anything that stops the spec from running: skipping it, excluding it from CI, or trimming feature-branch runs. Fewer recorded runs means a smaller sample for detection to learn from.

One caution: muting is triage hygiene, not a fix. A muted spec that fails for a genuine reason still produces a failing run and, depending on configuration, a failing GitHub status check. The failure signal isn't gone — it's just quieter.

3. GitHub statuses versus PR comments

Commit status checks and pull-request comments are separate behaviors of the GitHub integration, and you control whether each is posted and for which branches. Status checks are the pass/fail signal that branch protection consumes, so be careful here: if you suppress passing-run statuses or scope statuses too narrowly, a branch protection rule that requires the Cypress check on every commit will block merges because the expected status never arrives. Keep status checks reporting on every relevant commit; reduce noise with PR comment settings instead.

Recommended configuration

1. Slack integration A: failed runs only, main and release branches, team channel.
2. Slack integration B (optional): failed runs on feature branches, separate triage channel.
3. GitHub integration: status checks on all recorded branches; PR comments enabled for run summaries, including flaky-test callouts.
4. Mute known-flaky specs for notifications only; keep them running so flake analytics keep accumulating.

Verify before relying on it

• Trigger a deliberately failing run on a feature branch and a passing run on main; observe which Slack messages, statuses, and PR comments actually appear.
• After several recorded runs of a muted flaky spec, check the project's flaky-test view to confirm data still accumulates.
• Compare the options your project exposes against your plan tier's feature list — some flake and alerting capabilities are gated.

One diagnostic question that changes everything: are feature-branch runs recorded to Cypress Cloud at all? If they aren't, no alerting or flake configuration can produce signal from them, and the fix is in your CI workflow, not in notification settings.