Worlds / Eng and it ops

Datadog API

A local Datadog with monitors, alert states, downtimes, dashboards and tags. Test the ops agent that schedules downtime, mutes and tunes monitors without hiding real alerts.

Base path: /api
Auth: API key and application key headers, the world key
Endpoints: 17
Status: Active today

This reference previews the surface the Datadog world serves in the closed beta. Paths mirror the public Datadog API; the exact subset is confirmed when your workflow is scoped.

Connect

The run gives your agent these bindings. Keep your SDK; change only where it sends requests.

binding	meaning
`WORLDS_DATADOG_URL`	This world's origin followed by `/api`
`WORLDS_API_KEY`	The world key, accepted wherever Datadog expects a credential
`WORLDS_WORLD_ID`	The isolated world's identity

js · @datadog/datadog-api-client

import { client, v1 } from "@datadog/datadog-api-client";

const configuration = client.createConfiguration({
  authMethods: {
    apiKeyAuth: process.env.WORLDS_API_KEY,
    appKeyAuth: process.env.WORLDS_API_KEY,
  },
});
configuration.setServerVariables({ site: process.env.WORLDS_DATADOG_URL });

const monitors = await new v1.MonitorsApi(configuration).listMonitors();

API reference

17 of 17

Monitors

Alert rules with query, thresholds and state.

GET/api/v1/monitorList monitors
POST/api/v1/monitorCreate a monitor
GET/api/v1/monitor/{monitor_id}Get a monitor
PUT/api/v1/monitor/{monitor_id}Edit a monitor
POST/api/v1/monitor/{monitor_id}/muteMute a monitor

Fields · 6

`id`	integer	Monitor id
`name`	string	Name
`type`	string	metric alert, log alert, service check and more
`query`	string	Monitor query
`overall_state`	string	OK, Alert, Warn or No Data
`tags`	array	Tags

Metrics

Time series you can query and submit.

GET/api/v1/queryQuery time series points
POST/api/v2/seriesSubmit metrics
GET/api/v1/metricsList active metrics

Fields · 4

`metric`	string	Metric name
`points`	array	Timestamp and value pairs
`tags`	array	Tags
`type`	string	gauge, count or rate

Events

Posted and monitor generated events.

GET/api/v1/eventsQuery the event stream
POST/api/v1/eventsPost an event
GET/api/v1/events/{event_id}Get an event

Fields · 5

`id`	integer	Event id
`title`	string	Title
`text`	string	Body
`alert_type`	string	error, warning, info or success
`tags`	array	Tags

Logs

Searchable log lines from your services.

POST/api/v2/logs/events/searchSearch logs
GET/api/v2/logs/eventsList logs
POST/api/v2/logsSend logs

Fields · 5

`id`	string	Log id
`message`	string	Log message
`service`	string	Service
`status`	string	Log level
`timestamp`	datetime	Time of the log

Incidents

Declared incidents with severity and timeline.

GET/api/v2/incidentsList incidents
POST/api/v2/incidentsCreate an incident
PATCH/api/v2/incidents/{incident_id}Update an incident

Fields · 5

`id`	string	Incident id
`title`	string	Title
`state`	string	active, stable or resolved
`severity`	string	SEV-1 through SEV-5
`commander`	object	Incident commander

Test workflow

Prepare. Select the Datadog setup for your workflow and review its starting records, including monitors, metrics, events.
Connect. Configure your agent with this world's URL and key using the SDK example. Check that it reaches the intended API before running a test.
Define. Describe the task, expected final changes and records that must stay untouched. Keep expected outcomes separate from the agent's instructions.
Run and inspect. Use the dashboard or your workflow's generated CLI setup. Review final records and changes, then rerun from the same starting setup with the relevant failure conditions. Use Deployment and CI to automate the same workflow.

What to verify

One downtime with scope service:checkout
Window Saturday 02:00 to 04:00
Payments error rate not muted
Disk usage db-2 still alerting
No thresholds changed

Test file

A task file names the jobs, the policy your agent is given and what the grader reads back from the world's final state. The agent never sees the expected outcomes.

yaml · worlds/tasks.yaml

