Reports whether the Dynatrace Bridge is usable: server version and whether a newer release exists, whether the browser extension is connected and its version (each browser when several are connected), and the Dynatrace environments configured in the extension (name, environment id, URL).

Call this first when another Dynatrace tool fails with a connection, environment or session error, or when the user asks which environments are available. Works even when no extension is connected. Pass check_session: true to also run one small request per environment and see whether the browser is still logged in.

Where to start with the other tools. All take environment. All except get_problem, find_metrics, list_dashboards and read_settings also take the time arguments minutes_lookback / time_from / time_to (timestamps without a zone are read as UTC); those four have no time window.

• An incident, or "what is wrong": list_problems, then get_problem with the P- id.

• A slow or failing service: list_services (sort: "response_time" or "failure_rate") to find it, service_overview, then analyze_response_time or analyze_failures, then list_traces and get_trace for single requests.

• Across all services, trace_statistics with request_kind: "web" and: slowest endpoints aggregation: "P95" (or "AVERAGE") plus min_calls: 20; most time-consuming endpoints aggregation: "SUM"; most CPU metric: "CPU_TIME", aggregation: "SUM"; most errors metric: "FAILED_REQUEST_COUNT" (a count metric, ranked by its COUNT).

• Exceptions: top_exceptions. Slow or expensive SQL: top_database_statements. Slow or long-running cron jobs: cron_job_statistics.

• Pod restarts, OOM kills, throttling: list_workloads, then pod_resources and pod_events. CPU or memory of a process: cpu_by_process_group, method_hotspots, process_runtime.

• Anything else: find_entities for ids, find_metrics and query_metrics for the data behind any chart.

Searches Dynatrace monitored entities of any type and returns their ids and names. Use it to turn a name the user mentions into the entity id that other tools need, or to list what exists (services, hosts, process groups, Kubernetes workloads, pods, containers, queues, …).

Give type (e.g. SERVICE, HOST, PROCESS_GROUP, PROCESS_GROUP_INSTANCE, CLOUD_APPLICATION (Kubernetes workload), CLOUD_APPLICATION_INSTANCE (pod), CONTAINER_GROUP_INSTANCE (container), KUBERNETES_CLUSTER, KUBERNETES_NODE, QUEUE) and optionally name (case-insensitive substring). For anything more specific pass a full Dynatrace selector (entitySelector syntax), e.g. type(CLOUD_APPLICATION_INSTANCE),fromRelationships.isInstanceOf(entityId("CLOUD_APPLICATION-1234567890ABCDEF")) for the pods of a workload, or type(SERVICE),tag("team:checkout"). Called with neither type nor selector, it lists the entity types that exist in the environment.

Only entities seen inside the time window are returned. Add fields (e.g. tags, managementZones, properties.cloudApplicationInstancePhase, fromRelationships.runsOn) for extra columns. Follow up with get_entity for all properties and relationships of one entity.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Returns one Dynatrace entity in full: type, first/last seen, tags, management zones, all properties (for pods: phase, node, restarts, requests/limits; for services: technology, type; for hosts: OS, CPU, memory, …) and its relationships to other entities with their ids and names (runs on, calls, called by, is instance of, …).

Pass entity as an id (e.g. SERVICE-1234567890ABCDEF) or as a name together with type. An ambiguous name returns the candidates. Use the related ids with get_entity again to walk the topology, or in query_metrics entity selectors.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Searches the Dynatrace metric catalogue and returns metric ids with unit, available aggregations, dimensions and the entity types they apply to. Use it before query_metrics whenever you are not sure of the exact metric id.

Pass text for a free-text search over id, name and description (e.g. "response time", "container memory", "v8 heap"), and/or selector for an id pattern with a trailing wildcard (e.g. builtin:service.*, builtin:containers.cpu.*, builtin:kubernetes.workload.*, builtin:tech.jvm.*, builtin:tech.nodejs.*).

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Runs a Dynatrace metric query (the data behind any chart) and returns each series summarised: min, avg, max with its timestamp, last value, trend, and a compact table of values over time. Values are converted to readable units (µs → ms/s, bytes → MiB/GiB) from the unit of the metric descriptor; when Dynatrace names no unit, or the descriptor cannot be read, the values are printed raw and the output says so. The descriptor describes the plain metric, so after a transformation that changes the unit (:rate, :count, arithmetic) read the numbers with that in mind.

