Merge branch 'fix-regional-endpoints' of github.com:temporalio/documentation into fix-regional-endpoints

Author: lukeknep

docs/cloud/billing-and-usage/billing-api.mdx

@@ -20,7 +20,7 @@ This API is part of the [Cloud Operations API](/ops).
 
 :::tip Support, stability, and dependency info
 
-The Temporal Cloud Billing API is in [Pre-release](/evaluate/development-production-features/release-stages#pre-release).
+The Temporal Cloud Billing API is in [Public Preview](/evaluate/development-production-features/release-stages#public-preview).
 
 :::
 
@@ -33,7 +33,7 @@ The Billing API allows you to:
 The Billing Report contains:
 
 - Accurate Namespace-level cost attribution  
-- Hourly granularity  
+- Hourly, daily, and monthly granularities
 - A [FOCUS](https://focus.finops.org/)-friendly data format
 
 For complete request and response schemas, refer to the Schema below.
@@ -42,7 +42,10 @@ Billing report generation is **asynchronous**. You initiate report creation, the
 
 ## Report data limitations
 
-For pre-release, reports can be generated with hourly granularity only, for the current billing month, and the previous billing month.
+For public preview, reports can be generated with hourly, daily and monthly granularities, each of which have their own data ranges.
+- Hourly: Current billing month and previous billing month
+- Daily: Current billing month and previous two billing months
+- Monthly: Current billing month and previous eleven billing months
 
 ## Allowed date ranges
 

docs/cloud/billing-and-usage/billing.mdx

@@ -87,7 +87,7 @@ The following information appears under the credits table:
 
 ## Cost by Namespace {#cost-by-namespace}
 
-:::tip Temporal Cloud Billing API in Pre-release
+:::tip Temporal Cloud Billing API in Public Preview
 
 The [Temporal Cloud Billing API](/cloud/billing-api) allows you to access billing information on a Namespace basis to an hourly granularity, enriched with Tags and Projects. The Billing API will replace the Cost by Namespace UI.
 

docs/cloud/billing-and-usage/index.mdx

@@ -44,7 +44,7 @@ The following tools are available for measuring Usage and Billing:
 
 :::tip Support, stability, and dependency info
 
-The Temporal Cloud Billing API is in [Pre-release](/evaluate/development-production-features/release-stages#pre-release).
+The Temporal Cloud Billing API is in [Public Preview](/evaluate/development-production-features/release-stages#public-preview).
 
 :::
 

docs/cloud/connectivity/aws-connectivity.mdx

@@ -33,16 +33,15 @@ After creating the PrivateLink endpoint, configure your clients to use it throug
 
 ## Requirements
 
-* Your AWS PrivateLink endpoint must be in the same region as your Temporal Cloud namespace. If using [replication for High Availability](/cloud/high-availability), the PL connection must be in the same region as one of the replicas.
+* Your AWS PrivateLink (PL) endpoint must be in the same region as your Temporal Cloud Namespace. If the Namespace is using [replication for High Availability](/cloud/high-availability), the PL connection must be in the same region as one of the replicas.
   See [cross-region PrivateLink connectivity](#cross-region-privatelink) to access the Namespace from a different region.
 * Your Private DNS must be configured to direct Worker / Client traffic to your VPC Endpoint, as described below.
 * If the Worker / Client is not using the Namespace Endpoint, it may need to set the `server_name` config to the Namespace Endpoint string, as described below.
 
 ### Cross-region PrivateLink Connectivity {#cross-region-privatelink}
 
-Temporal Cloud does **not** support [cross-region connectivity for AWS PrivateLink](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-cross-region-connectivity-for-aws-privatelink/) out of the box.
+Temporal Cloud does **not** support [cross-region connectivity for AWS PrivateLink](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-cross-region-connectivity-for-aws-privatelink/) out of the box. However, if you need to reach Temporal Cloud privately from a different region than your Namespace, you can route traffic to your VPC Endpoint in the Namespace's region using [AWS's native cross-region networking features]((https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#cross-region-endpoint-access)). 
 
-You can access your VPC Endpoint in a different region using the [native cross-region routing in AWS](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#cross-region-endpoint-access).
 
 When using High Availability on Temporal Cloud, it's best practice to have two VPC Endpoints, one in each of the Namespace's regions, to ensure at least one VPC Endpoint is accessible during a regional outage.
 
@@ -197,7 +196,7 @@ The DNS resolver inside your VPC returns the private endpoint, while TLS still v
 
 ## Configure private DNS for Namespaces with High Availability
 
-For Namespaces with [High Availability features](/cloud/high-availability), you need to override DNS for `region.tmprl.io` so each region resolves to the local VPC Endpoint, and you need to ensure Workers can reach whichever region is active. Failover is transparent to clients only when this is set up correctly.
+For Namespaces with [High Availability features](/cloud/high-availability), you need to override DNS for `region.tmprl.cloud` so each region resolves to the local VPC Endpoint, and you need to ensure Workers can reach whichever region is active. Failover is transparent to clients only when this is set up correctly.
 
 The complete guidance — including single-cloud (AWS-only) HA, multi-cloud HA (AWS PrivateLink + GCP Private Service Connect), and a recommended failover-testing plan — lives on a single page: [Connectivity for High Availability](/cloud/high-availability/ha-connectivity).
 
@@ -212,13 +211,14 @@ For single-region Namespaces, you can avoid creating DNS records for each Namesp
 
 With this approach, new Namespaces do not require new DNS records.
 
-:::warning Extra care needed for Namespaces with High Availability
+:::caution Extra care needed for Namespaces with High Availability
 
 Direct VPCE targeting bypasses the Temporal-managed DNS CNAME that normally routes a Namespace to its active region, so each Worker is pinned to whichever VPC Endpoint you configure. To keep both regions reachable, you must run Workers in each region and configure them with **different endpoints**:
 
 - Workers in the primary region: the local VPC Endpoint for that region (e.g., `vpce-...-us-east-1.vpce.amazonaws.com:7233`).
 - Workers in the replica region: the local VPC Endpoint for that region (e.g., `vpce-...-us-west-2.vpce.amazonaws.com:7233`).
-- All Workers: the same SNI override — the Namespace Endpoint value (e.g., `my-namespace.my-account.tmprl.cloud`).
+
+All Workers require the same SNI override — the Namespace Endpoint value (e.g., `my-namespace.my-account.tmprl.cloud`).
 
 :::
 

docs/cloud/high-availability/failovers.mdx

@@ -62,7 +62,7 @@ In most scenarios, we recommend you let Temporal handle failovers for you.
 After failover, be aware of the following points:
 
 - When working with Multi-region Namespaces, your CNAME may change.
-  For example, it may switch from us-west-1.aws.api.temporal.io to us-east-1.aws.api.temporal.io.
+  For example, it may switch from aws-us-west-1.region.tmprl.cloud to aws-us-east-1.region.tmprl.cloud.
   This change doesn't affect same-region Namespaces.
 
 - Your Namespace endpoint _will not change_.

docs/cloud/high-availability/ha-connectivity.mdx

@@ -25,7 +25,7 @@ A Namespace with High Availability features has two replicas — a primary and a
 Temporal Cloud expresses the active replica through DNS:
 
 - The Namespace DNS record (`<ns>.<account>.tmprl.cloud`) is a CNAME.
-- It points to the active region's regional record (`<region>.<provider>.api.temporal.io`).
+- It points to the active region's regional record (`<provider>-<region>.region.tmprl.cloud`).
 - On failover, Temporal Cloud rewrites the CNAME target.
 
 Namespace DNS records have a 15-second TTL. Clients should converge to the new region within roughly 30 seconds (about twice the TTL) once their resolver cache expires.

docs/cloud/manage-access/roles-and-permissions.mdx

@@ -36,7 +36,7 @@ The following table provides a summary of the account-level roles and their prim
 | Account Owner | Owns and governs the account                | Yes                   | All Namespaces (cannot be revoked)      | Full billing, payments, and usage |
 | Global Admin  | Administers account configuration and users | Yes                   | All Namespaces (cannot be revoked)      | Usage only                        |
 | Developer     | Creates and manages Namespaces they own     | Yes                   | Namespaces they create (can be revoked) | None                              |
-| Finance Admin | Manages billing and payment information     | No                    | None                                    | Full billing and payments         |
+| Finance Admin | Manages billing and payment information     | No                    | None                                    | Full billing, payments, and usage         |
 | Read-Only     | Views account configuration and resources   | No                    | None                                    | None                              |
 
 Account-level roles don't govern day-to-day operations within a Namespace. Access to resources inside a Namespace, such

docs/develop/dotnet/workflows/child-workflows.mdx

@@ -40,8 +40,9 @@ A [Child Workflow Execution](/child-workflows) is a Workflow Execution that is s
 
 When using a Child Workflow API, Child Workflow related Events ([StartChildWorkflowExecutionInitiated](/references/events#startchildworkflowexecutioninitiated), [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted), [ChildWorkflowExecutionCompleted](/references/events#childworkflowexecutioncompleted), etc...) are logged in the Workflow Execution Event History.
 
-Always block progress until the [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted) Event is logged to the Event History to ensure the Child Workflow Execution has started.
-After that, Child Workflow Executions may be abandoned using the _Abandon_ [Parent Close Policy](/parent-close-policy) set in the Child Workflow Options.
+The [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted) Event must be logged to the Event History before the Parent Workflow completes to ensure the Child Workflow has started.
+In .NET, awaiting `StartChildWorkflowAsync()` or `ExecuteChildWorkflowAsync()` internally waits for this Event before returning, so the Child Workflow is guaranteed to have started once the call resolves.
+If you start a Child Workflow from a non-main context (for example, a Signal or Update handler), make sure the Parent Workflow doesn't complete before that call resolves.
 
 To spawn a Child Workflow Execution in .NET, use the `ExecuteChildWorkflowAsync()` method which starts the Child Workflow and waits for completion or
 use the `StartChildWorkflowAsync()` method to start a Child Workflow and return its handle.

docs/develop/go/workers/run-worker-process.mdx

@@ -22,7 +22,8 @@ Create a [`Worker`](https://pkg.go.dev/go.temporal.io/sdk/worker#Worker) by call
 2. The name of the Task Queue to poll.
 3. A [`worker.Options`](https://pkg.go.dev/go.temporal.io/sdk/internal#WorkerOptions) struct (can be empty for defaults).
 
-Register your Workflow and Activity types, then call `Run()` to start polling.
+Register your Workflow and Activity types, then call `Run()` to start polling. The Worker process is a long-running process that blocks while polling for tasks.
+Run it in a separate terminal from your starter code or other application logic.
 
 ```go
 package main

docs/develop/go/workflows/child-workflows.mdx

@@ -24,12 +24,9 @@ A [Child Workflow Execution](/child-workflows) is a Workflow Execution that is s
 
 When using a Child Workflow API, Child Workflow related Events ([StartChildWorkflowExecutionInitiated](/references/events#startchildworkflowexecutioninitiated), [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted), [ChildWorkflowExecutionCompleted](/references/events#childworkflowexecutioncompleted), etc...) are logged in the Workflow Execution Event History.
 
-Always block progress until the [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted) Event is logged to the Event History to ensure the Child Workflow Execution has started.
-After that, Child Workflow Executions may be abandoned using the _Abandon_ [Parent Close Policy](/parent-close-policy) set in the Child Workflow Options.
-
-To be sure that the Child Workflow Execution has started, first call the Child Workflow Execution method on the instance of Child Workflow future, which returns a different future.
-
-Then get the value of an object that acts as a proxy for a result that is initially unknown, which is what waits until the Child Workflow Execution has spawned.
+The [ChildWorkflowExecutionStarted](/references/events#childworkflowexecutionstarted) Event must be logged to the Event History before the Parent Workflow completes to ensure the Child Workflow has started.
+In Go, you must explicitly call `GetChildWorkflowExecution()` on the `ChildWorkflowFuture` and then call `Get()` on the returned Future to wait for this Event.
+See the [Async Child Workflows](#async-child-workflows) section below for a complete example.
 
 To spawn a [Child Workflow Execution](/child-workflows) in Go, use the [`ExecuteChildWorkflow`](https://pkg.go.dev/go.temporal.io/sdk/workflow#ExecuteChildWorkflow) API, which is available from the `go.temporal.io/sdk/workflow` package.