PulseWatch 4.2: What is new
We'll walk through each of these properly below. There's a lot to cover.
Database syncing
This one has been a long time coming. Before 4.2, your PulseWatch data, monitors, incidents, uptime history, alert configurations, lived on whichever cluster you were connected to at that moment. If you were running multiple regions, or if a cluster had any kind of disruption, you had no guarantee that the state you saw was the state that actually existed. It made incident recovery harder. It made reporting unreliable. And honestly, it was something we knew we needed to fix properly.
Starting with 4.2, PulseWatch now syncs your data across the database layer continuously. Here's what that means in practice.
Real-time cross-cluster sync
Changes made in one region (new monitors, updated alert rules, incident status changes) propagate to all other regions automatically. You no longer need to duplicate configuration manually.
Unified uptime history
Your uptime records are now consolidated across clusters. Historical data from EU and US clusters is merged into a single continuous timeline per monitor, so your reporting finally reflects the full picture.
Failover data consistency
When a cluster goes down and traffic is rerouted, your data follows it. Whatever was happening on the primary cluster at the time of failover is preserved and visible on the fallback cluster immediately.
Conflict resolution built in
In the rare case where two clusters receive conflicting writes simultaneously, 4.2 uses a last-write-wins strategy with a full conflict log. Nothing is silently overwritten. You can review any resolution in your account history.
A note on rollout
Syncing is enabled automatically for all accounts from today. For accounts that have been running for a while, we performed a one-time backfill of historical data before the feature went live. You should already see your full history consolidated when you open your dashboard. If anything looks off, reach out and we'll take a look.
Security fix: admin Docker restart vulnerability
We found a security vulnerability in the Admin Docker restart feature, and we've patched it in 4.2. We want to be straightforward about what happened, what the risk was, and what we've done to fix it.
What was at risk
The Admin Docker restart feature lets administrators restart specific PulseWatch containers directly from the dashboard, useful for applying updates or recovering from stuck states. Because this endpoint interacts with the Docker socket, it carries elevated system-level permissions. An attacker who could trigger it without authorization could restart critical infrastructure components.
In practice, exploiting this required an active authenticated session, knowledge of the endpoint structure, and intentional crafting of the request. It was not something that could be triggered accidentally or by a passive actor. But the exposure was real, and it was serious enough that we treated it as a priority fix.
What we fixed
- Security Server-side role validation for the Docker restart endpoint now runs at the middleware level, before the request reaches any handler. The check cannot be bypassed by modifying request parameters.
- Security We now log all calls to the Docker restart API, regardless of whether they succeed or fail. Failed unauthorized attempts are flagged separately for review.
- Fix The role check is now consistent between the UI and the API. Previously, the frontend relied on user role state to hide the button, but the backend check was applied conditionally. Both layers now enforce the same rule independently.
- Improvement Admins will now receive a notification when any Docker restart is triggered, including who initiated it and which container was targeted. This gives you real-time visibility on the highest-privilege actions in the system.
Full account control
The third pillar of 4.2 is something we've been building toward for a few releases. Account control in PulseWatch was functional but incomplete. There were things you should have been able to do from your account that required you to contact us, or that simply weren't possible at all. That changes with this release.
Full account control means you now own every part of your workspace. Here's what's new.
Delete accounts
You can now delete your account, or any sub-account under your workspace, directly from settings. We'll ask you to confirm and give you a 7-day grace period during which you can cancel the deletion. After that, everything is removed permanently and securely.
Change password
Update your password at any time from the Account Security settings page. The new flow enforces strength requirements, invalidates all existing sessions on change, and sends a confirmation email so you're always aware when your credentials are updated.
Complete backend rewrite
We've rebuilt the entire backend from the ground up. Response times are much faster across the board, the API is more consistent, and the foundation is now solid enough to support everything we're planning next. You shouldn't need to change anything. It just works better.
Better UI
Alongside the backend rewrite, we've overhauled the interface. Navigation is cleaner, the settings pages are reorganised into logical groups, and the dashboard loads faster. We touched every screen. Small improvements everywhere add up to a noticeably better experience.
Why this took a while
A full backend rewrite is not something you rush. We ran the new and old systems in parallel for several months, validating correctness and performance at every step. Account deletion and password management in particular went through multiple internal security reviews. These features touch sensitive data and had to be right before we shipped them.
Full change log
Everything that shipped in 4.2, listed out:
- New Real-time database syncing across all clusters with automatic conflict resolution.
- New Unified uptime history: cross-cluster data merged into a single timeline per monitor.
- New Failover data consistency: state from the primary cluster is preserved and visible on fallback clusters immediately.
- Security Patched privilege escalation vulnerability in the Admin Docker restart API endpoint.
- Security Docker restart actions are now fully logged, including failed unauthorized attempts.
- Fix Role enforcement for Docker restart is now consistent between UI and API. Backend no longer relies on frontend state.
- Improvement Admins receive real-time notifications for any Docker restart event, including actor and target.
- New Self-serve account deletion with 7-day grace period and full data removal guarantee.
- New Change password from Account Security settings: invalidates all sessions on update with email confirmation.
- Improvement Complete backend rewrite: much faster response times, more consistent API behaviour, stronger foundation for future features.
- Improvement Full UI overhaul: cleaner navigation, reorganised settings, faster dashboard load times across every screen.
- Improvement Settings page reorganised: all account controls are now grouped under a single Account section.
- Fix Resolved an edge case where monitor status could appear stale after a cluster failover event.
- Fix Email notifications for incident recovery were sometimes firing before the monitor had fully stabilised. Fixed.
What's coming next
We're not announcing specific timelines for anything yet, but there are a few threads we're actively pulling on after 4.2 ships. Database syncing opens up a lot of possibilities for cross-region reporting and analytics that we haven't been able to build cleanly until now. The backend rewrite also gives us a foundation to build proper multi-workspace support, something a number of you have asked for.
On the infrastructure side, the work we did hardening the Docker restart endpoint is part of a broader pass we're running on every privileged API route in the system. Expect more security-focused improvements in 4.3.
Thanks for being with us, and for the patience while we built this out properly. The goal has always been to make PulseWatch a tool you can rely on for uptime monitoring and for handling infrastructure data correctly while keeping your team in control. 4.2 is a big step in that direction.
The PulseWatch Team
Comments
Questions, corrections or thoughts on this post? Join the thread below.