Rudderstack Release Notes

Features

• run python transformation tests on ephemeral per-request pyt deployments (#7177) (1008ae7)
• support partition migration job fanout per jobsdb (#7141) (be42e48)

Bug Fixes

• abort snowpipe events on channel bad request (#7118) (6c08584)
• avoid redundant transformer statTags unmarshalling (#7182) (c3c283c)
• classify reverse-ETL sources from config for MAR metering (#7159) (fa7870f)
• detect server-side snowpipe channel failures via per-channel status at stuck threshold (#7166) (581410c)
• kafkamanager compilation error (#7189) (1fb7f6e)
• kafka: support insecure TLS skip verify config (#7022) (d01574f)
• preserve order when overflowing snowpipe insert batches (#7178) (9c01fa0)
• quote postgres warehouse ddl identifiers (#7127) (5aeb481)
• router: emit invalid payload metric (#7168) (6e2009a)
• update null to #N/A for salesforce bulk upload (#7151) (1dffd93)
• warehouse: use pod identity for rudder-storage flow; keep S3-copy user fallback for user S3 destinations (#7167) (3f9aa32)

Miscellaneous

• add contract tests for test endpoints in pytransformer (#7147) (3b210ec)
• bump compose-test to v0.1.5 to remediate pgx CVE-2026-33815 (#7162) (7672f96)
• deps: bump actions/checkout from 6.0.3 to 7.0.0 (#7132) (d453c93)
• deps: bump actions/setup-go from 6.4.0 to 6.5.0 (#7150) (75d9648)
• deps: bump aws-actions/amazon-ecr-login from 2.1.5 to 2.1.6 (#7109) (7b2a859)
• deps: bump aws-actions/configure-aws-credentials from 6.2.0 to 6.2.2 (#7152) (c984268)
• deps: bump golangci/golangci-lint-action from 9.2.1 to 9.3.0 (#7170) (4565d25)
• deps: bump the frequent group across 1 directory with 4 updates (#6891) (88a0ddf)
• support compression in bqstream destinations (#7142) (0694f12)

Send RudderStack pipeline health alerts straight into PagerDuty and incident.io, so a failure pages your on-call instead of sitting unnoticed.

Available Plans

Growth
Enterprise

You can now deliver RudderStack’s Configurable Alerts directly into PagerDuty and incident.io — the two tools engineering teams use to run on-call and incident response — alongside the existing Slack, Microsoft Teams, email, and webhook channels. When a pipeline breaks, the alert lands where your on-call attention already lives instead of getting buried in a channel or inbox.

This adds two new delivery destinations for the alerts RudderStack already detects. It does not change what RudderStack monitors or how alert thresholds work — only where those alerts can be sent.

Not to be confused with the PagerDuty destination

This feature sends RudderStack’s operational health signals out to your incident tooling. It is different to the PagerDuty destination, which sends your event data into PagerDuty.

Why route alerts to your incident tools?

A broken pipeline is a business-critical failure, not a cosmetic one. It can silently drop or corrupt the data feeding your analytics, ML models, and downstream marketing and product decisions — and the damage is often invisible until someone notices the numbers are wrong days later.

The problem is that a Slack message or an email is easy to miss. A page is not.

• PagerDuty guarantees the right on-call human is actually notified — loudly, via phone, SMS, or push — and auto-escalates if nobody acknowledges.
• incident.io coordinates the response once people are aware, spinning up an incident channel, assigning roles, and auto-capturing a timeline that becomes the postmortem.

Meeting your team where its on-call attention already lives turns a RudderStack failure from a buried notification into a real page. For a platform whose promise is data reliability, that closes a direct trust gap.

What you can route

RudderStack’s existing alert engine already detects the failures that matter most (this set is unchanged):

• A destination starts rejecting or failing to receive events (bad credentials, downtime, network errors)
• A warehouse sync aborts, or pre-sync processing fails
• A transformation starts erroring and dropping events
• Event volume drops suspiciously versus the same hour last week
• A source violates its Tracking Plan (data arriving in the wrong shape)
• A Reverse ETL sync fails partially or fatally
• A Profiles run fails

Any of these can now land as a PagerDuty incident (with escalation policies, on-call schedules, and phone/SMS/push paging) or as an incident.io alert (which can trigger an incident channel, role assignment, and an auto-built postmortem timeline).

Key features

• PagerDuty routing with real paging and escalation: Route any RudderStack alert into a PagerDuty service so the right on-call engineer is paged and alerts auto-escalate if unacknowledged.
• incident.io routing with response coordination: Deliver alerts into incident.io to kick off an incident channel, assign roles, and capture a timeline for the postmortem.
• Setup in minutes: Configuration is minimal — for PagerDuty, create a service with an Events API v2 integration and paste the 32-character integration/routing key. For incident.io, create an HTTP alert source and paste the secret API key plus the (non-secret) alert source config ID.
• The same guardrails as every channel: Only org admins can configure workspace-level channels; alerts are de-duplicated (at most one notification per resource, per alert type, per channel every 24 hours, so on-call isn’t spammed); you can’t disable your last remaining production channel, so you’re never flying blind; and a test alert button confirms the wiring before you rely on it.

Get started

PagerDuty and incident.io alert channels are available on the RudderStack Growth and Enterprise plans and are configured at the workspace level from your RudderStack dashboard:

1. Go to Data Governance > Alerts in your RudderStack dashboard.
2. Choose the PagerDuty or incident.io channel.
3. For PagerDuty, paste your 32-character Events API v2 integration key. For incident.io, paste your HTTP alert source API key and alert source config ID.
4. Click the test alert button to confirm the connection, then save.

See the Configurable Alerts guide for full setup instructions for both channels.

For vendor-side context, see PagerDuty’s own Events API v2 documentation and incident.io’s Custom HTTP alert source documentation.

Questions? We're here to help.
Join the RudderStack Slack community or email us for support

Features

• add control-plane connection management for processor (#7126) (ea6ca00)
• carry integration version on DestinationT to the transformer (#7125) (421c613)
• implement Forward RPC for control-plane requests to workspace pyt transformers (#7143) (8a704cf)
• implement Kubernetes deployment scaler for workspace replica management (#7123) (84fc747)
• monthly active records (MAR) metering pipeline (#7119) (d1df486)

Bug Fixes

• router: transformer returning response with empty metadata array causes server to panic (#7144) (d6a4dbc)

Miscellaneous

• enable compression for google pubsub (#7137) (11c9ab8)

Features

• support compressing payloads in reporting client (#7124) (365b530)
• support deltalake azure hierarchical namespace folders (#7089) (61b41e4)

Bug Fixes

• jobsdb: compaction panics with pq error column js.consumer does not exist at position (#7133) (f392a53)
• panic in user transformer client due to timeout doesn't get recorded by alerts (#7116) (61b41e4)
• partition migration restarts server on slow in-progress wait (#7129) (d63d597)

Miscellaneous

• jobsdb: capturing multi-consumer pending events (#7121) (dc382f7)
• jobsdb: cleanup legacy configuration flags (#7122) (58778d5)
• jobsdb: multi-consumer compaction (#7096) (57f1ef5)
• jobsdb: multi-consumer get and noresults cache handling (#7095) (9d5c58a)
• jobsdb: multi-consumer get distinct consumers (#7097) (f68a56d)
• jobsdb: multi-consumer partition migration (#7098) (9cda68d)
• jobsdb: multi-consumer-specific indexes and views (#7093) (61b41e4)
• jobsdb: multiconsumer flip, registry table and unionjobsdb (#7094) (9eff2e9)
• jobsdb: new columns for multi-consumer jobsdb (#7082) (61b41e4)
• recreate stale rsources subscription on shared db (#7108) (c59e9e5)
• use priority pool at migration start while polling for pending jobs (#7128) (254ae15)

Features

• add and register bq stream v2 async destination manager (#7057) (787b7ac)
• add BQSTREAM_V2 destination type and bqstreamv2 building blocks (#7056) (02e84e5)
• batchrouter: raise getImportingJobs max iterations and remove payload size limit (#7076) (15707f6)
• gateway: throttling support for internal batch endpoint (#7055) (6b6ba65)
• jobsdb: introduce compaction min ds age (#7077) (4d6d97a)
• processor: new intermediate jobsdb (#7048) (dfef1f1)

Bug Fixes

• abort non-retryable Klaviyo upload errors instead of retrying (#7085) (4c3e4f1)
• batchrouter: correlate poll results by externalId instead of whole-row hash (09326d2)
• batchrouter: report real status code and sample event for drained jobs (#7104) (d3fab82)
• internal endpoints enabled in open source version of rudder-server (#7075) (dc071cd)
• jobsdb: get jobs lateral join against the v_last view (#7105) (853d14c)
• klaviyo upload partial failures (#7107) (37e79e9)
• router: shared barrier causing illegal job sequence errors (#7101) (b5435ba)

Miscellaneous

• add BQSTREAM_V2 integration tests (#7058) (478e217)
• add rudderai announcement (#7046) (ff02fe8)
• bump codecov-action to 7.0.0 (#7070) (31f0623)
• cleanup embedded warehouse transformations (#7072) (31f0623)
• deps: bump actions/checkout from 6.0.2 to 6.0.3 (#7084) (745d5ab)
• deps: bump aws-actions/configure-aws-credentials from 6.1.2 to 6.2.0 (#7081) (19251cd)
• jobsdb: refactoring and cleanup (#7043) (2e4ea92)
• remove legacy warehouse endpoints (#7090) (6f85153)
• rename bqstream all events (#7088) (4d9ad19)
• router: rename experimental buffer size calculator to dynamic (#7103) (52896cd)
• support using the full event schema key as pulsar ordering key (#7086) (ff50611)

Capture leads from Facebook and Instagram Instant Forms directly in RudderStack — no third-party middleware, with full control over your lead PII.

RudderStack now supports Facebook Lead Ads as a native source. When someone fills out an Instant Form on Facebook or Instagram, their lead data flows directly into RudderStack — no LeadsBridge, no Zapier, no middleware in your data path. Leads arrive as standard identify events, ready to route to your CRM, data warehouse, marketing automation, and 200+ other destinations.

This OAuth-based source replaces the deprecated webhook-based Facebook Lead Ads integration, bringing the connection fully in-house with enterprise-grade reliability, observability, and regional compliance.

See the Facebook Lead Ads Source documentation for full details.

Why a native Facebook Lead Ads source?

Until now, getting Facebook leads into your stack meant a compromise. Manual CSV downloads from Ads Manager are slow and let leads go cold. Third-party middleware like LeadsBridge or Zapier is faster, but it routes your lead PII — names, emails, phone numbers — through a system you don’t control, which is a non-starter for teams with strict compliance requirements. Building your own integration is expensive and breaks every time Facebook’s API changes.

Facebook’s webhook design makes this genuinely hard to do well: the webhook only delivers a lead_id (not the lead itself), and Facebook requires acknowledgment within five seconds. RudderStack handles that two-step fetch internally — acknowledging the webhook immediately, then calling Facebook’s API to retrieve the full lead. So the complexity stays on our side. The result is a direct, first-party connection from Facebook to your infrastructure, with the retry logic, observability, and security controls you’d expect from the rest of your RudderStack pipeline.

Key features

• Direct, first-party connection: Leads flow from Facebook to your destinations without any third party touching your PII.
• OAuth-based setup: Authenticate with your Facebook business account and select a page — no manual webhook URL configuration.
• Reusable accounts across sources: Grant one OAuth account access to all your Facebook pages, then reuse it across multiple Facebook Lead Ads sources.
• Standard identify events: Each leadgen event arrives as a normal RudderStack identify event, enriched with page ID, form ID, and all custom form fields — ready for any of 200+ destinations.
• Built-in deduplication: Facebook’s at-least-once delivery can resend the same lead, but RudderStack deduplicates on messageId so destinations never receive duplicates.
• Regional compliance: US and EU CRM applications ensure your lead data is processed in the appropriate region based on your workspace.

Get started

1. In your RudderStack dashboard, click Add Source and select Facebook Lead Ads.
2. Name the source, then under Account click Create account, choose OAuth, and authorize RudderStack to access your Facebook business account.
3. Select the Facebook page you want to receive lead events from. Each source ingests events from one page.
4. Connect a destination to start routing leads from your Facebook Lead Ads campaign.

See the Facebook Lead Ads Source documentation for detailed setup instructions and the full list of required OAuth permissions.

Resources

See the following guides for detailed instructions on using this feature:

• Facebook Lead Ads Source
• Setup and OAuth permissions
• Event structure
• Live Events

Screenshots

1. Search for the Facebook Lead Ads source
2. Name the source and select or create an account to connect
3. Select the business page you want to connect to

Questions? We're here to help.

Join the RudderStack Slack community or email us for support

Generate type-safe client bindings for TypeScript, Swift, and Kotlin directly from your Tracking Plans using Rudder CLI.

Available Plans

Starter

Growth

Enterprise

This feature is in Public Beta as part of RudderStack’s Early Access Program, where we work with early users and customers to test new features and get feedback before making them generally available.

We are introducing RudderTyper 2.0, which generates type-safe client bindings from your Tracking Plans for modern SDK languages — TypeScript, Swift, and Kotlin. By generating native code that matches your Tracking Plan’s event definitions, you can catch instrumentation errors at compile time rather than runtime, with full IntelliSense support in your IDE.

RudderTyper 2.0 is packaged into Rudder CLI, which already works with the Tracking Plans and Data Catalog you maintain as code in your Git repositories. This lets you generate and update your typed bindings as part of the same workflow you already use to manage your tracking plans, keeping your instrumentation in sync with your governance definitions.

What’s new

• Modern SDK language support: Generate strongly-typed bindings for TypeScript, Swift (iOS), and Kotlin (Android and JVM) that match your Tracking Plan’s event structure.
• Compile-time type safety: Validation ensures your tracking code matches your Tracking Plan definitions before your application ships, with autocomplete and type checking in your IDE.
• Packaged into Rudder CLI: Generate bindings directly from your Tracking Plans using the same CLI that manages your Data Catalog as code.
• Git-native workflow: Works with the Tracking Plans and Data Catalog you already maintain as code in your repositories, so generated bindings stay version-controlled alongside the rest of your instrumentation.
• Standard event coverage: Supports all standard RudderStack event types—track, identify, screen, and group.

Get started

Guide Description
RudderTyper v2 Overview of RudderTyper 2.0, its features, and limitations
RudderTyper v2 Walkthrough Guide Step-by-step tutorial to generate and use type-safe bindings in your application
RudderTyper v2 Command Reference Complete reference for RudderTyper v2 CLI commands and parameters

Questions? We're here to help.

Join the RudderStack Slack community or email us for support