Building on Inngest — Background Job Infrastructure (v1.0.76)

One of the quiet but important milestones in any production platform is establishing the infrastructure for reliable background processing. In v1.0.76 we've done exactly that — bootstrapping Inngest as the event-driven background job engine for the entire platform.

Why Background Jobs Matter

A lot of what makes this platform valuable happens asynchronously. When a member logs a workout, several things need to happen that aren't part of the immediate HTTP response:

• Recalculate their performance score
• Check whether their readiness data from wearables indicates injury risk
• Fan out a social activity event to their coach's feed
• Evaluate churn signals for the gym owner dashboard

Handling these synchronously in an API route would be slow, fragile, and hard to debug. Offloading them to a durable background job system means they can be retried on failure, observed in a dedicated dashboard, and scaled independently.

What We've Built

This release is infrastructure — no visible user-facing changes, but it lays the foundation for a large portion of the platform's intelligence.

The Inngest client is initialised once and shared across the application. Any part of the codebase can call inngest.send(...) to emit an event, which Inngest will durably receive and route to the correct handler function.

The serve endpoint is a Next.js 15 API route that Inngest calls back into when it's time to execute a function. It handles secure request verification and step-based execution, which means long multi-step workflows can be broken into discrete, independently-retriable steps.

The event naming convention gives every event a predictable, discoverable name. We've settled on platform/<category>.<action> — so churn alerts live at platform/alerts.churn-risk-detected, wearable syncs at platform/sync.wearable-data-received, and so on. This makes the Inngest dashboard much easier to navigate as the number of event types grows.

Shared TypeScript types mean that every event payload is fully typed, both at the send site and in the handler. No more guessing what shape data is inside a function.

The Four Job Categories

The shared type definitions introduced in this release reflect the four primary areas of background work on the platform:

Category	What it covers
Scoring	Performance and progress score recalculation after workout logging or benchmark updates
Alerts	Churn risk and injury risk detection pipelines powering the owner and coach dashboards
Sync	Wearable data ingestion (HRV, sleep, readiness) and external service integrations
Social	Community fan-out — reactions, comments, activity feeds

What's Next

With the infrastructure in place, the next step is building out the actual Inngest functions in each category. The scoring pipeline, wearable sync handlers, and alert detection jobs will all be registered against this foundation.

For setup details including required environment variables, see the Inngest Background Job Infrastructure feature page.