Monitor Redgate Assistant and MCP Server are now in public preview (v14.28)

Both routes into AI-assisted work with Monitor data have moved from private into public preview, and Redgate Assistant is now available on Server overview pages for SQL Server on Windows (v14.31).

We covered what each one does in July. In short, Redgate Assistant brings the chat, your Monitor data and the relevant context together inside Monitor, while the Monitor MCP Server connects that same data to an MCP-compatible assistant of your own. Both draw on the same Monitor foundation, and in both cases access is read-only, auditable and scoped by your existing controls.

The difference now is that you can try them for yourself. To see what that looks like first, watch the live demo, where an alert on a single server becomes a prioritized, evidence-backed plan of action.

Know about a brute-force attack while it's happening, not afterwards* (v14.30)

Repeated failed logins are one of the clearest early signals that someone is trying to get into a server they shouldn't, and one of the easiest to miss, because the evidence sits in logs nobody reads until something has already gone wrong.

Redgate Monitor Enterprise now alerts you when a set number of SQL Server login failures occur against a monitored server inside a window of time you define, so the team finds out while it's happening and can act before it becomes an incident. The alert uses the SQL Server audit log, so that needs to be enabled on the instance.

It complements database permission change alerting, which shipped last month. One tells you when someone is trying to get in from outside. The other tells you when someone already inside has been granted access they shouldn't have.

Configuration advice and table bloat alerting for PostgreSQL (v14.30)

In Postgres, tuning configuration is important, and if you've inherited a Postgres estate alongside your SQL Server one, the hard part is knowing what "good" looks like across hundreds of Postgres parameters. The PostgreSQL server overview pages now have a Configuration tab that shows each instance's current values against recommendations for the settings that matter most, so you can spot a badly configured server without knowing Postgres inside-out. The estate-level Server configuration page has a new PostgreSQL tab too, so you can scan down it to find the one cluster whose settings have drifted, or pivot to a single parameter and see how it's set across every server.

There's also a new table bloat alert, raised when the percentage of dead tuples on a PostgreSQL table goes over a threshold you set (with a minimum table size default, so small tables don't add noise). Bloat builds up quietly as rows are updated and deleted, and by the time it shows up as slow queries or storage creeping up, auto-vacuum has usually been falling behind for a while. This alert isn't just warning you that a table needs vacuuming, it's telling you that the vacuum configuration should be reviewed.

Also new

• Redgate Monitor SaaS customers can now opt for Redgate Monitor SaaS Enterprise* which brings the full Monitor Enterprise feature set (with the exception of the Data API and sensitive action log) to Redgate Monitor SaaS.
• The new security user role* gives security, compliance and audit teams read-only access to the security pages alone, rather than the wider monitoring estate (v14.30). Built directly in response to customer requests, it means those teams can pull the access information they need themselves while the database team stays in control of exactly what's shared.
• Redgate Monitor can also now run in a Docker container (v14.28), using the Base Service and Website images hosted on Docker Hub. See the installation documentation to get started.