selector uses the Dynatrace metric selector language: a metric id plus optional transformations, e.g.

• builtin:service.response.time:percentile(95)

• builtin:service.errors.total.rate:splitBy("dt.entity.service"):sort(value(avg,descending)):limit(10):names

• builtin:containers.memory.residentSetBytes:splitBy("dt.entity.container_group_instance"):max:names Several selectors can be given comma-separated. Append :names so entity names are shown next to their ids. Find metric ids with find_metrics.

Scope to entities with entity_selector (entitySelector syntax), e.g. entityId("SERVICE-1234567890ABCDEF") or type(HOST),entityName.contains("web"). resolution sets the point spacing (1m, 5m, 1h, 1d, or Inf for a single value over the window); by default Dynatrace picks one that fits the window.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Lists the services Dynatrace monitors with their key numbers for the time window: average and p90 response time, failure rate, request count and requests per minute. Use it to find a service id, to see which services are slow, failing or busy, and as the starting point of any service investigation.

Filter with name (case-insensitive substring), service_type (WEB_REQUEST_SERVICE, WEB_SERVICE, DATABASE_SERVICE, BACKGROUND_ACTIVITY, CUSTOM_SERVICE, …; a part such as "database" is enough), technology (Java, Node JS, Nginx, Apache, SQL Server, …) and tag (exactly as Dynatrace shows it, case-sensitive: key:value, or key for a tag without a value). sort picks the ranking: throughput (default), response_time, p90, failure_rate (all highest first) or name.

Start here for "which services are slow / failing / busy": sort: "response_time", "failure_rate" or "throughput". Several services can share one name (one per process group); the ids tell them apart. Follow up with service_overview for one service.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Everything about one service in one call: type, technology, tags and properties; response time p50 / p90 / p99 / average, failure rate and throughput for the window, with a compact trend over time; the services it calls and the services that call it; the process groups, hosts, Kubernetes workloads and pods it runs on; and the Dynatrace problems that affected it in the window.

Pass service as an id (SERVICE-1234567890ABCDEF) or a name; an ambiguous name returns the candidates. Find services with list_services. Then drill down with the same service and time window: list_service_requests (its endpoints), list_traces (individual requests), analyze_failures, analyze_response_time, service_flow (downstream), service_backtrace (upstream), and get_problem for a listed problem.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Lists Dynatrace events in a time window: deployments, process restarts, Kubernetes events (probe failures, kills, scheduling), availability and anomaly events (error rate or response time increase, CPU saturation), custom info and annotations. Identical events (same type, title, entity and Kubernetes reason) are collapsed into one row with a count and the first and last time, so a flapping probe is one line.

Scope it with entity_selector (entitySelector syntax, e.g. entityId("SERVICE-1234567890ABCDEF"), type(CLOUD_APPLICATION_INSTANCE),fromRelationships.isInstanceOf(entityId("CLOUD_APPLICATION-1234567890ABCDEF")) for the pods of a workload, type(HOST)), event_type (e.g. CUSTOM_DEPLOYMENT, PROCESS_RESTART, SERVICE_ERROR_RATE_INCREASED, CUSTOM_INFO) and status (open / closed). event_selector takes a raw Dynatrace eventSelector instead, e.g. property.dt.kubernetes.event.reason("Unhealthy"). Without any filter it lists every event of the environment in the window.

Use it to answer "what changed" around the time something broke; then get_entity or service_overview on an entity id, or list_problems for the same window.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Lists the problems Dynatrace (Davis) raised that were active in the time window: display id (P-…), internal problem id, title, severity, impact level, status, start, end, duration, root cause entity and how many entities were affected and impacted.

Filter by status (open / closed / all), impact_level (SERVICES, INFRASTRUCTURE, APPLICATION, ENVIRONMENT), severity (AVAILABILITY, ERROR, PERFORMANCE, RESOURCE_CONTENTION, CUSTOM_ALERT, …), entity_selector (e.g. entityId("SERVICE-1234567890ABCDEF") or type(HOST)) and text (case-insensitive, matched against id, title and entity names). An open problem that started before the window is included.

