Get notified about blocked releases

Hear about releases that are blocked or need you, and about runs and pull request checks that fail, in the console's bell and by email. It takes about 2 minutes, and anyone in your company can choose their own settings.

Before you start

• Your GitHub account is linked in Integrations. Zof finds your pull requests through that link. Without it, the settings say "Link your GitHub account to hear about your own pull requests."
• Your workspace has email set up. Until then, the settings say "Email isn't set up for this workspace yet." The bell still works.
• The Zof GitHub App is installed, so Zof sees your pull requests.
• Zof is connected to send notifications. If the bell says "Notifications start once Zof is connected to your GitHub organization.", it isn't connected for your company yet. Email support@zofai.com.

What you hear about

Every event is on in the bell by default. Events marked "admins" go to company admins only.

The settings show each name on two lines, for example "Approval needed" over "Admins".

A few events need a word more:

• "Approval needed" goes to company admins when Zof's result for a pull request is "AWAITING APPROVAL" It opens the pull request's Quality gates tab, where the approval gate says who may approve and links Approve in GitHub.

• "Release blocked" goes to the pull request's author when Zof blocks a deploy of their change to a protected environment. A blocked merge sends "PR check failed" instead. See Branches and environments.

• "PR check failed" goes to the pull request's author when Zof blocks a merge, or when the evidence that arrived for it didn't meet policy (a blocking check failed, or the evidence contradicted or didn't match the requirement). It goes to company admins when Zof can't tell who the author is, or the author hasn't linked GitHub in Zof. A pull request still waiting for evidence doesn't send it.

• "Critical review finding" goes to the pull request's author when a code review finds a critical issue, or to company admins when Zof can't tell who the author is.

• "Manual run failed or couldn't run" goes to the person who started the run when it fails, errors, times out or can't be verified. When Zof can't tell who started it, it goes to company admins. A cancelled run sends no run notification, only the AI key ones below.

• "Credits added by the Zof team" goes to company admins once each time Zof staff add credits to the company. It says how many credits and when they expire, and links to Billing and usage.

• The three AI key notifications go to company admins when the company uses its own AI key (see Use your own AI key): when Zof's daily check finds the key or model no longer works, once per run or code review that switched to Zof's default model because the key failed, and once per run or code review that failed because the model rejected a request Zof sends. This covers pull request runs, and runs that were cancelled or timed out, too.

• "Payment failed" goes to company admins when Stripe can't take a payment for the company's plan. It says the day new runs stop unless the card is updated, and opens Billing and usage, where Update payment method lets you update the card. Each failed attempt is reported once, and attempts for the same invoice within a day share one bell item and one email.

• The three credit and spending limit notifications go to company admins when credits run low, when this month's spend plus credits held for running tests reaches 80% of the monthly spending limit, and when no more test runs fit under it. Each comes again only after it clears and happens again: credits are added or returned by finished runs, the limit is raised, or a new month starts. You get it at most once a day. They open Billing and usage. They're only a heads-up: the limit and your credits decide whether a run starts, whether or not anyone reads them.

• "Manual run passed" goes to the person who started the run, in the bell. Turn on Email for it to get an email too. Zof only says a run passed when the run reports a pass.

• "Scheduled run failed or couldn't run" goes to the person who created the schedule, or to company admins when Zof can't tell who that is.

• If more than 5 of your runs fail within 10 minutes, Zof sends one more email that counts the rest, instead of one email each. Every run still has its own bell item.

• A deploy decision uses the same three settings, in its own words: "Deploy to production authorized", "Deploy to production blocked" or "Deploy to production needs approval", naming the environment. It is a separate notification from the pull request's merge decision.

• "Release decision recorded" goes to the pull request's author, or to company admins when Zof can't tell who that is, when Zof records a decision it can't say is for a merge or a deploy. It never says the release is authorized. Open the change to see the result.

• "GitHub App, webhook or enforcement problems" goes to company admins, each with its own message:

  • "Merged without Zof's approval" names the pull request, what Zof still needed (evidence or approval, or that Zof blocked it), why GitHub didn't stop the merge, and what to do. It opens the change. For example, on a GitHub plan that can't block merges on a private repository, it says so and suggests upgrading the plan or turning on branch protection with the Zof check as required.
  • "Zof's check is no longer enforced on" a repository says why (for example, the GitHub plan or a removed rule) and how to fix it. It opens the repositories in Integrations.
  • "The Zof GitHub app was suspended" or "uninstalled" names the GitHub account and how to unsuspend or reinstall the app.
  • "Webhook deliveries failing" counts the failed deliveries. See Retry a failed delivery.

  Integrations › Issues lists the same problems that still stand: repositories where GitHub doesn't block merges on Zof's check, and merges without Zof's approval from the last 14 days. If Zof can't read them, it says "Couldn't check enforcement" instead of a count. See Enforcement statuses and Bypass Zof in an emergency.

• "System map drafts" goes to company admins when Zof drafts a system map for a repository: a draft you asked for, one drafted because the services or links changed, or the weekly one. It also tells admins when a draft Zof started by itself failed. It opens that repository's System map page. See Set up your system map.

• "System map not stored" goes to the person who accepted, stopped or adopted a system map when Zof couldn't store it, and to company admins when Zof can't tell who that was, or when that person hasn't linked GitHub in Zof or isn't in this company. It says why, and opens the repository's System map page.

• The two system map events appear in the bell only. They are never emailed.

• "Zof-written tests ready to add to a repository" goes to company admins when tests Zof wrote for a pull request pass and are ready to add. Zof sends it at most once per repository every 7 days.

• "Tips and guides" is email only, so it has a dash under In-app. It covers the setup reminders sent to company admins while a step is still open (connect GitHub, confirm what Zof found, send your first change), the "While you were away" summary after 14 days without signing in, and the five How Zof works emails. Zof sends at most one of these every 48 hours. Each one has an unsubscribe link. Tips and guides is one setting for all your companies: turning it off, by the link or in the settings of any company, turns it off for all of them. Welcome emails are always sent and have no setting.

• "Product news from Zof" is email only and off until you tick it. It is one choice for you, not for each company: turning it off, by the link in any product news email or in the settings, turns it off in every company you're in now or join later.

Pull request updates stay on GitHub.

Change what you get

1. At the top of the console, click the bell.
2. At the bottom of Notifications, click Notification settings.
3. For each event, turn Email and In-app on or off. A dash means that event has no email, or, under In-app, no bell item.
4. Click Save preferences.

You can also open Notification settings directly. Your settings are your own, and apply to the current company. Email and In-app work independently: you can receive an email without a bell item, or a bell item without an email. Reading a bell item does not cancel a queued email.

Check that it worked

1. After you save, the console says "Notification settings saved".
2. Reload Notification settings. Your ticks are still there.
3. New events put a dot on the bell; point at the bell to see how many are unread. Click the bell to read them, and Mark all read to clear them.

What emails contain

Emails never include code, diffs, run names or secrets. They link back to the console and carry an unsubscribe link. Noisy events are grouped, and a burst of failed runs is one email. Reading a bell item does not send another email for the same group. If email is temporarily unavailable, queued messages wait until it is available again.

Not supported yet