[DOCS-15413] Add prodname shortcode BlockIgnore to Vale config

.vale.ini

@@ -12,7 +12,8 @@ BlockIgnores = (?s) *({{< ?code-block [^>]* >}}.*?{{< ?/ ?code-block >}}), \
 (?s) *({{< ?(w|/w)hatsnext [^>]*>}}), \
 (?s) *({{< ?(n|/n)extlink [^>]*>}}), \
 (?s) *({%\s*if\s+[^%]*%}), \
-(?s) *({%\s*partial\s+[^%]*\/%})
+(?s) *({%\s*partial\s+[^%]*\/%}), \
+(?s) *({{< ?prodname ?>}}.*?{{< ?/ ?prodname ?>}})
 TokenIgnores = ({{< ?site-region [^>]* >}})
 
 [*.html]

hugo/content/en/account_management/api-app-keys.md

@@ -54,7 +54,7 @@ The recommended best practice for scoping application keys is to grant your keys
 Action APIs include:
 - [App Builder][5]
 - [Actions Connections][6]
-- [Workflow Automation][7]
+- [{{< prodname >}}Workflow Automation{{< /prodname >}}][7]
 
 In order to use application keys with these APIs, you must enable Actions API access on the application key. This can be done [through the UI][2] or [API][21]. By default, application keys cannot be used with these APIs.
 

hugo/content/en/account_management/audit_trail/_index.md

@@ -43,7 +43,7 @@ For security admins or InfoSec teams, audit trail events help with compliance ch
 
 - For user logins, account, or role changes in your organization.
 
-You can also analyze Audit Trail events with [Cloud SIEM][15] to detect threats and generate security signals. See [Getting Started with Cloud SIEM][16] for more information.
+You can also analyze Audit Trail events with [{{< prodname >}}Cloud SIEM{{< /prodname >}}][15] to detect threats and generate security signals. See [Getting Started with Cloud SIEM][16] for more information.
 
 **Note**: Datadog's tools and policies comply with PCI v4.0. For more information, see [PCI DSS Compliance][2].
 

hugo/content/en/account_management/audit_trail/events.md

@@ -18,7 +18,7 @@ further_reading:
 
 ## Agent actor and delegation fields
 
-In addition to product-specific events, Audit Trail events can carry actor and delegation metadata that identifies actions taken by a Datadog AI agent, such as Bits SRE, Bits Chat, Bits Security Analyst, and Bits Agent Builder.
+In addition to product-specific events, Audit Trail events can carry actor and delegation metadata that identifies actions taken by a Datadog AI agent, such as Bits SRE, {{< prodname >}}Bits Chat{{< /prodname >}}, {{< prodname >}}Bits Security Analyst{{< /prodname >}}, and Bits Agent Builder.
 
 | Field               | Description                                                                                                                                                                    |
 | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|

hugo/content/en/account_management/audit_trail/guides/track_agentic_usage_in_your_organization.md

@@ -13,7 +13,7 @@ further_reading:
 
 ## Overview
 
-Datadog AI agents, including the Bits fleet (Bits SRE, Bits Chat, Bits Security Analyst) and Bits Agent Builder, can take actions inside your organization on their own or on behalf of a user. Audit Trail attributes these actions to the agent that performed them and, when applicable, to the user who authorized them. Onboarding to this attribution model varies by agent and by action type. This guide walks you through finding agent-driven events, filtering them by agent type, tracing an agent's actions back to the user who delegated them, and checking agent coverage.
+Datadog AI agents, including the Bits fleet (Bits SRE, {{< prodname >}}Bits Chat{{< /prodname >}}, {{< prodname >}}Bits Security Analyst{{< /prodname >}}) and Bits Agent Builder, can take actions inside your organization on their own or on behalf of a user. Audit Trail attributes these actions to the agent that performed them and, when applicable, to the user who authorized them. Onboarding to this attribution model varies by agent and by action type. This guide walks you through finding agent-driven events, filtering them by agent type, tracing an agent's actions back to the user who delegated them, and checking agent coverage.
 
 ## Agent coverage
 
@@ -69,7 +69,7 @@ To retrieve a user's complete activity, including delegated agent actions:
 
 ## Distinguish agent events from human events
 
-Agent-driven events are marked with the agent's name and avatar (for example, Bits Chat) paired with the delegating user, labeled Co-authored by user + agent. This lets you distinguish agent activity from human activity without opening each event.
+Agent-driven events are marked with the agent's name and avatar (for example, {{< prodname >}}Bits Chat{{< /prodname >}}) paired with the delegating user, labeled Co-authored by user + agent. This lets you distinguish agent activity from human activity without opening each event.
 
 ## Further reading
 

hugo/content/en/account_management/billing/_index.md

