Infrastructure

Sigil runs on Cloudflare’s edge network. The signature path executes close to whoever is composing the message.

Components

Component	Used for
Cloudflare edge compute	The API, the admin portal and the redirect service
Cloudflare D1	Templates, configuration, telemetry and billing state
Cloudflare R2	Uploaded images
Cloudflare KV	Rendered signature cache and per-mailbox rule resolution
Cloudflare Email	Invitations, test emails, operator notices and internal alerts
Stripe	Subscriptions, payment methods and invoices
Microsoft Entra ID	Authentication for both the add-in and the portal
Microsoft Graph	Read-only directory attributes for personalisation

Hostnames

Host	Serves
portal.usesigil.app	Admin portal, designer, and the signature API
static.usesigil.app	The add-in bundle and its manifest
e-clk.usesigil.app	Tracked link redirects only

The add-in is served from a different hostname to the API on purpose. That hostname is baked into the Entra broker redirect URI and into every URL in the add-in manifest, which is part of why a hostname change requires a manifest redeploy and fresh admin consent.

The link domain answers /r/ redirects and returns 404 for everything else, so the surface that recipients touch carries no portal or API.

Code loaded from other hosts

The components above are the services Sigil runs on. One further host is reached by the Outlook client rather than by Sigil’s servers, and it is worth stating plainly because it is the only code inside your users’ Outlook that Sigil did not write.

Host	What it serves	Reached by
appsforoffice.microsoft.com	Office.js	The add-in, on every path

Office.js is not optional and not a choice Sigil made. Microsoft requires every Office add-in to load it from that host, and an add-in that bundled its own copy would not run.

There is no second entry, and that is deliberate. The icons in the “My signature” pane were once drawn by a script fetched from unpkg.com, which put a third party in a position to run code in the origin that holds the sign-in client and the Office.js bridge, in order to draw seven glyphs. Those glyphs are now shape data inside the add-in’s own bundle, so the pane loads no script but Microsoft’s. A check on every build fails the release if a third-party script reference reappears on either add-in page, which is what keeps this a property of the add-in rather than a fact that happens to be true today.

The typefaces the pane and the admin portal are set in are deliberately not on this list either. They are served from Sigil’s own hosts rather than from Google Fonts, so opening the pane or the portal discloses nothing to a font provider, not even an IP address.

Microsoft is sent nothing of yours. The host answers a request for a script, and what it learns is what any web request discloses: the address it came from and the page that made it. Signature content, directory attributes and tokens never travel to it.

The network view of the same list, written for an administrator configuring an outbound filter, is on requirements.

Caching

Rendered signatures are cached in KV, keyed by template id, template version and email address. The banner and footer in force are part of that key, and so is a counter that moves whenever an image is uploaded or replaced, which is what keeps a swapped logo instant now that the cached entry holds the image bytes alongside the HTML.

Publishing a template increments its version, which strands every cached entry for it at once. That is why edits reach users in seconds without an explicit purge.

A one hour freshness window sits on top of that, which is how a change to somebody’s job title in Entra reaches Outlook without anyone republishing: a cached entry older than the window still serves that compose, then re-renders in the background from a fresh directory read, so the change lands on the compose after. The entry itself lives a day, which bounds how long any directory data exists inside Sigil at all: the attributes are read when a signature is rendered and are never stored as a record of their own, so a day after the last render there is nothing left of them.

The answer to a single directory lookup is held for fifteen minutes, so that a person composing several messages is not looked up in Graph each time. It sits inside the day above and changes nothing about how long directory data survives. A deprovisioned organisation has it cleared with everything else.

The routing decision behind assignment rules is cached separately, keyed by a rules version that changes whenever the rules are edited, so an edit strands every cached decision at once. A ten minute freshness window sits on those entries as well, after which the decision is re-checked against the directory in the background rather than while somebody is composing. That is what bounds how long a directory attribute can go on routing somebody to a template they should no longer be getting: ten minutes, and then one further message.

Reliability characteristics

Telemetry writes are best-effort and off the critical path. A storage problem loses a telemetry record rather than delaying or failing the signature somebody is waiting on.

The directory cross-reference in the Activity view is also best-effort. If Graph is briefly unavailable, the rest of the telemetry still renders.

The add-in’s outcome beacon is time-boxed and never holds a compose window open.

An interruption to Sigil affects signature management rather than mail flow. Sigil never gates the sending of email, so an outage costs you the portal and the application of signatures, not your users’ ability to send.

Availability commitment

There are two answers, depending on how you buy Sigil.

Bought directly, there is no contractual uptime figure. The terms of use aim at a reliable service without guaranteeing uninterrupted availability, and the support page states an aim of a response within one business day.

Bought through a managed service provider, the partner agreement commits to 99.9% monthly uptime with a service credit table behind it, and a four business hour response target on escalations. That commitment runs between Tophhie Cloud and the provider, so what reaches you is whatever your provider has agreed with you on the back of it. See support and service level.

Either way, the current state of the service is published on the status page.

The status page

status.usesigil.app is the public status page. It carries the current state of Sigil and any incident that is open, and it is where to look first when signatures have stopped across an organisation for no reason you can find.

It is hosted away from Sigil deliberately. A status page served by the thing it reports on is worth nothing during the one event it exists for, so the page is run by a third party on infrastructure Sigil does not share.

What sits behind it is an external monitor that renders a signature end to end from more than one region, every few minutes, and treats the result as a failure unless a valid signature came out. A check that only asked whether the service answered would report a service returning errors as healthy.

A failure has to be confirmed from a second region before an incident is opened, so one region’s network trouble is not reported as an outage of Sigil.

A second monitor checks that the platform underneath is answering at all. The two together are what separates a fault at Cloudflare from a fault in Sigil, which matters because the partner service level excludes the first and not the second.

The status pill in the portal

You do not have to go and look. Every page of the portal carries a status pill beside the page title, and the public support page carries the same one for somebody who cannot sign in. It reduces the state of Sigil to one of three answers and links to the full page.

The pill claims nothing it cannot stand behind. If the status page cannot be read, it shows no colour and no wording beyond “Service status”, because a pill saying all is well because it could not reach the status page would be worse than no pill at all.

Your browser never contacts the status host. The portal reads the page on your behalf and caches the answer for a minute, so however many people have the portal open it is one read, and no visitor of yours is disclosed to the company hosting the status page. The pill refreshes every five minutes while you leave the portal open.

Two things the page does not carry, deliberately. There is no historical uptime percentage on it, since a figure published before it has been measured for long enough invites more questions than it settles. And the heartbeats behind Sigil’s own overnight jobs are not on it either: whether a nightly rollup ran is an operational matter rather than something to report as an outage.

Health

portal.usesigil.app/health reports configuration and storage state. It is a service-level check rather than a per-tenant one.