Nova v2.6: Identity, Delivery, and Session Reliability
LinkedIn OAuth, multi-channel alert fan-out, scheduled incident comms, and sessions that survive server restarts. The plumbing release that makes everything else in the platform feel solid.
LinkedIn OAuth
v2.6 ships LinkedIn as a first-class identity provider for the comms broadcast feature, joining X, Threads, Slack, and Microsoft Teams. The OAuth flow is the standard authorization-code-with-PKCE; tokens are stored encrypted at rest with the per-tenant KMS key, and refresh tokens rotate automatically every 60 days.
The reason LinkedIn took longer than the other providers is that LinkedIn's API surface for org-level posting changed twice in 2025. We needed both the personal-account scopes and the organisation-account scopes; the latter requires a partnership-program review that took most of December. As of v2.6 it's live for everyone.
What this enables: when you broadcast an incident update from Nova, your organisation's LinkedIn page can post the executive-summary version automatically, same as it already does for the X account and the public status page. Useful for B2B teams whose customers actually live on LinkedIn.
Multi-channel alert fan-out
Every alert in Nova now has a configurable fan-out policy. A single alert can route to multiple destinations with channel-specific transformations, Slack gets the rich-block format with the runbook link, PagerDuty gets the structured event payload, the team-specific email distribution gets the long-form summary, and the team's Microsoft Teams channel gets the digest.
The implementation is a small DSL, each fan-out target is a tuple of (channel, transformer, throttle). The transformer is a small function that takes the alert object and returns the channel payload. Throttles are configurable per channel, Slack gets every alert, PagerDuty gets only the P1s, the email digest gets a 5-minute window of grouped alerts.
The DSL is small enough that we ship a UI editor for it (no YAML). Drag a target onto the alert routing canvas, pick a transformer from a dropdown, set the throttle. Most teams configure their first set of fan-outs in 10 minutes during onboarding.
Scheduled incident comms
During a long-running incident, the comms cadence matters. Customers expect updates every 30 minutes during a P1, every hour during a P2. Forgetting an update is a credibility hit. Sending too many is noise.
v2.6 introduces scheduled comms, set a cadence on the incident ("every 30 minutes until resolved"), and Nova prompts the on-call commander 5 minutes before each scheduled update is due. The prompt is a Slack DM with a draft based on the latest incident state, ready to edit and broadcast. If the commander doesn't respond within 3 minutes of the scheduled time, the prompt escalates to the secondary on-call.
The cadence pauses automatically when the incident is mitigated, resumes if mitigation rolls back, and finalises at incident close with a "Resolved" broadcast. The pattern is borrowed from how the best incident commanders we've worked with operate manually; we just made it default.
Sessions that survive restarts
This one is unglamorous and was the most-requested fix in our 2025 customer survey. Before v2.6, deploying a new version of the Nova control plane would invalidate every active user session. On-call engineers got logged out mid-incident. Browser tabs lost state. Nobody died, but it added 30 seconds of friction to a moment when 30 seconds matters.
The root cause was that session state was stored in the application server's memory. A restart wiped the state. Trivial in theory, embarrassing in practice. The fix is a Postgres-backed session store with a thin in-memory cache for the hot path; sessions persist across restarts and are validated on every request.
The performance impact is negligible, session validation now hits Postgres on cache miss, but the cache hit rate is 99.4% in production, and Postgres p95 read latency is sub-millisecond on the session table. The cold-start path is one extra round-trip; the hot path is unchanged.
For the multi-tenant deployment we run, this also unblocks horizontal scaling of the API tier, sessions are no longer pinned to the server that issued them, so any pod can serve any request. Rolling deploys now happen invisibly to active users.
Why this release matters
v2.6 doesn't have a headline feature. It's the release where four annoying-but-unimportant edges got smoothed: a missing identity provider, alert routing that needed manual scripting, comms that needed manual reminders, sessions that broke during deploys. Each one was a paper-cut; together they were the difference between "this product is great" and "this product is great and nothing about it bothers me anymore."
That's the kind of release we do every six weeks alongside the bigger features. The big features ship the headlines; the plumbing releases ship the polish. Both are necessary; we just don't always blog them. v2.6 was the one where there was enough of substance worth writing up.
All four features are live in production for all tenants today. No setup; no migration. If you're using Nova, you're using them already.