@@ -23,7 +23,7 @@ It is recommended that containers are monitored with a single containerized Agen
 
 Datadog bills based on the average number of functions per hour across the month for your accounts. Every hour, Datadog records the number of functions that were executed one or more times and monitored by your Datadog account. At the end of the month, Datadog charges by calculating the average of the hourly number of functions recorded. Pro and Enterprise plans include five custom metrics per billable function.
 
-Billing for serverless APM is based on the sum of AWS Lambda invocations connected to APM ingested spans in a given month. You will also be billed for the total number of [indexed spans][4] submitted to the Datadog APM service exceeding the bundled quantity at the end of the month. There are no billable [APM Hosts][4] when using serverless.
+Billing for serverless APM is based on the sum of AWS Lambda invocations connected to APM ingested spans in a given month. You will also be billed for the total number of [indexed spans][4] submitted to the {{< prodname >}}Datadog APM{{< /prodname >}} service exceeding the bundled quantity at the end of the month. There are no billable [APM Hosts][4] when using serverless.
 
 For more information, see the [Serverless billing page][5] and the [Datadog Pricing page][6].
 

hugo/content/en/account_management/billing/ai_credit_limits.md

@@ -9,7 +9,7 @@ further_reading:
 
 ## Overview
 
-Organization admins can set monthly caps on AI Credit usage at the organization level, the per-user level, or both. Admins can also override the default per-user limit for individual users. AI Credits are shared across [Bits Chat][1], [Bits Investigation][2], [Bits Code][3], and [Bits Agent Builder][4].
+Organization admins can set monthly caps on AI Credit usage at the organization level, the per-user level, or both. Admins can also override the default per-user limit for individual users. AI Credits are shared across [{{< prodname >}}Bits Chat{{< /prodname >}}][1], [Bits Investigation][2], [{{< prodname >}}Bits Code{{< /prodname >}}][3], and [Bits Agent Builder][4].
 
 ## Permissions
 
@@ -38,7 +38,7 @@ You can configure three types of monthly limits:
 - When both an organization limit and a user limit (or override) are configured, the most restrictive applicable limit applies to a user.
 - If a user has both a default per-user limit and an override configured, the higher of the two applies, and the user's usage is still subject to the organization-wide limit.
 - Raising a limit unblocks users who reached the previous limit. Lowering a limit blocks users whose usage already exceeds the new value.
-- When a user or the organization reaches a limit, affected users can't use Bits Chat, Bits Investigation, Bits Code, or Bits Agent Builder, and a banner shows the reset date.
+- When a user or the organization reaches a limit, affected users can't use {{< prodname >}}Bits Chat{{< /prodname >}}, Bits Investigation, {{< prodname >}}Bits Code{{< /prodname >}}, or Bits Agent Builder, and a banner shows the reset date.
 
 ### Examples
 

hugo/content/en/account_management/billing/incident_response.md

@@ -14,11 +14,11 @@ further_reading:
 
 ## Overview
 
-Datadog's [Incident Management][1], [On-Call][2], and Incident Response SKUs use a seat-based billing model. 
+Datadog's [{{< prodname >}}Incident Management{{< /prodname >}}][1], [{{< prodname >}}On-Call{{< /prodname >}}][2], and Incident Response SKUs use a seat-based billing model. 
 
 Organizations have two options for incident response billing:
-- Incident Management or On-Call as separate SKUs, each billed individually
-- The Incident Response bundle, which unifies billing for both Incident Management and On-Call under a single SKU
+- {{< prodname >}}Incident Management{{< /prodname >}} or {{< prodname >}}On-Call{{< /prodname >}} as separate SKUs, each billed individually
+- The Incident Response bundle, which unifies billing for both {{< prodname >}}Incident Management{{< /prodname >}} and {{< prodname >}}On-Call{{< /prodname >}} under a single SKU
 
 Each product bills by seat, so each user who performs qualifying actions requires a seat license. For detailed pricing information, see the [Incident Response pricing page][3].
 
@@ -28,16 +28,16 @@ View and manage seat usage for each product in the [Seat Management][4] section
 
 A **seat** is a license for a user to actively participate in the on-call or incident management process in Datadog. 
 
-Any user can claim a seat for On-Call, Incident Management, or Incident Response as they perform actions that require a seat. Billing admins can also assign seats ahead of time to simplify the process for their teams.
+Any user can claim a seat for {{< prodname >}}On-Call{{< /prodname >}}, {{< prodname >}}Incident Management{{< /prodname >}}, or Incident Response as they perform actions that require a seat. Billing admins can also assign seats ahead of time to simplify the process for their teams.
 
-A user needs an **On-Call seat** if they perform any of the following:
+A user needs an **{{< prodname >}}On-Call{{< /prodname >}} seat** if they perform any of the following:
 - Participate in an [on-call schedule][5]
 - Are included in an [escalation policy][6]
 - Have set up [notification preferences][7] to receive pages
 
