---
title: "MongoDB high availability, custom headers for project webhooks, MySQL PITR"
date: 2026-10-01T22:59:00.000Z
number: 0310
url: https://railway.com/changelog/2026-10-02-mongodb-high-availability
---

# MongoDB high availability, custom headers for project webhooks, MySQL PITR

This week, we’re helping your databases weather surprises and your webhooks arrive with everything they need.

MongoDB high availability arrives in Priority Boarding, project webhooks gain custom headers, and MySQL point-in-time recovery graduates to general availability.

Let’s get into it! 🚄

# MongoDB high availability

[Convert a MongoDB service to a high-availability cluster.](https://cms.railway.com/media/dbb16450-4085-40d9-8be5-33e9f64e053a-MongoDB-HA.mp4)

Your database could use some company. MongoDB high availability gives it a replica set that can elect a new primary if the current one goes down, as long as a majority of voting members remains available.

You can now try it in **Priority Boarding** for supported MongoDB 7 and 8 services. HAProxy gives your apps a stable connection endpoint and routes reconnecting clients to the new primary.

To get started, enable **HA for MongoDB** in [Priority Boarding](https://railway.com/account/feature-flags), then open **Database → Config → High Availability**. Choose the number of replicas and proxies, then click **Convert to HA**. Railway backs up your volume and stages the cluster. Review the changes, then click **Deploy**.

During conversion, Railway updates references to your MongoDB service’s variables within the project. Existing connections drop, and any hardcoded connection strings need the new endpoint.

Check out the [MongoDB HA docs](https://docs.railway.com/databases/mongo-ha) for setup and failover details, and share your feedback on [Central Station](https://station.railway.com/new?type=feedback).

# Custom headers for project webhooks

[Set a custom header when configuring webhooks for your project](https://cms.railway.com/media/ee55a3a2-9681-4e93-885f-9ac2d76f1c8c-custom-header-webhook.mp4)

Your deployments have news. Railway webhooks send deployment updates and service alerts to your tools, so you can trigger workflows, notify your team, and keep other systems in sync.

Now, those requests can carry the headers your tools expect. Add authorization tokens, API keys, and routing metadata directly in your project’s webhook settings, and Railway includes them with every delivery.

To configure them, enter header names and values under **Custom headers** in the webhook form, then click **Test Webhook** to send a test request with those headers. Once saved, header values are encrypted at rest and aren’t shown again in the form.

You can also create and update webhook headers through the Railway MCP server. Check out the [webhooks docs](https://docs.railway.com/observability/webhooks), and tell us what you connect on [Central Station](https://station.railway.com/new?type=feedback).

# MySQL point-in-time recovery

[Choose a timestamp and restore MySQL into a separate service.](https://cms.railway.com/media/7677ecc2-20c9-41d9-93e6-f0d2a794f472-mysql-PITR.mp4)

An accidental delete or a migration gone wrong can leave you wishing for an undo button. MySQL point-in-time recovery lets you restore your database to a timestamp before things went sideways.

That recovery option is now generally available for standalone MySQL services and MySQL HA clusters, following its debut in Priority Boarding.

To start building your recovery window, open your database’s **Backups** tab and click **Enable PITR**. Setup restarts standalone databases. For HA clusters, Railway restarts nodes one at a time, with a brief interruption during switchover. Your recovery window starts with the first full backup after enabling PITR.

With that history in place, choose a timestamp within the available window and click **Restore to this moment**. Railway creates a separate service, so you can inspect the recovered data while your original database keeps running.

For the full walkthrough, check out the [MySQL PITR guide](https://docs.railway.com/volumes/point-in-time-recovery). Share your experience on [Central Station](https://station.railway.com/new?type=feedback).

# Fixes and improvements

- We fixed an issue where `railway postgres pitr status` showed stale archive information after an HA failover. The command now checks the active primary, so old timestamps don’t make archiving look stalled. Included in [CLI v5.63.1](https://github.com/railwayapp/cli/releases/tag/v5.63.1).