GitHub Actions iPhone notifications without Slack or email

There is a familiar shape to a deploy that takes nine minutes. You push, you switch tabs, you forget. Twenty minutes later you remember, alt-tab back to GitHub, and the run has been red for fifteen of them. The fix is half a line. The waste was the context switch back to checking.

GitHub Actions iPhone notifications should fix this, and mostly don't. The default channels — Slack #ci, an email digest, the GitHub mobile app — are tuned for inbox triage, not for "is my deploy still alive right now." You want a glanceable surface that opens on start, updates as the job moves, and closes green or red. Chirp contains a source-preview connector for that flow; no Marketplace release is claimed yet.

Why the usual notification paths feel broken

Slack notifications for CI start out useful and decay fast. After a week of green runs they are noise. After a month people mute the channel, and the one red run that mattered drowns in standup chatter. Email is worse — it batches, lands in a folder you check on a different cadence, and never tells you about the run that is currently in progress.

The GitHub mobile app gets closer, but it is still a notification: a banner you tap to see status. There is no persistent lock-screen surface that tracks the run's progress without you opening anything. For a long deploy, polling is exactly the wrong shape.

What Chirp gives you instead

• A Live Activity designed to open when the phone receives the job start and close when it receives the end — green on exit 0, red on anything else.
• Lock-screen and Dynamic Island progress without unlocking your phone.
• Optional rich push notifications on success or failure, with a tap-through to the workflow run page.
• The same shell helper across GitHub Actions, GitLab CI, Bitbucket Pipelines, Buildkite, Docker, and raw bash — one mental model, every runner.

Wire the reviewed source into a test workflow

The current repository recipe is a source-only composite action. Copy and review it under your repository; do not use an unverified Marketplace slug or source a mutable remote helper during a job.

1. 1Have Chirp issue a narrowly scoped headless credential after that issuance path is release-ready.
2. 2Store it as a protected GitHub Actions secret named CHIRP_SCOPED_CI_KEY; never expose it to fork pull requests.
3. 3Vendor the reviewed connectors/github-actions source as .github/actions/chirp and exercise it first in a reversible workflow.

The vendored action submits bounded state. Put the closing step behind `if: always()` and derive its success/failure state from trusted workflow context. Do not send stderr, secrets, commit messages, or arbitrary command output to a Lock Screen payload.

Request a notification on success or failure

If you also want a classic alert — a banner with title and body, tappable to a URL — call chirp_notify in conditional steps. A successful action response means Chirp accepted the request; call it delivered only after the target phone reports its separate receipt. When delivered, this is the closest replacement for the Slack-on-failure pattern: a Lock Screen alert with sound and a deep link to the run.

Notification payloads support sounds, subtitles, and tap-to-open URLs — full schema in the notifications reference. Remote `image_url` is disabled in the launch build and makes the API reject the request with HTTP 400; omit it rather than expecting a text-only fallback. For most CI use cases the two-arg call above is what you want.

Span build → test → deploy as one activity

The source action supports start, update, and end calls. Before using parallel jobs, retries, or matrix builds, verify the exact instance-correlation behavior and pass a stable workflow/run identifier wherever the current server contract supports one. Do not assume one schema ID is sufficient concurrency control.

This is the pattern to reach for when a deploy is long enough that a halfway progress update is worth more than a banner at the end. The full multi-step example is in the GitHub Actions integration walkthrough, alongside cross-job state, fork-PR gating, and the runner troubleshooting list.

Where this fits in the lock-screen story

GitHub Actions is the most common case, but it is not special. Reviewed source recipes also exist for Bitbucket Pipelines, Buildkite-style shells, Docker entrypoints, and bash. Their hosted or marketplace distributions remain preview. The wider argument for treating long-running work as a Live Activity instead of a push notification is in the companion post, Lock-screen status for long-running jobs.

Provision a narrowly scoped headless credential through GitHub Secrets. Do not reuse a broad key across unrelated jobs when a separate rotation boundary is practical. The dashboard tracks entitlement, acceptance, and phone delivery separately.

Try it on the next deploy

1. 1Use the verified signed Chirp iPhone build (iOS 16.1+) and pair with a reviewed CLI build.
2. 2After scoped headless issuance ships, add that credential as CHIRP_SCOPED_CI_KEY in GitHub Secrets.
3. 3Vendor the reviewed composite action and test a reversible workflow before a real deploy.

Push a reversible test commit and inspect two outcomes: whether Chirp accepted the event and whether the phone confirmed delivery. Setup details and availability notes live on the GitHub Actions integration page.