Rudderstack Release Notes

Features

• backend config v2 resolver with stub mapper (#7275) (267b973)
• warehouse: clickhouse v2 connection and schema (#7301) (2eb1fa6)
• warehouse: clickhouse v2 ddl operations (#7302) (f2887c5)
• warehouse: clickhouse v2 loading (#7303) (3e48618)
• warehouse: enable the clickhouse v2 driver behind a flag (#7311) (3ce1da5)

Bug Fixes

• race conditions while counting initial pending events can cause wrong counting (#7292) (3efa718)
• replay destinations not using the config corresponding to their connected source type (#7307) (ee7aa93)
• router: abort router-transform on proactive invalid_grant instead of retrying (INT-6779) (#7175) (4d7348d)
• tracking plan merged config is cached without its event type (#7314) (624dd5c)

Miscellaneous

• setattr/delattr hardening (#7291) (2855af4)
• sync release v1.84.0 to main branch (#7306) (fa102b7)
• webhook reasons (#7294) (c298d59)

Original source

A redesigned Transformations experience with a more flexible testing suite and full version control for transformations and libraries.

Transformations is one of the most widely used features on the platform, and it just got a major upgrade. Transformations v2 is now in public beta, with a completely revamped UI/UX plus two significant new capabilities: a more flexible testing suite and full versioning and deployment control — for both transformations and the libraries they import.

Transformations v2 is in public beta.

See the following guides for more details:

• Test Transformations - Version and Deploy Transformations
• Version and Publish Libraries

Why upgrade Transformations?

Transformations sits in the critical path of your event pipeline, so its popularity raised the bar for what this update needed to deliver — a visual refresh alone wouldn’t be enough for a feature this central to your data flow. We focused the rebuild on the UI/UX, keeping the parts of the workflow you already know while redefining the areas that needed it most: testing and change management.

Two gaps stood out. First, testing only ever validated a transformation in isolation — a change to a shared library could silently break every transformation that imported it, and you wouldn’t find out until events started failing downstream. Second, there was no real change history: publishing was final, with no version trail and no way to recover from a bad deploy without manually redeploying old code.

Transformations v2 closes both gaps — and not just for the people writing transformation code by hand. As more of your transformation logic gets written and maintained by AI agents, the same guardrails that protect a human’s changes (draft before publish, tests validated before rollback, inferred library tests) are exactly what let an agent modify and deploy transformation logic safely on your behalf.

Updates and improvements

• Revamped UI/UX: A redesigned editor experience that’s familiar where it counts — writing and saving transformation code works the way you’d expect — and redefined where it matters most, with dedicated, purpose-built views for testing and version history.

New functionality

• A more flexible testing suite: Import a live event or a saved payload, edit it inline, and run it against your transformation. Compare Expected against Actual output in a line-by-line Diff view, inspect Logs from your code log() calls, and Approve a result to update the expected output, or Reject to keep the current expected payload.
• Inferred testing for libraries: Libraries don’t need their own test cases. Running a test on a library automatically replays every test case from every transformation that imports it, so a breaking library change surfaces immediately — before you publish it — instead of silently breaking transformations downstream.
• Transformation versioning and deployments: Save work-in-progress as a Draft without touching production. Publish a tagged version when you’re ready — it becomes Active immediately for connected destinations. Every publish is recorded in Version history with its code, tag, description, author, and timestamp.
• Validated rollback: Deploy an older transformation version back to Active status. Your test cases are validated against that version’s code first, so you know before you roll back whether it’s safe — and you can still deploy anyway if you choose to.
• Library versioning: Save drafts and publish tagged library versions the same way. One asymmetry to note: unlike transformations, you can’t deploy an older library version directly — publishing a new version is the only way to change what’s active.

Get started

1. Go to Collect > Transformations in the RudderStack dashboard and open (or create) a transformation.
2. In the Editor tab, write your code, then create a test case — import a live event or an existing payload — and click Run to validate it.
3. Click Save draft to store changes without affecting production, or Publish to tag and activate a new version.
4. Open the Versions tab to review version history, open an older version in the editor, or Deploy it back to Active.
5. Libraries follow the same Editor and Versions workflow. Publish a library version before importing it into a transformation — you can’t import a draft.

Resources

• Test Transformations: Create test cases, import event payloads, and use the diff view
• Version and Deploy Transformations: Save drafts, publish tagged versions, and roll back to an older version
• Transformation Libraries: Add libraries and use them in transformations
• Version and publish libraries: Draft, publish, and view library version history
• Test a library: How library tests are inferred from importing transformations

Screenshots

Diff view comparing expected and actual transformation output

Publishing a new transformation version

Transformation version history with the Active badge

Library version history with the Active badge

Questions? Let's figure it out together.

Join the RudderStack Slack community to connect with other users, customers, and the RudderStack team — or reach out for direct support.

Original source

Override workspace-level alert thresholds and delivery channels on individual sources, destinations, and transformations.

Available Plans

Growth

Enterprise

3 minute read

Date: Aug 26, 2026

RudderStack’s Configurable Alerts let you set failure thresholds and delivery channels for your whole workspace. But not every resource deserves the same treatment — a business-critical destination needs a tighter threshold than a low-priority one, and the team that owns a given pipeline may want its alerts in their own Slack channel.

You can now override workspace-level alert settings on individual resources — sources, destinations, and transformations. Set a custom threshold or route alerts to a different channel for one resource, while every other resource keeps inheriting your workspace defaults.

A resource inherits all workspace-level alert settings except the ones you explicitly override. If you override the threshold for one alert type on a source but leave another untouched, the second one keeps reflecting the workspace-level setting.

Why override alerts at the resource level?

Workspace-level alerts are a great baseline, but a single set of thresholds and channels can’t fit every pipeline in a growing workspace:

• Not every resource is equally critical. A destination feeding your revenue dashboard warrants a 0% failure threshold and an immediate page; a scratch destination used for testing does not. Resource-level overrides let you tune sensitivity per resource instead of picking one threshold for everything — so you reduce alert fatigue without missing failures on critical resources.
• Different teams own different pipelines. With channel overrides, a specific source’s alerts can go straight to the owning team’s Slack channel or on-call tool, while the rest of the workspace routes to your central channel.
• Defaults stay intact. Because overrides are scoped to a single resource, you can fine-tune the resources that need it without disturbing the settings protecting everything else.

When to use it: reach for resource-level overrides whenever a specific source, destination, or transformation needs a stricter (or looser) threshold than your workspace baseline, or when its alerts should be routed to a different team or channel than the rest of your pipelines.

Key features

• Custom thresholds per resource: Set a failure threshold for an individual source, destination, or transformation that differs from the workspace default — tighter for critical resources, looser for noisy or low-priority ones.
• Per-resource delivery channels: Route a specific resource’s alerts to its own channels (Slack, Microsoft Teams, PagerDuty, incident.io, email, or webhook), independent of your workspace-level channels. If no channel override is set, the resource falls back to the workspace channels — so alerts are never silently dropped.
• Selective overrides with inheritance: Override only the alert types that need it; everything else on the resource keeps inheriting the workspace settings.
• One-click reset: Revert any threshold or channel override back to the workspace default with the reset icon and a confirmation — no need to remember what the original value was.
• Workspace-level visibility: The Custom alerts setting under each failure type lists every resource with an override, its subscription status, and its custom threshold, so you always know what’s been customized and where.

Get started

Resource-level alert overrides are available on the RudderStack Growth and Enterprise plans. Configuring them requires admin access, or the Alert Overrides permission.

To set a custom threshold for a resource:

1. Go to the resource (source, destination, or transformation) and click the Alerts tab.
2. Adjust the threshold for any alert type. By default, the tab shows your workspace-level settings.
3. Click Create override in the confirmation dialog.

To route a resource’s alerts to different channels, open the same Alerts tab. Under the Channels section, click Setup next to the channel you want to configure. To undo any override, click the reset icon next to the custom setting and confirm.

See Resource-level alerts for full setup details, including the permissions required and the alert types applicable to each resource type.

Resources

• Configurable Alerts — workspace-level thresholds and delivery channels
• Resource-level alerts — thresholds, channel overrides, and resets
• Alert delivery channels — Slack, Microsoft Teams, PagerDuty, incident.io, webhook, and email

Questions? Let's figure it out together.

Join the RudderStack Slack community to connect with other users, customers, and the RudderStack team — or reach out for direct support.

Slack community Join now

Email support Reach out

Original source

Features

• add AGENTS.md for agent management and reference (#7290) (2d28b32)
• processor: report duplicate events as dedup/filtered metrics (#7280) (f2655fb)
• warehouse: add clickhouse driver interface (#7296) (239d9a4)

Bug Fixes

• processor: proc destination hydration omitted destination's original id (#7297) (f389df4)
• warehouse: close load file descriptor in identity uploadFile (#7186) (bfd8bc9)

Miscellaneous

• handle oversized reporting payloads (#7293) (7a83281)
• pyt security hardening (#7272) (e13b731)

Original source

RudderTyper v2 TypeScript bindings now send your Tracking Plan’s property names on the wire instead of camelCased ones.

Available Plans

Growth

Enterprise

3 minute read

Date: Aug 21, 2026

RudderTyper v2 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.

Rudder CLI v0.24.0 fixes the RudderTyper v2 TypeScript generator so that event property keys sent to RudderStack match the property names in your Tracking Plan.

Previously, the TypeScript generator camelCased property names for the generated interfaces, and those camelCased keys were also what your application sent. A plan defining product_id produced events carrying productId. Kotlin and Swift were never affected.

What changed

Generated TypeScript interfaces still use camelCase field names, so your existing code keeps compiling and needs no changes. What changed is the payload: RudderTyper now maps the keys back to your Tracking Plan’s names just before handing the event to the SDK.

// Your code, unchanged
typer.trackOrderCompleted({
  productId: "sku-1024"
});

// What RudderStack now receives
{
  "event": "Order Completed",
  "properties": {
    "product_id": "sku-1024"
  }
}

This applies to track, page, identify, and group, and holds at every level of the payload, including nested objects, arrays of objects, and properties typed as a custom type with variants.

Who is affected

Only TypeScript projects using RudderTyper v2 whose Tracking Plans define property names that aren’t already camelCase, such as snake_case or kebab-case.

If your plan’s property names are already camelCase, nothing changes for you.

Before you upgrade

This changes the property names in the events your application sends. Review the downstream effects before rolling out.

• Warehouse columns: events start landing in columns named after your Tracking Plan properties. Expect new columns alongside the existing camelCased ones, and plan for how you want to reconcile historical data.
• Downstream destinations: any destination mapping, transformation, or dashboard that referenced the camelCased property names needs updating to the Tracking Plan names.
• Identity stitching: if any of the affected properties feed Profiles identity stitching, confirm the stitching keys still resolve after the change.
• Remove any key-renaming workaround: if you worked around this by intercepting track and renaming keys before sending, remove it in the same change as the upgrade. RudderTyper now does that mapping itself, so leaving the workaround in place renames the keys twice and puts camelCase back on the wire.

Your events also stop violating your Tracking Plan, which may change the volume of violations reported for the affected sources.

Get started

Upgrade Rudder CLI to v0.24.0 or later and regenerate your bindings:

rudder-cli typer generate --tracking-plan-id <your-plan-id> --platform typescript

Guide Description RudderTyper v2 Overview of RudderTyper v2, its features, and limitations RudderTyper v2 Command Reference Naming conventions, platform options, and command parameters RudderTyper v2 Walkthrough Guide Step-by-step tutorial to generate and use type-safe bindings

Questions? Let's figure it out together.

Join the RudderStack Slack community to connect with other users, customers, and the RudderStack team — or reach out for direct support.

Slack community Join now

Email support Reach out

Original source

Features

• add OriginalID and OriginalDestinationID to support replay event transformations (#7274) (28d38e9)
• bingads integration tests (#7253) (fdb8c0a)
• processor: fork event processing for rsources pipelines (#7235) (707ea06)

Bug Fixes

• pyt contract tests data race (#7247) (9e62d0c)

Miscellaneous

• bump sqlconnect-go to v1.30.2 (#7251) (f5d6175)
• jobsdb: multi-consumer compaction improvements (#7248) (b4af86c)
• pyt contract tests for candidate releases (#7252) (149e91a)
• pyt contract tests for transformations auth (#7239) (ac4a859)
• router: support per-partition noOfWorkers override (#7270) (9d6f7cf)
• sync release v1.82.0 to main branch (#7243) (a6e29f2)

Original source

Secure your RudderStack account with an authenticator app, and require multi-factor authentication across your organization.

Available Plans

Free

Growth

Enterprise

3 minute read

Date: Aug 5, 2026

You can now secure your RudderStack account with an authenticator app. Scan a QR code with Google Authenticator, Microsoft Authenticator, 1Password, Authy, or any other authenticator app, and RudderStack asks for a six-digit code from that app when you sign in. You also get a set of single-use backup codes so you can still get in if you lose your device.

Org Admins can go a step further and require Multi-Factor Authentication (MFA) for everyone in the organization, with a seven-day grace period so no one is locked out without warning.

See the Security Settings guide for full details.

Why authenticator app support?

Until now, SMS was the only second factor available on RudderStack. That works, but it has real limits. Text messages don’t arrive reliably everywhere — international users, roaming, and patchy coverage all cause delays or failures, which turns a security feature into a login blocker. SMS is also the weakest of the common second factors, since a phone number can be hijacked through a SIM-swap attack. Many security teams now require an app-based factor and won’t accept SMS.

Authenticator apps solve both problems. Codes are generated on your device, so nothing has to be delivered over a phone network, and there’s no phone number for an attacker to take over. It’s also what most security teams and questionnaires expect to see.

Key features

• Authenticator app (TOTP) setup: Scan a QR code — or enter the key manually — and confirm one code to turn it on. Works with any standard authenticator app.
• Backup codes: You get 10 single-use codes when you set up your second factor. They’re your recovery path if you lose your phone, and you can regenerate them if you run low.
• Your codes stay protected: The secret that generates your codes is held in a dedicated, hardened secrets vault — never in the RudderStack application database.
• Require MFA across your organization: Org Admins can turn on the Require 2FA toggle to mandate MFA for all members. Members who don’t have it yet get a seven-day grace period and an email with their deadline.
• Choose your own method: Each user picks their own second factor. If you have both an authenticator app and SMS set up, RudderStack asks for the authenticator app code first — it’s the more secure option — and doesn’t send a text unless you choose Verify with SMS instead.
• Audit visibility for admins: MFA setup, sign-in attempts, and backup code use are recorded in your organization’s audit logs, and admins can export a per-member MFA status report for security reviews and compliance evidence.

If your organization signs in through SSO, RudderStack defers to your identity provider — enforce MFA in Okta, Azure AD, or your IdP of choice and RudderStack honors it, so your users aren’t asked for a second code on top.

Get started

1. Go to Settings > Your Profile > Security in the RudderStack dashboard.
2. Click Set up next to Authenticator app.
3. Scan the QR code with your authenticator app, then enter the generated code and click Save.
4. Save the backup codes you’re shown, then click I’ve saved my codes. You’ll be signed out and asked to sign in again with your new second factor.

Org Admins who want to require MFA for the whole organization can use the Require 2FA toggle in Organization settings.

Resources

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

• Security Settings: Set up an authenticator app or SMS, and regenerate backup codes
• Require 2FA toggle: Require MFA for all organization members
• Audit Logs: Review MFA-related activity across your organization
• Member Management: Roles and permissions, including who can change organization settings

Screenshots

• Security settings in the RudderStack dashboard
• Setting up an authenticator app
• Single-use backup codes shown after setup

Questions? Let's figure it out together.

Join the RudderStack Slack community to connect with other users, customers, and the RudderStack team — or reach out for direct support.

Slack community Join now

Email support Reach out

Original source

Features

• processor: fork event processing for configured isolated destinations (#7207) (6eb91b4)
• processor: isolated destination processing pipeline (#7202) (a684641)
• router: detect and classify transformer-proxy contract breaches (INT-6839) (#7184) (c7a15a8)
• router: gate 296 delivered-with-warning behind per-workspace rollout (#7217) (1d772a1)

Bug Fixes

• apply configured client QPS and Burst settings in restConfig (#7220) (762bc06)
• gcs manager allows non-service account credentials and warehouse ssl keys can escape their containing path (#7227) (3e126b2)
• mid-run pod deaths under concurrent test runs (#7212) (5279b64)
• normalize null BingAds offline conversion fields (#7236) (678f130)
• use correct JSON tag for adjustedConversionTime in bing-ads (#7204) (50df0f7)

Miscellaneous

• add new readme logo (#7200) (ab86afd)
• deps: bump the go-deps group across 1 directory with 32 updates (#7199) (0eaa833)
• jobsdb: graceful shutdown of addNewDSLoop and refreshDSListLoop (#7210) (78e104c)
• remove archiveInPreProcess processor toggle (#7205) (f471b1d)

Original source

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)

Original source

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

Original source