Background jobs and the Inngest account (Admin > System health)

Signed in? Ask Lovelio this question inside the app - it answers from this same page.

Every background job in Lovelio (CV reads, job ad distribution, email sends, the AI batch tick, the daily sweeps) runs through Inngest. Each deployment (ANZ, EU, US and the website) is a "receiver": Inngest calls it back to run a function. A receiver only exists in an account after it has been synced, and it belongs to whichever account its signing key came from.

The Background jobs section of System health (/admin/health) asks Inngest directly, using the deployment's own signing key as the credential, and shows:

Inngest account: the name of the organisation the current signing key belongs to. It reads Lovelio (renamed from Silky on 2026-09-20).
Production keys per receiver: each deployment asks Inngest about its OWN two keys (signing and event), with no other deployment involved, and answers Yes, Wrong or Unknown. Yes means Inngest lists both keys in the Lovelio Production environment, or lists the signing key there and a test event sent with the event key arrived in that same environment. Wrong names that one Vercel project (the website's is lovelio-website2): its key is from another Inngest environment, from another organisation, or not a key at all. Fix only that project: in Inngest open the Production environment, Manage, Keys, paste the signing key into INNGEST_SIGNING_KEY and the event key named Lovelio into INNGEST_EVENT_KEY, redeploy it, then press Sync all four now. Never copy a key from another Vercel project. Unknown means the deployment could not prove it either way (it runs older code, or Inngest did not answer); it never raises an alert on its own. Hover the badge for the reason and each step's evidence. The hourly sync writes every receiver's answer into its heartbeat, and the alert names the project to fix. When the website's own keys are wrong, the other rows are not blamed for it.
One row per receiver: whether that account holds an app of that name, whether its last sync came from the URL we expect, how many functions it registered, and when.
Signing key and Event key per receiver: the short hash of each key that deployment holds. A row reading Wrong key holds a different signing key from the website and cannot prove its own is Production, so its syncs may land in an account the panel cannot see; fix that project's INNGEST_SIGNING_KEY in Vercel and redeploy it. A row reading Wrong keys failed its own Production check (above).
Runner key per region: the fingerprint of the event key the migration runner (the containers that fetch, load and enrich a client's data) sends with, and when it was last set. It must equal that region's Event key. The website keeps it that way by itself: every hourly sync, every press of "Sync all four now" and every enrich or batch launch writes the website's own key into the runner, but only when the website's key matches the one the region's app sends with, so a wrong key in the website can never overwrite a good one. A red Runner key that stays red means the website's INNGEST_EVENT_KEY in Vercel differs from the region's; fix that and redeploy, and the runner follows on the next sync. The hourly cron raises a critical alert while any region is out of line.
Fallback key, when one is set: which account the old key belongs to and how many of its runs are still in flight. That count reaching zero is what says the old apps may be archived.

The three verdicts

Healthy: all four receivers are registered with the Lovelio account. Nothing to do.
Cutover pending: all four are registered and working, but with an organisation not called Lovelio. Jobs run fine. This never raises an alert. It should not appear any more; if it does, the organisation was renamed or the keys point somewhere new.
Needs attention: at least one receiver is not registered with the account the current key belongs to, or Inngest rejected the key. This is the half-done state a cutover passes through and can get stuck in. The hourly sync cron raises a critical alert on it.

Sync all four now

Re-registers every receiver with its current account straight away instead of waiting for the hourly sync, and brings any out-of-date migration runner key into line. Press it the moment a redeploy that changed the Inngest keys is READY. It is safe to press at any time; a sync that changes nothing is a no-op.

A push that adds or changes a background job syncs itself: a GitHub Actions run (inngest-sync) waits for each deployment to be live on that push, then syncs it, so a new job is registered within a minute or two of going live rather than at the next hourly sync. It runs only for pushes that touch the jobs or the Inngest route, and shows red in the Actions tab if a deployment never reached the push within 15 minutes.

If the hourly sync stops

The sync runs on the website project. A separate hourly check on the regional projects (ANZ, EU, US) reads when it last ran and sends a critical alert once it has been quiet for three hours, then a reminder every six hours until it runs again. It lives on the regions so it keeps watching when the website project is the thing that stopped. The usual fix: in Vercel, check lovelio-website2's latest Production deployment is Ready and its Cron Jobs are enabled, then press Sync all four now.

Moving to a Lovelio-owned account

Keys belong to an Inngest ENVIRONMENT, not a region: all four Vercel projects must hold Production environment keys, which the Production keys column proves. A planned move to a separate organisation was found unnecessary on 2026-09-20 (the organisation only ever held Lovelio and was renamed). The procedure for a real move, if one is ever needed, is docs/runbooks/inngest-account-cutover.md. In one line: set the new keys plus the old signing key as INNGEST_SIGNING_KEY_FALLBACK on all four Vercel projects, redeploy, press Sync all four now, wait out the skew window while the fallback count drains to zero, archive the old apps, remove the fallback key.

Key values are never shown anywhere. The panel carries only the hash Inngest itself reports.