Datadog offers monitoring, observability, and security for cloud-scale applications, unifying metrics, logs, and traces to help teams detect issues and optimize performance
Datadog offers monitoring, observability, and security for cloud-scale applications, unifying metrics, logs, and traces to help teams detect issues and optimize performance On Nagent, Datadog is exposed as a fully-configurable server monitoring integration that any agent can call — 43 actions, and OAUTH2, API_KEY authentication. No code is required to wire Datadog into your workflow — connect it once via the External Integrations panel and reuse it across every agent you build.
Agent builders use Datadog to automate the kinds of tasks server monitoring teams previously handled manually. Concrete examples — each one is a single agent step in Nagent — include:
Every action and trigger is paired with a structured input/output schema (visible in the sections below), so when you wire Datadog into Helix — our agentic agent builder — the editor knows exactly what each step expects and produces. Configure once, deploy anywhere across your Nagent agents.
Every operation an agent can call against Datadog, with input parameters and output schema. Drop these into any step of an agent built in Helix.
DATADOG_CREATE_DASHBOARDCreate a dashboard in Datadog. Dashboards provide customizable visualizations for monitoring your infrastructure, applications, and business metrics in a unified view.
Input parameters
Tags to associate with the dashboard
Dashboard title
List of widgets to include in the dashboard
Dashboard description
Dashboard layout type.
List of users to notify of dashboard changes
Template variables for dynamic dashboards
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_CREATE_DOWNTIMECreates a new downtime in Datadog to suppress alerts during maintenance windows or planned outages. Useful for preventing false alarms during deployments or maintenance.
Input parameters
UNIX timestamp when downtime should end
Scope to apply downtime to (host, service, or monitor tags)
UNIX timestamp when downtime should start. If not provided, starts immediately
Message to include with the downtime
Timezone for the downtime (e.g., 'UTC', 'America/New_York')
Monitor ID to schedule downtime for (optional, can use scope instead)
Downtime recurrence configuration.
Monitor tags to match for downtime
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_CREATE_EVENTCreates a new event in Datadog. Events are useful for tracking deployments, outages, configuration changes, and other important occurrences.
Input parameters
Host name associated with the event
List of tags to associate with the event
Event text/description (supports Markdown)
Event title (limited to 100 characters)
Event priority.
Alert type.
Device name associated with the event
UNIX timestamp when the event occurred. If not provided, current time is used
Key for aggregating events together
Source type name (e.g., 'jenkins', 'docker', 'ansible')
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_CREATE_MONITORCreates a new Datadog monitor to track metrics, logs, or other data sources with configurable alerting thresholds and notifications.
Input parameters
Name of the monitor
List of tags to assign to the monitor
Type of monitor.
Query that defines what the monitor tracks Query syntax must match the monitor `type` exactly — a mismatch will cause creation to fail.
Message to include in notifications (supports @mentions and markdown)
Monitor configuration options.
Priority level (1-5, where 1 is highest)
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_CREATE_SLOCreate a Service Level Objective (SLO) in Datadog. SLOs help you define and track reliability targets for your services, enabling data-driven decisions about service quality and reliability investments.
Input parameters
SLO display name
Tags to associate with the SLO (format: 'key:value')
SLO type.
Query specification for metric-based SLOs.
List of groups for the SLO scope
List of SLO target thresholds
Optional description of the SLO
Monitor IDs for monitor-based SLOs
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_CREATE_SYNTHETIC_API_TESTCreate a synthetic API test in Datadog. Creates a new synthetic API test that continuously monitors API endpoints from multiple locations worldwide. Useful for proactive monitoring of API uptime, performance, and functionality.
Input parameters
Name of the synthetic test
Tags to associate with the test
Type of synthetic test (always 'api' for API tests)
Test configuration including request and assertions
Test status.
Message to include in notifications
Test execution options
Subtype of test.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_CREATE_WEBHOOKCreate a webhook in Datadog. Registers a named destination endpoint; each monitor must explicitly reference the webhook by name in its message or notification settings for alerts to be delivered.
Input parameters
URL endpoint for the webhook Must be a reachable HTTPS endpoint.
Name of the webhook
Custom payload template (optional)
Encoding type: 'json' or 'form'
Custom headers in JSON format (optional)
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_DELETE_DASHBOARDDelete a dashboard in Datadog. Permanently removes a dashboard from your organization. This action cannot be undone. Use with caution.
Input parameters
Dashboard ID to delete
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_DELETE_MONITORDeletes a Datadog monitor permanently. Use with caution as this action cannot be undone.
Input parameters
Force delete the monitor (skip confirmation)
The ID of the monitor to delete
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_GET_DASHBOARDGet a specific dashboard from Datadog. Retrieves detailed information about a dashboard including its widgets, layout, template variables, and metadata.
Input parameters
Dashboard ID to retrieve
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_GET_MONITORRetrieves detailed information about a specific Datadog monitor, including its current state, configuration, and any active downtimes.
Input parameters
The ID of the monitor to retrieve Use DATADOG_LIST_MONITORS to discover valid integer IDs if unknown.
Filter by group states when retrieving monitor details. Valid values: 'all', 'alert', 'warn', 'no data'
Include downtime information in the response
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_GET_SERVICE_DEPENDENCIESGet service dependency mapping from Datadog APM. This action retrieves the dependency graph for a specific service, showing both upstream services (that call this service) and downstream services (that this service calls). It's essential for: - Understanding the blast radius of service failures - Identifying critical dependencies during incidents - Analyzing service communication patterns - Planning architectural changes - Monitoring service health in context The dependency information includes call rates, error rates, and latency metrics to help assess the health of service relationships. Requires APM instrumentation on the target service; uninstrumented services return empty or incomplete dependency data.
Input parameters
Environment to filter by Strongly recommended: omitting this aggregates data across all environments, producing noisy results that obscure meaningful dependency relationships.
The service name to get dependencies for
End time as UNIX timestamp (seconds)
Start time as UNIX timestamp (seconds)
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_GET_SYNTHETICS_LOCATIONSTool to retrieve all available public and private locations for Synthetic tests in Datadog. Use when you need a list of location identifiers for creating or managing synthetic tests.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_GET_TAGSRetrieves all tags associated with a specific host in Datadog. Useful for understanding host metadata and organizing infrastructure.
Input parameters
Source of tags to retrieve (e.g., 'users', 'chef', 'puppet')
Name of the host to get tags from
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_GET_TRACE_BY_IDDEPRECATED: Use DATADOG_SEARCH_TRACES instead. Get detailed information about a specific trace by its ID. This action retrieves comprehensive details about a distributed trace, including all spans, timing information, errors, and metadata. It's essential for: - Deep diving into specific request flows during incidents - Understanding the complete journey of a problematic request - Analyzing performance bottlenecks in detail - Correlating errors across services - Debugging complex distributed system issues The trace ID is typically obtained from logs, error reports, or trace search results. Use targeted time windows to avoid rate limiting; prefer narrow ranges over full 15-day spans when the approximate trace time is known.
Input parameters
End time for the search window. Supports ISO8601, date math (e.g., 'now'), or timestamps in milliseconds. Defaults to current time.
The unique trace ID to retrieve
Start time for the search window. Supports ISO8601, date math (e.g., 'now-1h', 'now-15d'), or timestamps in milliseconds. Defaults to 15 days ago.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_GET_USAGE_SUMMARYRetrieves usage summary information from Datadog including API calls, hosts, containers, and other billable usage metrics. Useful for cost monitoring and usage analysis. Months with no activity return empty payloads on success; absent data is expected, not an error.
Input parameters
End month in YYYY-MM format. If not provided, uses start_month
Start month in YYYY-MM format
Include organization details in the response
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_LIST_ALL_TAGSList all tags from Datadog. Tags help organize and filter your infrastructure and applications. This action shows all tags in use across your organization.
Input parameters
Filter tags by source (e.g., 'chef', 'puppet', 'users', 'datadog')
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_LIST_API_KEYSList API keys in Datadog. Retrieves all API keys in the organization for security auditing, access management, and key rotation planning. Helps maintain security posture by tracking key usage and ownership. Response contains sensitive key metadata (names, owners, last-used timestamps); restrict tool access to authorized personnel and handle output securely.
Input parameters
Sort field.
Number of API keys to return per page (default 20, max 1000)
Page number to retrieve (0-indexed)
ISO timestamp to filter keys created before this time
ISO timestamp to filter keys modified before this time
ISO timestamp to filter keys created after this time
ISO timestamp to filter keys modified after this time
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_LIST_APM_SERVICESList APM services from Datadog. Application Performance Monitoring (APM) provides deep visibility into your applications, helping you track performance, errors, and dependencies.
Input parameters
Environment filter (e.g., 'production', 'staging'). Use '*' to return services across all environments.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_LIST_AWS_INTEGRATIONList AWS integrations in Datadog. Retrieves all configured AWS account integrations, showing which AWS accounts are monitored by Datadog and their configuration settings. Useful for cloud infrastructure management and ensuring comprehensive monitoring coverage.
Input parameters
Filter by specific AWS IAM role name
Filter by specific AWS account ID
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_LIST_DASHBOARDSLists all Datadog dashboards with basic information. Useful for dashboard management and getting an overview of available dashboards.
Input parameters
Maximum number of dashboards to return (for pagination)
Offset for pagination; skip this many dashboards before returning results
Filter dashboards by shared status
Include deleted dashboards in the results
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_LIST_EVENTSLists events from Datadog within a specified time range. Events track important occurrences like deployments, outages, and configuration changes. Combining multiple filters (tags, sources, priority) with narrow time ranges may return empty results even when events exist — start with broad filters and narrow incrementally. Large time ranges with minimal filtering can return very high event volumes; tune tags, sources, and start/end before processing results.
Input parameters
End time as UNIX timestamp
Page number for pagination
Filter by tags
Start time as UNIX timestamp
Filter by event sources (comma-separated)
Filter by event priority.
Get unaggregated events (default: false)
Exclude aggregated events
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_LIST_HOSTSLists all hosts in your Datadog infrastructure with detailed information including metrics, tags, and status. Useful for infrastructure monitoring and management.
Input parameters
Number of hosts to return (max 1000)
Starting position for pagination
Filter hosts by tags or attributes
Sort direction.
Field to sort by.
Start time as UNIX timestamp for host activity
Include hosts metadata in response
Include data for muted hosts
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_LIST_INCIDENTSList incidents from Datadog. Incident Management helps you track, manage, and resolve incidents efficiently with comprehensive timeline and impact tracking.
Input parameters
Sort order for incidents by public ID.
Related resources to include (e.g., 'users,attachments')
Number of incidents per page (1-100, default: 25)
Page offset for pagination (default: 0)
Filter query for incidents (e.g., 'state:active')
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_LIST_LOG_INDEXESTool to retrieve a list of all log indexes configured in Datadog, including their names and configurations. Use before DATADOG_SEARCH_LOGS to identify the correct index name; searching without specifying the right index can hide valid logs and increase usage costs across high-volume indexes.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_LIST_METRICSDiscover metric names by listing actively reporting metrics since a given timestamp. Use when you need to find what metrics exist before querying timeseries data with DATADOG_QUERY_METRICS.
Input parameters
Hostname for filtering the list of metrics returned. If set, metrics retrieved are those with the corresponding hostname tag.
Filter metrics that have been submitted with the given tags. Supports boolean and wildcard expressions (e.g., 'env:prod AND service:api'). Cannot be combined with other filters.
Seconds since Unix epoch. Specifies the starting point for listing actively reporting metrics.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_LIST_MONITORSGet all monitor details. This endpoint allows you to retrieve information about all monitors configured in your organization. You can filter by group states, name, tags, and use pagination to manage large result sets.
Input parameters
Filter monitors by name (substring match)
The page to start paginating from. If this argument is not specified, the request returns all monitors without pagination. Both `page` and `page_size` must be set together to enable pagination; omitting either returns all monitors unpaginated. Iterate through pages (starting at 0) until a page returns fewer than `page_size` results to ensure all monitors are retrieved.
A comma separated list indicating what tags, if any, should be used to filter the list of monitors by scope. For example host:host0.
Monitor ID offset for pagination
The number of monitors to return per page. If the page argument is not specified, the default behavior returns all monitors without pagination. Page size is capped at 100.
When specified, shows additional information about the group states. Choose one or more from Alert, Warn, or No Data.
A comma separated list indicating what service and/or custom tags, if any, should be used to filter the list of monitors. Tags created in the Datadog UI automatically have the service key prepended. For example service:my-app.
If this argument is set to true, then the returned data includes all current downtimes for the monitor.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_LIST_ROLESList roles from Datadog organization. Roles define sets of permissions that control what users can do within your Datadog organization.
Input parameters
Sort field (name, created_at, user_count)
Number of roles per page (1-100, default: 10)
Filter roles by name (partial match)
Page number for pagination (default: 0)
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_LIST_SERVICE_CHECKSLists service checks from Datadog. Service checks are status checks that track the health of your services and infrastructure components.
Input parameters
End time as UNIX timestamp
Filter by tags
Filter by service check name
Start time as UNIX timestamp
Filter by service check status.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_LIST_SL_OSList Service Level Objectives (SLOs) from Datadog. Service Level Objectives help you track the reliability and performance of your services by setting measurable targets for key metrics.
Input parameters
Filter SLOs by tags using a comma-separated list (e.g., 'env:prod,team:backend')
Maximum number of SLOs to return (1-1000, default: 25)
Search query to filter SLOs by name or description
Number of SLOs to skip for pagination (default: 0)
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_LIST_SYNTHETICSList Synthetics tests from Datadog. Synthetics monitoring allows you to proactively monitor your applications and APIs by simulating user interactions and API calls from various locations.
Input parameters
Filter tests by tags using a comma-separated list (e.g., 'env:prod,team:frontend')
Maximum number of tests to return (1-200, default: 50)
Zero-based page number for pagination (default: 0). Page 0 returns first page, page 1 returns second page, etc.
Filter tests by locations using a comma-separated list
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_LIST_USERSList users from Datadog organization. User management allows you to see team members, their roles, and access levels within your Datadog organization.
Input parameters
Sort field (name, email, status, created_at)
Sort direction (asc or desc)
Number of users per page (1-1000, default: 50)
Page number for pagination (default: 0)
Filter by user status (Active, Pending, Disabled)
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_LIST_WEBHOOKSList webhooks from Datadog. Webhooks allow you to send notifications to external services when monitors trigger, enabling integration with your workflows.
Input parameters
Maximum number of webhooks to return (1-100, default: 50)
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_MUTE_MONITORMute a monitor in Datadog. Temporarily silences alerts from a monitor, which is useful during maintenance windows, deployments, or when investigating known issues to prevent alert fatigue.
Input parameters
POSIX timestamp for when the mute should expire (optional, if not specified the monitor remains muted until manually unmuted)
Whether to override existing mute settings
The ID of the monitor to mute
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_QUERY_METRICSQueries Datadog metrics and returns time series data. Useful for retrieving historical metric data, creating custom dashboards, or building reports.
Input parameters
Datadog metrics query string Broad tag filters (e.g., {*}) can return high-cardinality payloads; overly restrictive tag combinations can silently return empty series even when data exists.
End time as UNIX timestamp. Note: Time range cannot exceed 1 year. Must be UTC-based seconds (not milliseconds); non-UTC or millisecond values silently return empty series.
Start time as UNIX timestamp. Note: Time range cannot exceed 1 year. Must be UTC-based seconds (not milliseconds); non-UTC or millisecond values silently return empty series.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_SEARCH_LOGSSearches Datadog logs with advanced filtering capabilities. IMPORTANT NOTES: - Sort parameter is NOT supported by the Datadog Logs API and will cause errors - Time parameters must be in milliseconds (13-digit UNIX timestamps) - Limit parameter is passed as string to the API - Log content is nested under 'content' field in API response Useful for troubleshooting, monitoring application behavior, and analyzing log patterns.
Input parameters
Index name to search in Use DATADOG_LIST_LOG_INDEXES to discover available indexes; an incorrect or omitted index can silently exclude valid logs.
Maximum number of logs to return (max 1000, default 50)
Log search query string
End time as UNIX timestamp (in milliseconds). Note: Time range cannot exceed 15 days.
Pagination cursor for next page (use 'nextLogId' from previous response). IMPORTANT: Cursors expire quickly and can only be used with the exact same query and time parameters they were generated from. If you receive an 'Invalid startAt' error, omit this parameter and start a fresh search. More results are available when nextLogId is present in the response; omitting pagination silently drops those results.
Start time as UNIX timestamp (in milliseconds). Note: Time range cannot exceed 15 days.
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_SEARCH_SPANS_ANALYTICSSearch and analyze span data with aggregations in Datadog. This action uses the Datadog Spans Analytics API to perform advanced queries and aggregations on trace span data. It's essential for: - Analyzing error rates and latency patterns - Understanding service dependencies and bottlenecks - Root cause analysis during incidents - Performance monitoring and optimization The API supports complex queries with grouping, filtering, and various aggregation functions similar to log analytics. The request body must conform to the `aggregate_request` schema; schema violations return "Invalid type. Expected 'aggregate_request'". If `filter` or `compute` cannot satisfy this schema, use basic trace search instead.
Input parameters
Pagination options
Filter criteria for span search
Aggregations to compute
Additional search options
Group by configuration for aggregations
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_SEARCH_TRACESSearch for traces in Datadog APM. This action allows you to search for distributed traces across your services. It's essential for: - Finding specific request flows during incident investigation - Analyzing performance bottlenecks across services - Understanding error propagation through your system - Correlating user requests with backend operations Traces provide the complete picture of a request as it travels through your distributed system, making them crucial for root cause analysis.
Input parameters
Pagination options Check 'meta.page.after' or 'links.next' in the response to detect additional pages; pass the cursor value into 'page.cursor' to retrieve subsequent pages.
Sort configuration for trace search.
Filter criteria for trace search Custom span attributes must be prefixed with '@' (e.g., '@workflow_id'); omitting the prefix silently returns zero results. Use bounded UTC timestamp ranges — wide windows (e.g., 30 days) slow queries and may trigger rate-limit errors. Include 'env' and 'service' fields to avoid broad, noisy result sets.
Additional search options
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_SUBMIT_METRICSSubmits custom metrics to Datadog. Useful for sending application-specific metrics, business KPIs, or custom performance indicators.
Input parameters
List of metric series to submit
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_UNMUTE_MONITORUnmute a monitor in Datadog. Re-enables alerts from a previously muted monitor, returning it to normal monitoring and alerting behavior. Alerting resumes immediately upon call, so ensure maintenance or issue resolution is fully complete before unmuting to avoid alert storms. Use this after maintenance windows or issue resolution to resume monitoring.
Input parameters
Whether to unmute the monitor for all scopes (default: false)
The ID of the monitor to unmute
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_UPDATE_DASHBOARDUpdate a dashboard in Datadog. Updates an existing dashboard with new configuration, widgets, or layout while preserving its identity and creation metadata.
Input parameters
Tags to associate with the dashboard
Dashboard title
List of widgets to include in the dashboard
Dashboard description
Dashboard layout type ('ordered' or 'free')
List of users to notify of dashboard changes
Reflow type for ordered layout dashboards ('auto' or 'fixed'). Forwarded to Datadog only when set so existing values aren't clobbered.
Dashboard ID to update
Whether the dashboard is read-only
Whether automatic refresh is paused for this dashboard. Forwarded to Datadog only when set so existing values aren't clobbered.
Template variables for dynamic dashboards
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_UPDATE_HOST_TAGSUpdates tags for a specific host in Datadog. This replaces all existing tags from the specified source with the new tags provided.
Input parameters
List of tags to assign to the host (replaces existing tags)
Source of the tags (e.g., 'users', 'chef', 'puppet'). Defaults to 'users'
Name of the host to update tags for
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
DATADOG_UPDATE_MONITORUpdates an existing Datadog monitor with new configuration, thresholds, or notification settings. Only specified fields will be updated.
Input parameters
Name of the monitor
List of tags to assign to the monitor
Type of monitor.
Query that defines what the monitor tracks
Message to include in notifications (supports @mentions and markdown)
Monitor update configuration options.
Priority level (1-5, where 1 is highest)
The ID of the monitor to update
Output
Data from the action execution
Error if any occurred during the execution of the action
Whether or not the action execution was successful or not
No publicly available marketplace agent is found using this tool yet. There are 78 agents privately built on Nagent that already use Datadog.
Build on Nagent
Connect Datadog to any Nagent agent in minutes — no API key management, no boilerplate. Just configure and deploy.
The five questions agent builders ask before adopting a new integration.
Open the External Integrations panel inside Nagent (app.nagent.ai/externalIntegration), find Datadog, and click "Connect Now." You'll authenticate with OAUTH2, API_KEY — Nagent handles credential storage and refresh automatically. Once connected, Datadog is available to any agent in your workspace.
No. Nagent provides no-code integration for every tool. Once Datadog is connected, you configure its 43 actions directly in the agent builder UI — no API calls, no boilerplate, no schema management.
Helix — Nagent's agentic agent builder — lets you drop Datadog steps into any workflow visually. Pick an action (e.g., one of those listed above), fill in the inputs (Helix knows the required vs. optional schema for each parameter), and connect it to upstream/downstream steps. Triggers run as the entry point of an agent, so when a Datadog event fires, the agent kicks off automatically.
Every Datadog action and trigger ships with a fully-typed schema — input parameters with name, type, required flag, and description, plus the output payload shape. The schemas are documented in the sections above. Helix uses these schemas to validate your configuration at build time and to type-check the data flowing between steps.
Yes. While Datadog ships with 43 pre-built server monitoring actions, you can layer custom logic around them inside Helix — pre/post-processing steps, conditional branches, retries, or stitching Datadog together with other connected tools. For deeper customization, talk to our team about Nagent's Agentic AI Lab — forward-deployed engineers who build Datadog-based workflows tailored to your business.