-In the On-Call product, a user does not need a seat to view existing pages, escalation policies, teams, or schedules.
+In the {{< prodname >}}On-Call{{< /prodname >}} product, a user does not need a seat to view existing pages, escalation policies, teams, or schedules.
 
-A user needs an **Incident Management seat** if they perform any of the following actions. These actions require a seat whether they are performed in the Datadog UI or through integrations such as Microsoft Teams or Slack.
+A user needs an **{{< prodname >}}Incident Management{{< /prodname >}} seat** if they perform any of the following actions. These actions require a seat whether they are performed in the Datadog UI or through integrations such as Microsoft Teams or Slack.
 - Modify an incident (for example, update severity)
 - Delete an incident
 - Add a comment, graph, or link to an incident timeline
@@ -46,11 +46,11 @@ A user needs an **Incident Management seat** if they perform any of the followin
 
 In Incident Management, a user does not need a seat to create incidents, view incidents, or join incident channels. Commenting in Slack, including posting messages that sync to the incident timeline, also does not require a seat. Only actions taken through the Datadog app in Slack, such as using action buttons or interacting with @Datadog, trigger a seat requirement.
 
-If your organization has committed to the Incident Response SKU, any user who meets the On-Call or Incident Management criteria can claim or be assigned an **Incident Response seat**.
+If your organization has committed to the Incident Response SKU, any user who meets the {{< prodname >}}On-Call{{< /prodname >}} or {{< prodname >}}Incident Management{{< /prodname >}} criteria can claim or be assigned an **Incident Response seat**.
 
 ### Status Pages usage
 
-All paid Datadog customers can use Status Pages. Access depends on whether your organization has a committed Incident Management or Incident Response seat:
+All paid Datadog customers can use Status Pages. Access depends on whether your organization has a committed {{< prodname >}}Incident Management{{< /prodname >}} or Incident Response seat:
 - **With at least one committed seat**: Full access, including unlimited pages and custom domains.
 - **Without a committed seat**: Limited to one Status Page and no custom domain support.
 
@@ -60,10 +60,10 @@ If you are a trialing customer who would like full access during trial period, c
 
 ## Manage seats
 
-The [Seat Management page][1] gives billing admins visibility and control over users who occupy seats for Incident Management, On-Call, or the Incident Response bundle. 
+The [Seat Management page][1] gives billing admins visibility and control over users who occupy seats for {{< prodname >}}Incident Management{{< /prodname >}}, {{< prodname >}}On-Call{{< /prodname >}}, or the Incident Response bundle. 
 
 The Seat Management page contains tabs for each product enabled in your organization. Depending on your contract, you may see one of the following:
-- Separate tabs for Incident Management and On-Call
+- Separate tabs for {{< prodname >}}Incident Management{{< /prodname >}} and {{< prodname >}}On-Call{{< /prodname >}}
 - A single tab for Incident Response (if you use the bundle SKU)
 
 Each tab includes:
@@ -75,7 +75,7 @@ Each tab includes:
 
 You can also find users by searching by name, email, or team. 
 
-On-Call admins can also use the [Notification Preferences settings page][9] to view which schedules or escalation policies a user belongs to and remove that user's notification preferences if needed. 
+{{< prodname >}}On-Call{{< /prodname >}} admins can also use the [Notification Preferences settings page][9] to view which schedules or escalation policies a user belongs to and remove that user's notification preferences if needed. 
 
 Removing a user's notification preferences does not unassign their seat. If a user should no longer occupy a seat, you must explicitly unassign the user from the Seat Management Page. 
 
@@ -89,7 +89,7 @@ Billing admins, or users with the `billing_edit` permission, can manually assign
 
 To assign a seat:
 1. Go to {{< ui >}}Plan & Usage{{< /ui >}} → {{< ui >}}Seat Management{{< /ui >}}.
-2. Select the relevant product tab: {{< ui >}}Incident Management{{< /ui >}}, {{< ui >}}On-Call{{< /ui >}}, or {{< ui >}}Incident Response{{< /ui >}}.
+2. Select the relevant product tab: {{< ui >}}{{< prodname >}}Incident Management{{< /prodname >}}{{< /ui >}}, {{< ui >}}{{< prodname >}}On-Call{{< /prodname >}}{{< /ui >}}, or {{< ui >}}Incident Response{{< /ui >}}.
 3. Click {{< ui >}}Assign Seats{{< /ui >}}.
 4. Search for users by name or email, and select them.
 5. Click {{< ui >}}Assign Seats{{< /ui >}}.
@@ -110,7 +110,7 @@ After they are unassigned, the user loses access to features that require a seat
 
 ### Claim a seat
 
