Health digest

Sigil is invisible when it works, which is the point of the product and also a problem. An administrator who never opens the portal has no way of knowing whether 100% or 60% of their mailboxes are actually getting a signature.

The health digest is the answer. It takes what the portal already holds and mails it to your administrators, so the numbers arrive without anyone going to look for them.

What it contains

Section	What it says
Coverage	What share of your mailboxes have ever applied a signature successfully, and up to five that never have
Apply failures	How many attempts Outlook did not accept, across the organisation
Directory gaps	Attributes your default new-message and reply templates reference that a meaningful share of mailboxes do not have
Banners closing	Any campaign banner whose window ends within a week, unless it is paused
Waiting on approval	Drafts submitted for review and not yet decided
Published this week	Every template published in the last seven days, with the date and who published it
Booked publishes	Any scheduled publish not yet fired
Running rollouts	Any staged rollout in flight, and what percentage it is at

Empty sections are left out rather than printed as zeroes.

Two sections do not follow the digest’s own schedule. Apply failures are counted since your organisation started using Sigil, not since the last digest, so once any attempt has failed, that section and the attention-needed subject line appear in every digest. Published this week always covers the last seven days, even on a monthly digest, so earlier publishes in the month are in the change log instead.

Pictures of what was published

With signature previews, each line under Published this week carries a picture of the signature that went live, so the digest answers what changed rather than only that something did.

At most four pictures ride in one digest, and a large one is left out, so the mail stays something an inbox will accept. A version published before previews existed, or one the nightly sweep has not reached yet, is listed without a picture rather than held back.

Who published it is named rather than addressed: the digest prints the person’s name where Sigil knows it, and falls back to the address it holds otherwise.

While delivery is paused

If delivery is paused, the digest says so before anything else, and the subject line leads with it rather than with a coverage figure. Every number below that line means something different when nobody is being served, and an administrator who reads the coverage first has already been misled by the time they reach the explanation.

The list of mailboxes that have never had a signature applied is left out for the same reason. Under a pause it is the whole organisation, and it describes a decision an administrator made rather than anything to fix.

Everything else still appears, and still counts as needing attention: a failing apply, a banner about to close and a draft waiting on an approver are all things worth fixing before delivery resumes, which is exactly when a pause is in force.

Mailboxes you have excluded from Sigil are left out of the coverage and directory gap figures entirely. They are deliberately not being sent a signature, and a recurring email that chased your administrators about them every week would be the fastest way to make the digest into something people filter away.

Directory gaps are scoped to what you actually use

The gaps section does not report on every attribute a template could reference. It reports on the ones your organisation’s default new-message and reply templates actually depend on, including the fields that only appear as conditions on a section. A template that only reaches people through an assignment rule is not checked.

That is the difference between a useful line and noise. Nobody needs telling that extensionAttribute12 is unpopulated if no template mentions it.

An attribute has to be missing on at least 10% of mailboxes before it is mentioned. Below that it is ordinary sparseness, and a handful of people without a mobile number is not something worth mailing anybody about.

The digest currently gets the manager fields wrong. It reads your directory without looking up each person’s manager, so if a default template uses managerName, managerEmail or another manager field, the digest reports that field as missing for everybody. Run Attribute coverage for the real figure: it does look managers up.

Only real directory attributes are checked. A mistyped placeholder, a derived helper such as anyPhone, and a field Sigil supplies itself such as contactCardUrl are not reported.

Attribute coverage in the portal is the fuller version of the same audit, and the place to go once the digest has told you there is something to look at.

A healthy week still gets a digest

The digest reports rather than alerts. An organisation with nothing wrong gets a short one, with a subject line saying so.

This is deliberate. A message that only arrives when something is broken is an alert, and alerts do not tell you the product is working. “You are at 98%, nothing to do” is the message that makes the coverage number visible.

The subject line leads with the number that matters, so the digest is useful from the inbox list without being opened.

A running rollout and a booked publish appear in the digest but do not make it an attention-needed one. They are things you set up on purpose.

Seeing one before it arrives

You do not have to wait a week to find out what the digest says, or whether it sends at all.

Button	What it does
Preview	Renders the digest your organisation would get right now, in the page. Nothing is sent
Send me one	Mails it to you alone, so you can see it land in a real inbox