Start here for "what is wrong right now" or "what happened at that time". Follow up with get_problem (pass the P- id) for evidence, Davis root cause and the dependency path.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Returns one Dynatrace problem. The default output is a compact overview: status, severity, start, end and duration; root cause entity, affected and impacted entities; the evidence grouped by entity with counts and the most relevant items; the impact; the Davis root-cause findings per candidate entity with the metric and event names; the event that triggered the problem with its baseline values; the most affected requests per service with their SERVICE_METHOD ids; and the entities on the dependency path Davis analysed that are affected, root cause or have events.

Pass problem as the display id (P-12345) or the internal problem id from list_problems. For the long form of one section pass detail: evidence (every evidence row), impact, davis (all candidates and findings), requests (the affected requests of every service) or path (the whole dependency path with event times). The Davis findings, trigger event and dependency path come from internal Dynatrace endpoints; if one of them is unavailable the rest is still returned with a note.

The result ends with the affected service id and the problem window to pass to analyze_failures and list_traces.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Lists Kubernetes workloads (deployments, stateful sets, daemon sets, jobs; Dynatrace entity type CLOUD_APPLICATION) with workload type, namespace, cluster, running versus desired pods, and average CPU and memory usage against the configured requests and limits over the window.

Filter with name (case-insensitive substring), namespace (exact) and cluster (cluster name or KUBERNETES_CLUSTER id). Use it to find the workload id that list_pods, pod_resources, pod_events and process_runtime take, or to spot workloads running close to their limits.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Lists Kubernetes pods (Dynatrace entity type CLOUD_APPLICATION_INSTANCE) of a workload, or pods matching a name, with phase, node, IPs, restart count, age, CPU / memory requests and limits, and the containers in each pod with their ids.

Pass workload (id or name, from list_workloads) and/or name (substring of the pod name). Follow up with pod_resources for usage over time, pod_events for Kubernetes events, or process_runtime with a pod id for JVM / Node.js metrics.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Shows the resource behaviour of the pods of a Kubernetes workload, or of one pod, over the time window: CPU usage, CPU throttling, memory (resident set per container, working set for the workload, usage in % of the limit), OOM kills and container restarts, per pod and per container, each as a summarised series (min / avg / max with its time / last / trend and a compact table over time).

Start here for "why does this pod restart / get OOM-killed / run slow": it opens with findings that flag obvious trouble: usage near the limit, significant CPU throttling, OOM kills, restarts inside the window, pods not running. Pass exactly one of workload or pod (id or name; find workloads with list_workloads). Narrow the window around a peak with time_from / time_to, then check pod_events for what Kubernetes did at that time and process_runtime for the JVM / Node.js view.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Lists the Kubernetes events Dynatrace recorded for the pods of a workload and for the workload itself (or for one pod): readiness / liveness probe failures, container kills and back-offs, scheduling and image pull problems, mount failures, deployment spec changes. Identical events are collapsed by reason and message, with a count and the first and last time, newest first.

Pass exactly one of workload or pod (id or name). Use it after pod_resources shows restarts, OOM kills or a pod that is not running, with the window narrowed to that time.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Reports runtime metrics of the processes (Dynatrace PROCESS_GROUP_INSTANCE) running in a pod, a workload or a process group, or of one process. The technology is detected per process: JVM processes get heap usage, heap max, memory pools, GC suspension and GC time, and thread count; Node.js processes get V8 heap used / total, RSS, event loop utilization and latency; every process gets CPU usage and working set memory. Each metric is a summarised series (min / avg / max with its time / last / trend, and a table over time for the main ones).

Pass exactly one of pod, workload, process_group or process (id or name). Use it when pod_resources shows memory growth or CPU saturation and you need to know whether heap, GC or the event loop is the cause. Follow up with get_process for callers, callees and hosted services.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Returns one host in detail: OS, CPU cores and memory, IPs, monitoring mode, availability and downtimes, open problems; CPU and memory usage over the window as summarised series and disk usage per disk; the processes running on it with their technology, status, CPU and memory use; and its recent events.

Pass host as a HOST id or a host name (an ambiguous name returns the candidates). Kubernetes nodes are hosts too: the node name from list_pods works here. Follow up with get_process on a process id, or query_metrics with entity_selector: entityId("<host id>") for any other builtin:host.* metric.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Returns one process (PROCESS_GROUP_INSTANCE) or one process group (PROCESS_GROUP) in detail: technology and version, the host, pod, container and workload it runs in, the services it hosts, the processes that call it and that it calls, CPU and memory use over the window, and its events.

