yugabyte
diff --git a/‎.github/vale-styles/Yugabyte/spelling-exceptions.txt
+1 b/‎.github/vale-styles/Yugabyte/spelling-exceptions.txt
+1
diff --git a/‎docs/content/preview/architecture/docdb-replication/async-replication.md
+1-2 b/‎docs/content/preview/architecture/docdb-replication/async-replication.md
+1-2
diff --git a/‎docs/content/preview/explore/ysql-language-features/pg-extensions/_index.md
+1 b/‎docs/content/preview/explore/ysql-language-features/pg-extensions/_index.md
+1
diff --git a/‎docs/content/preview/explore/ysql-language-features/pg-extensions/extension-pgcron.md
+66 b/‎docs/content/preview/explore/ysql-language-features/pg-extensions/extension-pgcron.md
+66
diff --git a/‎docs/content/preview/reference/configuration/yb-tserver.md
+8 b/‎docs/content/preview/reference/configuration/yb-tserver.md
+8
@@ -445,6 +445,7 @@ Patroni
 performant
 PgBouncer
 pgLoader
+pg_cron
 pg_recvlogical
 Phabricator
 phaser
 
@@ -161,12 +161,11 @@ Today, this is done by backing up the source universe and restoring it to the ta
 
 Ongoing work, [#17862](https://github.com/yugabyte/yugabyte-db/issues/17862), will replace using backup and restore here with directly copying RocksDB files between the source and target universes.  This will be more performant and flexible and remove the need for external storage like S3 to set up replication.
 
-
 ## Supported deployment scenarios
 
 xCluster currently supports active-active single-master and active-active multi-master deployments.
 
-### Active- active single-master
+### Active-active single-master
 
 Here the replication is unidirectional from a source universe to a target universe. The target universe is typically located in data centers or regions that are different from the source universe. The source universe can serve both reads and writes. The target universe can only serve reads. Since only the nodes in one universe can take writes this mode is referred to as single master. Note that within the source universe all nodes can serve writes.
 
 
@@ -59,6 +59,7 @@ YugabyteDB supports the following additional extensions, some of which you must
 | [HypoPG](extension-hypopg/) | Pre-bundled | Create hypothetical indexes to test whether an index can increase performance for problematic queries without consuming any actual resources. |
 | Orafce | Pre-bundled | Provides compatibility with Oracle functions and packages that are either missing or implemented differently in YugabyteDB and PostgreSQL. This compatibility layer can help you port your Oracle applications to YugabyteDB.<br/>For more information, see the [Orafce](https://github.com/orafce/orafce) documentation. |
 | [PGAudit](../../../secure/audit-logging/audit-logging-ysql/) | Pre-bundled | The PostgreSQL Audit Extension (pgaudit) provides detailed session and/or object audit logging via the standard PostgreSQL logging facility. |
+| [pg_cron](extension-pgcron/) | Pre-bundled | Provides a cron-based job scheduler that runs inside the database. |
 | [pg_hint_plan](../../query-1-performance/pg-hint-plan/#root) | Pre-bundled | Tweak execution plans using "hints", which are descriptions in the form of SQL comments.<br/>For more information, see the [pg_hint_plan](https://pghintplan.osdn.jp/pg_hint_plan.html) documentation. |
 | pg_stat_monitor | Pre-bundled | A PostgreSQL query performance monitoring tool, based on the PostgreSQL pg_stat_statements module.<br/>For more information, see the [pg_stat_monitor](https://docs.percona.com/pg-stat-monitor/index.html) documentation. |
 | [pgvector](extension-pgvector) | Pre-bundled | Allows you to store and query vectors, for use in vector similarity searching. |
 
@@ -0,0 +1,66 @@
+---
+title: pg_cron extension
+headerTitle: pg_cron extension
+linkTitle: pg_cron
+description: Using the pg_cron extension in YugabyteDB
+techPreview: /preview/releases/versioning/#feature-availability
+menu:
+  preview:
+    identifier: extension-pgcron
+    parent: pg-extensions
+    weight: 20
+type: docs
+---
+
+The [pg_cron](https://github.com/citusdata/pg_cron) extension provides a cron-based job scheduler that runs inside the database. It uses the same syntax as regular cron, and allows you to schedule YSQL commands directly from the database. You can also use '[1-59] seconds' to schedule a job based on an interval.
+
+YugabyteDB supports all features of the pg_cron extension. Although YugabyteDB is a distributed database that operates on multiple nodes, pg_cron only runs on one of these nodes, called the pg_cron leader. Only the pg_cron leader schedules and runs the cron jobs. The queries executed by jobs do take advantage of all available resources in the cluster.
+
+If the pg_cron leader node fails, another node is automatically elected as the new leader to ensure it is highly available. This process is transparent, and you can connect to any node in a cluster to schedule jobs.
+
+## Set up pg_cron
+
+pg_cron in YugabyteDB is {{<badge/tp>}}. Before you can use the feature, you must enable it by setting the `enable_pg_cron` flag. To do this, add `enable_pg_cron` to the `allowed_preview_flags_csv` flag and set the `enable_pg_cron` flag to true on all YB-Masters and YB-TServers.
+
+The pg_cron extension is installed on only one database, which stores the extension data. The default cron database is `yugabyte`. You can change it by setting the `ysql_cron_database_name` flag on all YB-TServers. You can create the database after setting the flag.
+
+For example, to create a single-node [yugabyted](../../../../reference/configuration/yugabyted/) cluster with pg_cron on database 'db1', use the following command:
+
+```sh
+./bin/yugabyted start --master_flags "allowed_preview_flags_csv={enable_pg_cron},enable_pg_cron=true" --tserver_flags "allowed_preview_flags_csv={enable_pg_cron},enable_pg_cron=true,ysql_cron_database_name=db1" --ui false
+```
+
+To change the database after the extension is created, you must first drop the extension and then change the flag value.
+
+## Enable pg_cron
+
+Create the extension as superuser on the cron database.
+
+```sql
+CREATE EXTENSION pg_cron;
+```
+
+You can grant access to other users to use the extension. For example:
+
+```sql
+GRANT USAGE ON SCHEMA cron TO elephant;
+```
+
+## Use pg_cron
+
+YugabyteDB supports all features and syntax of the pg_cron extension.
+
+For example, the following command calls a stored procedure every five seconds:
+
+```sql
+SELECT cron.schedule('process-updates', '5 seconds', 'CALL process_updates()');
+```
+
+If you need to run jobs in multiple databases, use `cron.schedule_in_database()`.
+
+When running jobs, keep in mind the following:
+
+- It may take up to 60 seconds for job changes to get picked up by the pg_cron leader.
+- When a new pg_cron leader node is elected, no jobs are run for the first minute. Any job that were in flight on the failed node will not be retried, as their outcome is not known.
+
+For more information on how to schedule jobs, refer to the [pg_cron documentation](https://github.com/yugabyte/yugabyte-db/blob/master/src/postgres/third-party-extensions/pg_cron/README.md).
@@ -855,6 +855,14 @@ Default: `-1` (disables logging statement durations)
 
 Specifies the lowest YSQL message level to log.
 
+##### --ysql_cron_database_name
+
+Specifies the database where pg_cron is to be installed. You can create the database after setting the flag.
+
+The [pg_cron extension](../../../explore/ysql-language-features/pg-extensions/extension-pgcron/) is installed on only one database (by default, `yugabyte`).
+
+To change the database after the extension is created, you must first drop the extension and then change the flag value.
+
 ##### --ysql_output_buffer_size
 
 Size of YSQL layer output buffer, in bytes. YSQL buffers query responses in this output buffer until either a buffer flush is requested by the client or the buffer overflows.