Both live in settings, next to the frequency.

Neither moves the schedule. Previewing or testing today does not delay the real digest, so there is no cost to pressing either.

Send me one goes to you and to nobody else. It is there to prove the delivery path works, and a test that mailed every administrator is a test nobody would run.

The preview is the same digest the scheduled send would produce, built by the same code rather than a separate rendering of it. A preview that showed something subtly different to the real thing would be worse than no preview, because it would be believed.

If your organisation is too new to be sent one, the preview still renders and tells you it would be held back. See below for when that applies.

Previewing or sending a test

You need the Admin role, a custom role given Settings, or a partner Owner or Admin role inside a managed client.

1. Open Settings in the portal sidebar, under Organisation.
2. On the Health digest card, choose Preview. The subject line and the rendered digest appear beneath the frequency options.
3. Choose Hide preview to close it.
4. To see it in an inbox, choose Send me one.

A message confirms the address it was sent to and that this does not change when the next one goes out.

How often it arrives

Setting	Behaviour
Weekly	The default
Monthly	One every 30 days, for organisations where weekly is more than they want
Off	No digest at all

Change it in settings. Every digest carries a link to that page, so turning it down or off never means hunting for the switch.

It defaults to on because a digest nobody discovers is a digest nobody reads. It is a service email about your own organisation, with an off switch linked from every send.

Changing the frequency or switching it off

You need the Admin role, a custom role given Settings, or a partner Owner or Admin role inside a managed client.

1. Open Settings in the portal sidebar, under Organisation.
2. On the Health digest card, choose Weekly, Monthly or Off.

The choice saves as soon as you make it and a message confirms it. The card also shows when the last digest was sent. Switching it back on later is the same choice in reverse.

Who receives it

Every administrator of the organisation.

There is no separate recipient list. The digest goes to everyone who holds the Admin role, so to change who receives it, change who is an admin in Users & roles.

An organisation with no administrators yet, which happens partway through onboarding, is not sent one and is not marked as having received one. It gets its first digest once somebody is there to read it.

Partner staff never receive a client’s digest, because only the client’s own Admins are on the list. A managed client with no Admin of its own is not sent one. Partner staff can still use Preview or Send me one from the client’s Settings.

Organisations that are not being served are not sent digests either. That covers a suspension, a deletion grace window, and every billing reason signatures have stopped: a cancelled subscription, a trial that ended without a card, dunning that ran out, or a managed client whose provider’s own subscription has lapsed. None of them wants a weekly report about signatures nobody is receiving.

A cancellation that has only been scheduled is not one of those. Signatures are still going out until the day it takes effect, so the digest carries on until then and stops with them.

When it does not arrive

A brand new organisation with no directory read and no activity at all is skipped for that period and looked at again at the next one. A mail full of zeroes reads like a fault.

If the directory could not be read on the day a digest was built, the digest is still sent, and says the directory could not be read. It leaves out the coverage figure, the list of mailboxes that never applied a signature and the directory gaps, rather than reporting 0%, which would be alarming and wrong.

Every organisation due a digest is sent one on the same run. Sigil used to work through the list in batches, so a busy day could push a digest to the following morning; it no longer does, and no organisation waits its turn behind another.

Each organisation is sent at most one digest per period, even if the run that sends it is retried. Between the end of September and 3 October 2026, while organisations were being moved onto their own databases, some were sent a digest every morning whatever their frequency, including organisations that had switched it off. That was a fault and is fixed; your saved choice was kept throughout and applies again without you changing anything.

A digest is not sent to an organisation whose signatures have stopped, whether that is a suspension, a pending deletion or a billing reason. The test is the same one the signature path applies, so the digest stops when the signatures do rather than on a rule of its own.

Where the numbers come from

Coverage counts a mailbox as covered once the add-in has reported applying a signature successfully at least once. That is evidence Outlook actually took the signature, rather than evidence Sigil served one, and the two are not the same thing.

The same telemetry drives the activity view, which is where to go for per-mailbox detail. The digest is a summary of it, not a separate measurement.

What it is not

It is not an alerting system. There is no threshold you can set, nothing pages anybody, and a digest is not sent early because something broke.

If a signature stopped working an hour ago, the digest is the wrong tool. Open activity.