GitHub project status to clients by Slack or email digest

To send GitHub project status to customers, start with GitHub Projects' own status updates, write them in client language, and deliver them by email or a shared Slack channel. Your options for delivery are an automation tool, a workflow your engineers own, or a dedicated client-facing tool. The digest tools covered here, such as Git Digest and Zapier's GitHub templates, summarize code activity for engineers, so whichever you pick, keep a separate project and a human-written note for each customer.

Which tools can turn GitHub status into a client digest?

The options for turning GitHub status into a client digest are GitHub Projects' own status updates, automation templates such as Zapier's scheduled Slack digests, a scheduled workflow your engineers maintain, and dedicated digest or client-portal products. Each sends different content to a different audience, so the right choice depends on whether your customers have GitHub access.

For GitHub-native automation, GitHub's changelog announced GraphQL and webhook support for project status updates: a ProjectV2StatusUpdate GraphQL object and a projects_v2_status_update webhook. Those are the names your engineers can search for, and they let an automation pick up the update you wrote rather than raw issue events.

What should a client onboarding digest contain?

A client onboarding digest should tell the customer's sponsor whether the rollout is on track, what finished, what comes next, and what is waiting on them. Leave out commits, branch names, and internal tickets. If a line would not make sense to the sponsor reading it on a phone, rewrite or remove it.

A feature request in the Orbit tracker sketches a useful internal shape: each project's health, its latest update headline and author, stale projects called out at the top, a configurable day, and the digest off until an admin turns it on. For customers, keep the health and headline and add the asks.

Copy this template into your status update note or email:

Subject: [Customer] onboarding update: [On track / At risk / Off track]

Overall: [Status]. Target go-live: [date].

Done since the last update
- [Milestone or deliverable], [one plain sentence on what it means for them]

Next
- [Milestone], expected [date]

Waiting on you
- [Decision, review, or access needed] by [date], so that [what it unblocks]

Risks
- [Risk in plain language], and what we are doing about it

Questions: reply to this email or post in [shared channel].

The "Waiting on you" block matters most. Name one owner on the customer side for each item and a date, and say what slips if it waits.

How do you keep internal work out of the digest?

You keep internal work out of a client digest by separating what the customer sees at the source, before any tool touches it. Give each customer its own GitHub project, mark which items are client-visible, and have a person write the status note. Filtering after the fact is where other clients' data and engineering noise leak through.

1. Create one project per customer and add only the issues that belong to that rollout. Never point a digest at an org-wide project or a shared repo.
2. Add a field or label for visibility, such as [Client-visible], so automations and people both know what can go out.
3. Track milestones, not tasks. Use the project's Status and date fields for onboarding milestones such as [kickoff], [data migration], [training], and [go-live].
4. Write the status note yourself. GitHub's status updates carry a written note alongside the status and dates. Write it for the sponsor, not the engineers.
5. Check before the first send. Read the digest as if you were the customer, and look for internal names, issue numbers, other customer names, and jargon.

How do you set up a recurring digest step by step?

To set up a recurring client digest, decide the cadence with the customer, post a GitHub status update on that day, and then route it to the customer by email or a shared Slack channel. Start with a manual send for the first few cycles, then automate delivery once the content is stable.

1. Agree with the customer's sponsor on a cadence and channel at kickoff. Ask: "Would you like project updates by email, in our shared channel, or both, and who should receive them?"
2. On the agreed day, post a status update on the customer's project with the status, dates, and the template above as the note.
3. Copy the note into an email or the shared channel. Doing this by hand at first shows you what reads well.
4. When the format settles, pick the route that matches who will own it.
   • If engineering owns it: ask them to listen for the projects_v2_status_update webhook or read the ProjectV2StatusUpdate object over GraphQL, both described in GitHub's changelog. Then post the note to that customer's Slack incoming webhook, or send it with an email action such as dawidd6/action-send-mail, as the GitHub Community thread describes. Ask for your status note to be sent, not issue events.
   • If you want no-code: start from the schedule pattern in the Zapier templates, and swap the pull request trigger for the New Issue trigger listed in Zapier's GitHub trigger catalog. That trigger asks for an Organization, a Repo, and a Label, so set the Label to [Client-visible] and only labelled issues go into the digest. The linked templates end in a Slack "Send Channel Message" step, so sponsors who want email need an email step added.
5. Keep a review step. Have the digest land with you before it goes out, or post the note yourself so nothing unreviewed reaches the customer.

Should each customer get the digest in Slack Connect or by email?

Choose the channel each customer's sponsor actually reads. A shared Slack Connect channel suits customers whose working team lives in Slack and wants quick back-and-forth. Email suits executive sponsors, customers whose IT team limits shared channels, and anyone who needs a record to forward. You can send both: the channel for the working team, email for the sponsor.

Ask at kickoff rather than guessing, including whether the customer's IT team allows shared channels with outside companies. For a shared channel, keep it to one customer, pin the latest update, and post decisions there in a thread so they are easy to find. For email, send from a person, not a no-reply address, so the sponsor can answer directly. The GitHub Community thread is a reminder that many stakeholders have no GitHub seat, so do not rely on subscriptions inside GitHub to reach them.

Which option fits per-client onboarding projects?

For per-client onboarding, use GitHub status updates as the source and pick delivery by how many customers you run and who owns the automation. With a few customers, a hand-sent update is enough. With many, automate delivery but keep a person writing each note. Choose a dedicated tool when customers need to respond, not just read.

• If you run a few customers with a small team, post a GitHub status update and send it yourself.
• If you run many customers and someone in engineering can own a workflow, have it send each project's status note to that customer's channel or email list.
• If you run many customers and nobody in engineering has time for it, use a no-code automation for delivery and keep your review step before each send.
• A digest only informs. When the sponsor needs to reply with an approval, a decision, or help with a blocker, a client tool built for asks and replies fits better than another summary. Unblockd has "Asks to the sponsor by email with one-tap answers (no account), or answered by replying to the email."

What mistakes make client digests backfire?

The common mistakes are sending engineering activity instead of progress, pointing automation at shared repos, and burying the asks. Each one makes the customer read more and act less. Fix them at the source and in the template rather than adding more filters later.

• Sending commit or pull request counts. Customers want milestones and dates.
• Letting the status say On track while a customer-side item is late. Say what is waiting on them.
• Sending to a distribution list with no named owner. Address each ask to one person.
• Changing format every cycle. Keep the same sections so the sponsor knows where to look.

Before your next customer check-in, open that customer's GitHub project, post one status update using the template, and send it by the channel the sponsor prefers.