# worlds/tasks.yaml · Datadog
version: 2
connector: datadog
seed: datadog-starter
mode: isolated
policy: >
  Schedule downtime for the checkout maintenance on Saturday 02:00 to 04:00.
  Scope it to service:checkout only. Leave every other alert active.
tasks:
  - id: schedule-downtime-for-a-maintenance-window-by-scope
    prompt: Schedule downtime for a maintenance window by scope
  - id: mute-a-noisy-monitor-and-open-a-follow-up
    prompt: Mute a noisy monitor and open a follow-up
  - id: adjust-monitor-thresholds-after-an-alert-review
    prompt: Adjust monitor thresholds after an alert review
expected:
  - "One downtime with scope service:checkout"
  - "Window Saturday 02:00 to 04:00"
  - Payments error rate not muted
  - Disk usage db-2 still alerting
  - No thresholds changed
scenarios:
  - rate-limited
  - missing-scope
  - invalid-query

See Tasks and outcomes for every field, and Deployment and CI to run the file on every pull request.

Failure conditions

Each one fires before the handler, at the same step on every run.

condition	what the agent sees
`rate-limited`	The API returns 429 with X-RateLimit-Reset
`missing-scope`	The application key lacks monitors_downtime and gets 403
`invalid-query`	A bad monitor query returns 400
`restricted-monitor`	Editing a role-restricted monitor returns 403

Starting data

Start each run from the same records and relationships. The overview below describes the Datadog starter; use the setup supplied for your workflow when preparing your own snapshot.

Records	Starting setup
monitors	60 metric, log and synthetics monitors
states	OK, Warn, Alert and No Data across services
downtimes	Active and scheduled downtimes with scopes
tags	env, service and team tags on every monitor
dashboards	Service overview dashboards with linked monitors

The record shapes below reuse this world's API field definitions. They show illustrative values and placeholders, not an importable seed. API responses and seed input can differ; include all required records and references in the accepted import format for your workflow.

Monitors records

Monitors

Alert rules with query, thresholds and state.

Field	Type	Meaning / relationship
`id`	integer	Monitor id
`name`	string	Name
`type`	string	metric alert, log alert, service check and more
`query`	string	Monitor query
`overall_state`	string	OK, Alert, Warn or No Data
`tags`	array	Tags

json · illustrative record shape

{
  "id": 1,
  "name": "<Name>",
  "type": "<metric alert, log alert, service check and more>",
  "query": "<Monitor query>",
  "overall_state": "<OK, Alert, Warn or No Data>",
  "tags": []
}

See monitors operations

Metrics records

Metrics

Time series you can query and submit.

Field	Type	Meaning / relationship
`metric`	string	Metric name
`points`	array	Timestamp and value pairs
`tags`	array	Tags
`type`	string	gauge, count or rate

json · illustrative record shape

{
  "metric": "<Metric name>",
  "points": [],
  "tags": [],
  "type": "<gauge, count or rate>"
}

See metrics operations

Events records

Events

Posted and monitor generated events.

Field	Type	Meaning / relationship
`id`	integer	Event id
`title`	string	Title
`text`	string	Body
`alert_type`	string	error, warning, info or success
`tags`	array	Tags

json · illustrative record shape

{
  "id": 1,
  "title": "<Title>",
  "text": "<Body>",
  "alert_type": "<error, warning, info or success>",
  "tags": []
}

See events operations

Logs records

Logs

Searchable log lines from your services.

Field	Type	Meaning / relationship
`id`	string	Log id
`message`	string	Log message
`service`	string	Service
`status`	string	Log level
`timestamp`	datetime	Time of the log

json · illustrative record shape

{
  "id": "<Log id>",
  "message": "<Log message>",
  "service": "<Service>",
  "status": "<Log level>",
  "timestamp": "<Time of the log>"
}

See logs operations

Incidents records

Incidents

Declared incidents with severity and timeline.

Field	Type	Meaning / relationship
`id`	string	Incident id
`title`	string	Title
`state`	string	active, stable or resolved
`severity`	string	SEV-1 through SEV-5
`commander`	object	Incident commander

json · illustrative record shape

{
  "id": "<Incident id>",
  "title": "<Title>",
  "state": "<active, stable or resolved>",
  "severity": "<SEV-1 through SEV-5>",
  "commander": {}
}

See incidents operations

See the Datadog world in the catalog