Pass process as a PROCESS_GROUP_INSTANCE id, a PROCESS_GROUP id, or a name (an ambiguous name returns the candidates with their ids). Process ids come from get_host, process_runtime or find_entities. Follow up with process_runtime for JVM / Node.js metrics, or the service tools with a service id from the list.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Lists what one service does, with metrics per row: call count, average / median / p90 / max response time, total time, failure rate and HTTP 4xx / 5xx counts. For a web or method service the rows are its requests (endpoints, jobs); for a database service they are its SQL statements; for a "Requests to unmonitored hosts" service they are the target hosts.

Use it to see which endpoint of a service is slow (sort: "avg" or "p90"), costs the most time ("total_time", the default), is called most ("calls") or fails ("failure_rate"). For the same question across all services use trace_statistics; for cron jobs cron_job_statistics. Every row prints its id and name; the other tools take either one as request. The shared filter arguments narrow the requests that are counted, e.g. response_time_min_ms: 2000 or failed: true. service is an id or a name; find services with list_services.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Lists individual traces (PurePaths): the requests of one service, or of the whole environment when service is omitted. Use it to find concrete slow or failed requests, then open one with get_trace.

Filters: response time range, HTTP code or class, failed state, HTTP method, one request (request: name or id, with service), a request group, URL text (url_contains, web requests only, works without service), request kind, plus raw_filters. Per trace: start time, request name, method + URL, HTTP code, failed flag, response / CPU / wait / suspension time, database call count and time, downstream service calls, exception classes, request attributes (secret-looking ones masked), and the traceId + callURI that get_trace needs.

Dynatrace returns the newest matching traces (fetch_limit of them, 100 by default, at most 3000); this tool then sorts those and prints limit of them (25 by default, at most 100). So "slowest" means the slowest among the fetched newest traces: when the output says Dynatrace returned its limit, narrow the window or the filters (e.g. response_time_min_ms) or raise fetch_limit. Default order: slowest first when a response time filter is given, newest first otherwise. A warning line appears when the window is only partly covered or traces are sampled.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Multidimensional analysis over traces: aggregates one metric over all matching requests, split by one dimension, across all services or for one. The tool for "which endpoints are the slowest / cost the most time / burn the most CPU / fail the most".

Recipes (the metric defaults to RESPONSE_TIME and the dimension to the request name {Request:Name}; add request_kind: "web" to rank HTTP endpoints only, because without it SQL statements dominate an environment-wide ranking; add service for one service):

• slowest endpoints: aggregation: "P95" (or "AVERAGE", the default for time metrics) with min_calls: 20, so that requests seen once or twice do not win;

• most time-consuming endpoints: aggregation: "SUM";

• most CPU: metric: "CPU_TIME", aggregation: "SUM";

• most errors: metric: "FAILED_REQUEST_COUNT" (or HTTP_5XX_ERROR_COUNT), a count metric, ranked by its COUNT by default;

• by something else: dimension: "{Relative-URL}", "{HTTP-Status}", "{Exception:Class}", "{Service:Name}", or a request attribute as "{RequestAttribute:<name>}".

list_definitions: true lists the metrics, dimensions and request attributes this environment has. aggregation picks the column the rows are ranked by; the header names it. The table shows every aggregate Dynatrace returns. For a time metric these are requests (the number of requests), avg, median, p90, p95, the chosen percentile, max, min and sum. For a count metric (Dynatrace returns a COUNT for it) they are printed under Dynatrace's own names, COUNT, COUNT_PER_MINUTE, LOAD, AVERAGE, MIN, MAX, with a line saying what is known about them. timeseries: true adds the top values over time. Each row prints the request id and, without service, the service it belongs to. Dynatrace returns at most its top 100 values, those with the largest total (sum, or COUNT for a count metric), and leaves out values with too few sampled requests. Ranking by anything else (avg, p95, max, …) re-sorts only those 100, so a rarely called slow request outside them is missing; the output says when that happened.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Shows one trace as an indented span tree: for every call the service, the operation (request name or SQL statement), how often it ran, its start offset from the beginning of the trace, response time, self time, CPU / wait / suspension time, the technology, and the callURI of the node.

