diff --git a/doc/user/content/releases/_index.md b/doc/user/content/releases/_index.md
index 13ec8d0105cbd..306ff46134967 100644
--- a/doc/user/content/releases/_index.md
+++ b/doc/user/content/releases/_index.md
@@ -20,6 +20,40 @@ Starting with the v26.1.0 release, Materialize releases on a weekly schedule for
 both Cloud and Self-Managed. See [Release schedule](/releases/schedule) for details.
 {{</ note >}}
 
+## v26.45.1
+*Released to Materialize Cloud: 2026-10-08* <br>
+*Released to Materialize Self-Managed: 2026-10-09* <br>
+
+### Alerting for Self-Managed {#v26.45.1-alerting}
+
+<red>*Materialize Self-Managed only*</red>
+
+Starting with v16.0.0 of the [Materialize Terraform modules](/self-managed-deployments/installation/#install-using-terraform-modules), the monitoring stack ships with ready-made alerts, so you hear about a problem before your users do:
+
+- **Ready-made alert rules**: 34 alerts are on by default, covering Materialize and the Kubernetes platform under it. They include `environmentd` going down, clusters stuck hydrating, replicas nearing their memory limit or being OOM-killed, and panics in Materialize's logs.
+- **Route each alert to whoever acts on it**: Every alert carries a severity and an audience, `platform` for the team operating the deployment and `workload` for the teams that own the clusters, so you can send each to the right people.
+- **Notify the tools your team already uses**: Configure PagerDuty, Slack, Microsoft Teams, email, or webhook receivers from Terraform.
+
+A default install configures no receiver, so alerts notify nobody until you add one. For more information, see [Alerting](/observability/self-managed/alerting/) and [Customize alerting](/observability/self-managed/customize-alerting/).
+
+### Improvements {#v26.45.1-improvements}
+- **External dependency monitoring for Self-Managed**: Starting with v15.0.0 of the [Materialize Terraform modules](/self-managed-deployments/installation/#install-using-terraform-modules), new **Materialize Persist (Storage)** and **Materialize Consensus (Metadata)** dashboards show the object storage and metadata database that Materialize depends on, so you can tell quickly whether a problem is in Materialize or in one of its dependencies.
+- **`sum` and `avg` over `interval`**: `sum(interval)` and `avg(interval)` now work and return `interval`, matching PostgreSQL.
+- **Improved compatibility with PostgreSQL ODBC clients**: Queries that psqlODBC generates with `OPERATOR(pg_catalog.=)` syntax now parse instead of failing.
+- **Lower memory for `MIN` and `MAX`**: A materialized view or index computing a single `MIN` or `MAX` over an input that receives updates or deletes no longer keeps an extra copy of its input in memory.
+- **Lower `SUBSCRIBE` and query latency**: Introspection logging now processes its events in bounded chunks instead of all at once, so it no longer holds up `SUBSCRIBE` results and indexed queries on the same replica.
+- **Kubernetes API server certificates need a subject alternative name (Self-Managed)**: The Materialize operator, `environmentd`, and `mz-debug` now reject a Kubernetes API server certificate that names its host only in its common name. EKS, GKE, AKS, and kind are unaffected; if you use hand-issued API server certificates, check them before upgrading.
+- **Schema registry and `COPY FROM` server certificates need a subject alternative name**: Confluent Schema Registry connections, `COPY FROM` URLs, and the OIDC issuer fetch now reject a server certificate that names its host only in its common name, so reissue any such certificate with a matching subject alternative name before upgrading. A schema registry certificate that is byte-for-byte identical to the connection's `SSL CERTIFICATE AUTHORITY` is still trusted.
+- **Kubernetes events from the Materialize operator**: The operator now publishes Kubernetes events when it fails to reconcile a `Materialize`, `Balancer`, or `Console` resource and at each `Materialize` rollout phase, so `kubectl describe` shows why a resource is not progressing.
+
+### Agent Skills {#v26.45.1-agent-skills}
+- **`mz-demo-data`**: A new skill that creates continuously updating synthetic data inside Materialize using views over `mz_now()`, with no Kafka or external load generator, in a `materialize_demo` schema that one `DROP SCHEMA` removes.
+
+### Bug Fixes {#v26.45.1-bug-fixes}
+- Fixed zero-downtime deployment cut-overs that could stall for hours on environments with a large catalog audit log.
+- Fixed `DISCARD ALL` not reporting the parameters it resets, which caused connection poolers such as pgbouncer to lose track of values like `application_name`.
+- Fixed the Console showing different cluster utilization on different pages, and reporting memory and CPU per process rather than combined for multi-process replicas.
+
 ## v26.44.1
 *Released to Materialize Cloud: 2026-09-30* <br>
 *Released to Materialize Self-Managed: 2026-10-01* <br>
diff --git a/doc/user/data/self_managed/self_managed_operator_compatibility.yml b/doc/user/data/self_managed/self_managed_operator_compatibility.yml
index 0d68486fc9097..4e13ecc746fe4 100644
--- a/doc/user/data/self_managed/self_managed_operator_compatibility.yml
+++ b/doc/user/data/self_managed/self_managed_operator_compatibility.yml
@@ -5,6 +5,11 @@ columns:
   - column: Release date
   - column: Notes
 rows:
+  - Materialize Operator: v26.45.1
+    orchestratord version: v26.45.1
+    environmentd version: v26.45.1
+    Release date: "2026-10-09"
+    Notes: "See [v26.45.1 release notes](/releases/#v26451)"
   - Materialize Operator: v26.44.1
     orchestratord version: v26.44.1
     environmentd version: v26.44.1