Operations

This page covers the operational guarantees behind the work Fairmeter runs on your behalf: the daily jobs that produce audit rollups, the on-demand compliance packs you request separately, how the daily jobs behave when the service is restarted or redeployed underneath them, and how the platform’s dependency surface is kept current without changing behaviour you depend on.

The audience is whoever owns the Fairmeter relationship on your side and needs to answer questions about it, either for an internal review or for a security questionnaire.

Scheduled daily jobs

Several pieces of the platform run on a daily schedule rather than in the request path. The audit-chain rollup that seals each day’s tamper-evident log is the most visible of these.

The GDPR, SOC 2, and HIPAA compliance-export packs are not on this schedule. Each pack is composed and streamed back inside the request that asks for it, and the caller must hold the admin or owner role on the org. The SOC 2 and HIPAA packs additionally require an Enterprise entitlement. The GDPR subject-access pack does not, because a subject access request is a legal right rather than a plan feature. Every export is rate limited to five an hour, counted per caller per org rather than per org, so two admins on one org have two allowances. There is no daily run to check for these, because no scheduled job produces them.

Each scheduled job carries an exactly-once guarantee per UTC day. That guarantee holds across restarts and deploys, which is the case that actually matters: a naive scheduler that keeps its bookkeeping only in memory will re-fire a job that already ran when the process behind it is replaced mid-day, which in an audit context means duplicate sealed artefacts and duplicated per-org work. Fairmeter records each job’s last run in durable storage, so a process that comes up fresh reads what already happened rather than assuming nothing has.

The same record covers the narrower race where a restart lands inside a job’s own firing window. The replacement process sees that the run is already accounted for and stands down; the in-flight work finishes on its original path and is never duplicated. A job that fails is still marked as attempted for the day, so a persistently failing job degrades into a missing artefact you can see, rather than a retry storm you have to notice from the outside.

What you can verify

The last run of each scheduled job is recorded with its wall-clock timestamp, and a job whose last run is more than a day behind the current UTC date is the signal that something needs attention. Because that record is written whether the run succeeded or failed, it tells you the job was reached, not that it produced anything. For the audit chain specifically, the integrity badge on the audit surface is the stronger end-to-end check, because it verifies the sealed chain itself rather than merely reporting that the job fired.

Dependency currency

Fairmeter pins the versions of everything it runs on, and those pins are reconciled against what is actually deployed rather than being allowed to drift apart on paper. A version bump is not treated as routine where the package sits under something security-relevant or behaviour-defining.

Bumps touching the cryptographic surface, meaning password hashing, the audit chain’s HMAC computation, and key-vault encryption and decryption, must pass a parity check at the new version before the pin lands, so a library change cannot silently alter how existing stored material verifies. The PII redactor is not itself a dependency: it matches four regex patterns, for email addresses, phone numbers, Social Security numbers, and credit card numbers, with no external model behind it. A change to those patterns is checked against a fixed set of example strings for each type before it ships, so a pattern that quietly narrows what it matches shows up as a failing test rather than as redaction doing less without anyone noticing. Bumps to the terminal client’s rendering and command-parsing layers are checked against the CLI’s own surface for the same reason.

The practical commitment is that a dependency change that would alter observable behaviour has to be caught before it ships, not after, and that no pin advances on the strength of a passing install alone.