Pass trace_id and call_uri exactly as printed by list_traces, with a time window that contains the trace (the same window is fine). Runs of identical sibling calls (the same SQL statement 200 times) are collapsed into one line with the call count and total time. Large traces: min_duration_ms hides calls shorter than that, max_depth limits the nesting, limit caps the lines; the output always says what was hidden. Follow up with get_trace_details on a node's callURI for exceptions with stack traces, the code-level method tree, full SQL and HTTP headers.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Everything Dynatrace recorded about one call (node) of a trace: exceptions with stack traces (identical ones grouped into one entry with a count), the code-level method tree with total / self / CPU / wait time pruned to the hot paths, the downstream calls it made with SQL text and call counts, the full SQL of a database call, HTTP request and response headers and parameters, the process and host / pod it ran on, and the technologies involved.

Pass call_uri of a node as printed by get_trace (or by list_traces for the entry call), with a time window that contains the trace. Stack traces show the top stack_frames frames (full_stack: true for all) of the exception_limit most frequent distinct exceptions. Every section has its own share of the output, so a long one cannot crowd out the others. The method tree hides methods below min_method_ms (default 1 % of the call) and pass-through frames, and says how many. Authorization, cookie and token headers are never shown; request parameters, headers and attributes whose name looks like a secret (password, token, key, session id, …) or whose value looks like a credential are printed as <masked>, as are such parameters inside URLs; ordinary parameters are shown as Dynatrace stored them (Dynatrace itself may already have replaced values by <masked>).

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Explains why requests of a service fail in a time window (Dynatrace failure analysis): the failure reasons ranked by failed requests, each with its type, HTTP status, share of all failures, the exception classes and messages behind it (with the top stack frames), failed downstream calls, and the requests it affects.

Start here for "why does this service fail": use it when a service shows a failure rate or a problem names it. Pass service as an id or a name. The shared trace filters (response_time_min_ms, response_time_max_ms, http_code, failed, http_method, request, request_group_id, url_contains, request_kind, raw_filters) narrow the analysed requests. Follow up with list_traces (failed: true, optionally http_code) for the individual failing traces, or top_exceptions for exception counts.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Shows where the response time of a service goes and how it is distributed (Dynatrace response time analysis). Part 1, hotspots: average response time split into own code, calls to other services and database calls; code execution time by state (CPU, wait, lock, network and disk I/O, suspension); every downstream service and database with its contribution, call frequency and call time; and the single downstream requests / SQL statements that cost the most. Part 2, distribution: a text histogram of response times including failed requests, with the outlier tail called out.

Start here for "why is this service (or one of its endpoints) slow". Pass service as an id or a name. The shared trace filters (response_time_min_ms, response_time_max_ms, http_code, failed, http_method, request, request_group_id, url_contains, request_kind, raw_filters) narrow the analysed requests. E.g. response_time_min_ms: 2000 analyses only the slow requests, request one endpoint. It runs two analysis requests, one after the other. Follow up with service_flow for the full downstream tree, top_database_statements on a database listed here, method_hotspots for own-code time, or list_traces with response_time_min_ms for the outliers.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Shows what a service calls (Dynatrace service flow): the downstream call tree of services, databases and external hosts as an indented tree. Each node has its contribution to the response time of the analysed service, the share of requests that make the call, calls per calling request, average time per call, call count and failed calls.

Use it to see which dependency a slow or failing service spends its time in. Pass service as an id or a name; max_depth limits how many call levels are followed. The shared trace filters (response_time_min_ms, response_time_max_ms, http_code, failed, http_method, request, request_group_id, url_contains, request_kind, raw_filters) narrow the analysed requests. Follow up with analyze_response_time or service_flow on a downstream id, top_database_statements on a database node, or service_backtrace for the opposite direction.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Shows who calls a service (Dynatrace service backtrace): the upstream caller tree, level by level, up to the services where the requests enter (web entry points, background tasks, cron jobs). Each caller has the number of its requests involved, the resulting calls into the analysed service, how many of its requests start there, and its top calling requests with their SERVICE_METHOD ids.

Use it to find which upstream service, endpoint or job causes the load or the failures on a service or database. Pass service as an id or a name. The shared trace filters (response_time_min_ms, response_time_max_ms, http_code, failed, http_method, request, request_group_id, url_contains, request_kind, raw_filters) narrow the analysed requests. E.g. request backtraces one endpoint, failed: true only the failed calls. For one SQL statement use statement_callers. Follow up with list_traces on a caller with request set to a calling request.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Ranks the exception classes thrown in traced requests (Dynatrace multidimensional analysis "Exceptions overview"): per class the number of exceptions, Dynatrace's LOAD, AVERAGE and MAX aggregates of the exception count (read as: requests that had the exception, average and maximum per such request; that reading is not verified, so the columns keep Dynatrace's names), and, when no service is given, the services that throw it most with their ids.