-When you try to perform an action that requires a seat (such as joining an On-Call schedule, updating an incident, or adding information to an incident timeline) Datadog prompts you to claim a seat. Claiming a seat requires at least one of the following permissions: `billing_read`, `on_call_read`, or `incident_read`.
+When you try to perform an action that requires a seat (such as joining an {{< prodname >}}On-Call{{< /prodname >}} schedule, updating an incident, or adding information to an incident timeline) Datadog prompts you to claim a seat. Claiming a seat requires at least one of the following permissions: `billing_read`, `on_call_read`, or `incident_read`.
 
 After you claim a seat, the following items change in Datadog:
 - You immediately gain access to the product features you need (for example, receiving pages or managing incidents).
@@ -122,7 +122,7 @@ You only need to claim a seat once. After a seat is assigned, you continue to ha
 
 ## Billing and overages
 
-Datadog bills for On-Call, Incident Management, and Incident Response based on the total number of seats in use during each billing period. 
+Datadog bills for {{< prodname >}}On-Call{{< /prodname >}}, {{< prodname >}}Incident Management{{< /prodname >}}, and Incident Response based on the total number of seats in use during each billing period. 
 
 Each billing period reflects the maximum number of concurrently assigned seats across your organization for that product. Your contract includes a committed number of seats, and any usage beyond that amount is billed at your on-demand rate. 
 

hugo/content/en/account_management/billing/pricing.md

@@ -11,7 +11,7 @@ Datadog has many pricing plans to fit your needs. For more information, see the
 
 ## Billing plans
 
-Datadog offers two billing plans for host-based products, such as Infrastructure Monitoring, APM, and Database Monitoring:
+Datadog offers two billing plans for host-based products, such as {{< prodname >}}Infrastructure Monitoring{{< /prodname >}}, APM, and {{< prodname >}}Database Monitoring{{< /prodname >}}:
 
 - **High watermark plan (HWMP)**: Datadog meters your host count each hour. At the end of the month, Datadog bills you on the maximum count (high-water mark) of the lower 99% of those hourly readings, excluding the top 1% to reduce the impact of short usage spikes on your bill. This plan is well-suited to environments with stable usage throughout the month.
 - **Hybrid monthly/hourly plan (MHP)**: You commit to a monthly minimum, and any host hours above that commitment are billed at an hourly rate. Because usage above the commitment is billed hourly, this plan is well-suited to ephemeral environments, such as autoscaling fleets or short-lived workloads.
@@ -33,8 +33,8 @@ The following sections describe the most common pricing units for each product.
 * If an application running on a host (defined in [Infrastructure monitoring](#infrastructure-monitoring)) generates traces and submits them to the Datadog SaaS application, Datadog counts that host as one **APM host**.
   * On a high watermark plan (HWMP), Datadog meters the count of hosts hourly. The billable count of hosts is calculated at the end of the month using the maximum count (high-water mark) of the lower 99 percent of usage for those hours. Datadog excludes the top 1 percent to reduce the impact of spikes in usage on your bill.
   * On a hybrid monthly/hourly plan (MHP), Datadog charges your minimum monthly commitment, and for any host hours above that commitment, Datadog charges an hourly rate.
-* An **Indexed Span** is an individual request against an individual service in your stack. Datadog charges based on the total number of spans indexed by [retention filters][3] within Datadog APM.
-* An **Ingested Span** is an individual request against an individual service in your stack. Datadog charges based on the total number of gigabytes of spans ingested into Datadog APM.
+* An **Indexed Span** is an individual request against an individual service in your stack. Datadog charges based on the total number of spans indexed by [retention filters][3] within {{< prodname >}}Datadog APM{{< /prodname >}}.
+* An **Ingested Span** is an individual request against an individual service in your stack. Datadog charges based on the total number of gigabytes of spans ingested into {{< prodname >}}Datadog APM{{< /prodname >}}.
 
 You can put controls in place for both Indexed and Ingested span volumes. For more information, read the [Trace Ingestion][4] and [Retention][5] documentation.
 
@@ -86,7 +86,7 @@ You can put controls in place for both Indexed and Ingested span volumes. For mo
 ## Incident Management
 
 * For organizations on a seat-based plan, Datadog charges based on your organization's seat commitment. 
-* For organizations on the legacy usage-based plan, Datadog tracks the number of monthly active Incident Management users.
+* For organizations on the legacy usage-based plan, Datadog tracks the number of monthly active {{< prodname >}}Incident Management{{< /prodname >}} users.
   * Datadog counts a user as an **active user** if they have used Datadog capabilities to contribute substantively to the incident response. For example, you become an active user for the month when you:
     * Update an incident's state, severity, or other fields
     * Comment on the incident's timeline