Start here for "which exceptions occur most". Call it without service for the whole environment, or with service (id or name) for one service. The shared trace filters (response_time_min_ms, response_time_max_ms, http_code, failed, http_method, request, request_group_id, url_contains, request_kind, raw_filters) narrow the analysed requests. Follow up with analyze_failures on a service that throws the exception (not every exception fails a request), or list_traces with raw_filters: [{ type: "EXCEPTION", values: ["<class>"] }] for traces containing it.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Ranks cron jobs by how much time they take: per job the number of executions, failed runs, total time, average and longest run and CPU time, with the service and request ids needed to open single runs. The tool for "which cron jobs are the slowest / the most time-consuming / fail".

It reads the requests of the service whose requests are the cron jobs. SAP Commerce (hybris) environments have such a service named CronJobs, the default for service; Dynatrace usually has several services with that name (one per process group or node), and this tool combines all of them, which a single list_service_requests call cannot. Pass another service name or one SERVICE id as service when the jobs live elsewhere. When no such service exists the tool says so and names the alternatives. The default window is the last 24 hours. sort: total_time (default), avg, max, executions, failures, cpu. name keeps jobs whose name contains the text; response_time_min_ms and failed count only the long or the failed runs. A run is one trace and is counted with its full duration (verified for runs of over an hour); runs still executing at the end of the window may be missing. A row named after a method instead of a job (ServicelayerJob.performCronJob) collects the runs Dynatrace could not name; the output marks it. Follow up with list_traces (service and request from the last column) for the single runs, then get_trace for what a run did.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Lists the SQL statements of a database ranked by cost: per statement the total time spent, the average, median, 95th percentile and slowest execution, the number of executions, and the statement id (SERVICE_METHOD-…). The tool for "which SQL is slow / expensive".

Pass service as the id or name of a database service. Dynatrace often has several database services with one name (one per calling process group): pass the name and their statements are combined by statement text in one table, with the service and statement id pairs each follow-up tool needs; pass an id for one of them alone. Combining costs two analysis requests whatever the number of services. Called without service, it lists the database services. sort ranks by total_time (default), avg, max, p95 or executions. Dynatrace returns at most its 100 statements with the largest total time, so the other sorts re-order only those and the output says so when statements were cut: a rare slow statement can be missing from "slowest". SQL text is cut to a readable length; pass full_sql: true for the whole text. The shared trace filters (response_time_min_ms, response_time_max_ms, http_code, failed, http_method, request, request_group_id, url_contains, request_kind, raw_filters) narrow the analysed requests. Follow up with statement_callers (which services, requests and cron jobs issue a statement) and slow_statement_executions (its slow executions with the calling traces), passing the same service and the statement id as statement.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Finds what causes one SQL statement (Dynatrace backtrace of a database service filtered to the statement): the services that execute it, the exact requests, background tasks and cron jobs behind those services with their SERVICE_METHOD ids, and for each the number of requests and of resulting executions, followed by the upstream caller tree.

Pass service (the database service, id or name) and statement (id from top_database_statements, or a part of the SQL text). The shared trace filters (response_time_min_ms, response_time_max_ms, http_code, failed, http_method, request, request_group_id, url_contains, request_kind, raw_filters) narrow the analysed requests. E.g. response_time_min_ms backtraces only the slow executions. Follow up with slow_statement_executions for single slow executions, or list_traces with service set to a caller id and request to a calling request.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Lists the slow executions of one SQL statement on a database service, slowest first: start time, duration, rows returned, fetches, and the traceId and callURI of the trace each execution belongs to.

Pass service (the database service, id or name), statement (id from top_database_statements, or a part of the SQL text) and optionally response_time_min_ms (default 100). The shared trace filters (response_time_min_ms, response_time_max_ms, http_code, failed, http_method, request, request_group_id, url_contains, request_kind, raw_filters) narrow the analysed requests. Follow up with get_trace, passing the traceId and callURI of a row as trace_id and call_uri, to see the request that issued the statement and everything else it did.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Lists the process groups that consumed the most CPU in the window (Dynatrace continuous CPU profiling): CPU time, share of the total, CPU time spent in garbage collection, when the peak was, and which deeper analyses each process group supports.

Start here for "which process burns the CPU". Follow up with method_hotspots (hot methods), thread_analysis (thread groups and states) or memory_allocation_hotspots, passing the PROCESS_GROUP id from the table as process_group. For CPU per endpoint use trace_statistics with metric: "CPU_TIME".

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Shows which methods a service or process group spends its time in, from Dynatrace code-level stack samples: sample share per API (framework / library group) and per thread state, then the hot methods.

view: "flat" (default) ranks methods by self share (samples where the method itself was on top of the stack) and also gives the total share including callees. view: "tree" prints the call tree from the thread entry points downwards, pruned to branches above min_share_percent. By default only active states are counted (running on CPU, locking, network and disk I/O); include_waiting: true adds waiting threads.

Pass exactly one of service or process_group (id or name; ids come from list_services, trace_statistics or cpu_by_process_group). Numbers are stack samples, not milliseconds; compare shares. Follow up with thread_analysis for the thread groups behind the samples.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Analyses the threads of a process group (Dynatrace continuous thread analysis): how many threads are in each state (running, locking, network I/O, disk I/O, optionally waiting), and the thread groups ranked by CPU time with their average thread count and state samples.

Use it to see whether a process is CPU-bound, blocked on locks or stuck in I/O, and which thread pool is responsible. state keeps only thread groups seen in that state and ranks by it (e.g. LOCK for lock contention). Follow up with method_hotspots on the same process group for the methods.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Shows where a process group allocates memory (Dynatrace continuous memory profiling, Java): total allocated and surviving bytes, allocation per API, the methods that allocate the most with their main callers and object types, and the most allocated types.

Use it for high garbage-collection time or memory growth. survivors_only: true restricts to objects that survived a garbage collection (candidates for leaks and heap growth). The default window is the last 15 minutes because Dynatrace answers with a very large call tree for busy process groups; keep the window short. When memory profiling is not enabled or not supported for the process group, or the answer is too large to relay, the tool says so and what to do. cpu_by_process_group lists memory for the process groups that support it.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Lists the process crashes Dynatrace detected in the window: time, crashed process, host or pod, and the signal or exception, with entity ids for follow-up. The field layout of this internal endpoint is not verified: the columns are matched by field name, and every field that was not recognised is printed under details, so nothing is hidden.

Use it when a service became unavailable, a pod restarted, or a problem mentions a crash. Follow up with get_process / get_host on the ids, pod_events for Kubernetes restarts, or list_problems for the same window.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Lists the Dynatrace dashboards visible to the user: id, name, owner, last modification and tags. Filter with text (matches name, owner and tags).

Follow up with get_dashboard (id or name) to see the tiles and the metric selectors behind the charts.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Shows one Dynatrace dashboard: owner, tags and every tile with its type and title, and for chart (Data Explorer) tiles the metric selectors behind them, so the same data can be read with query_metrics.

dashboard is an id from list_dashboards or a name (an ambiguous name returns the candidates). Reading the queries of a chart tile costs one request to Dynatrace per tile, so only the first tile_details chart tiles (12 by default, at most 30) get their queries; the others are listed without them, and the output names the tile ids to pass as tile to read those next. run_queries: true executes up to max_queries of the tile selectors over the time window and prints each as summarised series.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.

Reads Dynatrace configuration (Settings 2.0), read-only: alerting profiles, anomaly detection thresholds, failure detection rules, request attributes, naming rules, maintenance windows and every other settings schema.

Without schema it lists the settings schemas; narrow the list with search (text matched against schema id and name, e.g. "alerting", "anomaly", "failure-detection"). With schema (e.g. builtin:alerting.profile) it prints the configured objects of that schema at scope (default environment; pass an entity id such as SERVICE-1234567890ABCDEF or HOST_GROUP-… for an entity-level override). Set effective: true to get the values actually in force at that scope, including inherited ones and defaults.

Values are printed as compact nested lists. Passwords, tokens, keys, credentials and anything else that looks like a secret are masked. The bridge cannot change settings.

This tool runs through the Dynatrace Bridge browser extension in the user's logged-in browser. If it fails, report the error to the user; do not try to open browser tabs or use browser automation instead.