Investigate service health and dashboards

Use service-level views when a symptom affects many customers or does not yet have a customer or an Issue to start from. Your agent reads the service health and the traces. When a view is worth repeating, the agent creates a dashboard, and you open it as a read-only page.

Approve configuration changes

Every management write through MCP, REST or the CLI first returns a server preview and changes nothing. It includes complete before and proposed definitions, required permissions and a confirmation token. Customer-authored configuration is marked as untrusted data. Creation IDs and commit timestamps are assigned at apply; the preview states which values are generated then.

Approve that state, then repeat identical arguments with MCP confirm_token, CLI --confirm-token TOKEN, or REST header X-Anectico-Confirm-Token: TOKEN. Keep the same body, version arguments and retry key. A changed state, source or argument requires a fresh preview and approval. Local --yes is no longer accepted.

Creation needs a stable idempotency_key (1–128 bytes), supplied with CLI --idempotency-key KEY or REST Idempotency-Key: KEY. Identical retries return the first committed result, even after the object changes or is deleted; they create nothing new. Changed arguments cannot reuse the key. Current permissions and privacy restrictions still apply when reading a receipt.

Dashboard creation can include up to 50 initial widgets, full layout, tags and variables through either surface. A project-bound credential may omit project_id; an organization credential must supply it. The authenticated API key or member owns the dashboard. Metadata changes and dashboard deletion require its owner or an organization admin. Creation, clone and widget add use retry keys. Clone and every dashboard and widget edit or deletion require the current expected_version. Updates accept explicit masks; CLI patches supplied metadata fields, while MCP without a mask replaces name, description, tags and variables.

Detail returns owner, project, layout, tags, variables and complete queries and visualization text. widget_count is populated. MCP returns widget pages of 30; continue pagination.next_cursor as widget_cursor on the same dashboard and version. The CLI accepts that cursor with dashboards get ID --widget-cursor CURSOR; an explicit empty cursor starts the first MCP page and also needs mcp:read. Without that flag, CLI and REST detail returns the complete native aggregate. Its configuration_json contains the full native definition of that page and is marked untrusted. List pages accept project, limit and cursor on both surfaces; keep those arguments fixed when continuing, and never infer an inventory total. Widget previews include both complete dashboards, including exact saved-insight pins; no query is shortened for approval.

Ask your agent

Which services are degraded in production right now? Take the worst one and show me one failing trace and its logs. Then create a dashboard called "Checkout latency by environment" with its request count, error rate, and p95 latency, and give me the link.

Job	MCP tool or action	CLI command
Compare services: activity rate, errors, latency, health	get_service_health	anectico services list, anectico services red
See upstream and downstream dependencies	get_service_map	anectico traces service-map
Span statistics per service and operation	aggregate_traces	anectico traces aggregate
Read a trace and its critical path	get_trace, get_trace_critical_path	anectico traces get, anectico traces critical-path
List and read dashboards	list_dashboards, get_dashboard	anectico dashboards list, anectico dashboards get
Create, change, or clone a dashboard	create_dashboard, update_dashboard, clone_dashboard	anectico dashboards create, anectico dashboards update, anectico dashboards clone
Add, replace, or remove a widget	add_widget, update_widget, delete_widget	anectico dashboards widgets add, anectico dashboards widgets update, anectico dashboards widgets delete
Delete a dashboard	delete_dashboard	anectico dashboards delete
Read or run a saved-insight widget	get_saved_insight_widget_status, query_saved_insight_widget	anectico dashboards widgets status, anectico dashboards widgets query

Service and trace reads need services:read and traces:read. Reading a dashboard needs dashboard:read. Creating, cloning, and changing widgets need dashboard:write. Deleting needs dashboard:delete and dashboard:read. MCP calls also need mcp:read or mcp:write. Every write is a preview and confirm write.

What your agent gets back

get_service_health returns a top list of services: for each one the exact request count (the entry spans it served), the activity rate, the error rate, p50 and p95 latency, and the server-derived health. With the list come the order that was applied, how many services reported activity in the window, how many the health and name selection kept, how many the list shows and how many matching services it left out, the total entry spans across every service, the project or projects it covers, and the window that was actually read. It can also return one service’s bucketed series. get_dashboard returns the dashboard’s current version, the project, and the id, type, title, and query of every widget, together with the dashboard’s url. Write tools that create or change a dashboard return a receipt with the same link.

A write that changes an existing dashboard quotes the dashboard version that the agent read. A stale version is refused, so a write never overwrites another person’s change without notice. Read the dashboard again before you retry.

Open the proof

Open the link from the result. It opens the dashboard page at /view/dashboard/:dashboardId, with project_id in the address. The page is read-only. It names its project, and its one action is Copy link. It has no editor, no Add widget, and no drag-and-resize handles. Your agent makes those changes. See Proof pages.

A dashboard belongs to one project. A link that names another project than the dashboard’s own shows nothing from the dashboard. Ask the agent for a new link.

The page has its own Dashboard time range (last hour, 24 hours, 7 days, 30 days, or a custom range) and a Dashboard refresh choice, and it shows the dashboard’s variables. They change only what you see. Choose Custom range to enter a start and an end in your browser’s local time. The fields start at the last hour and stack on narrow screens. Widgets pause while either date is missing or the start is not before the end. Correcting the range resumes them. If dashboard requests are temporarily rate limited, the page names that state and makes a small, bounded number of automatic retries after the delay the server asks for. Other failures stay separately labeled and can be retried.

Copy link copies the current dashboard URL, including the selected variable filters. It does not make the dashboard public. The recipient must sign in to the same organization and have access to the dashboard.

Read a service-health picture

Use get_service_health or anectico services list for a qualified service snapshot. The picture guide owns shape support, PNG flags, covered windows, series refusals and host fallback. The ordinary service measurements and selection controls are described below.

Follow the affected service

Ask the agent to compare services by exact request count, activity rate, error rate, p50, p95, and server-derived health. Name one service to get its bucketed series, and name an environment to narrow both. Activity includes inbound server spans, message-consumer spans, and root internal or producer spans from scheduled jobs. Child implementation spans and outbound client spans do not inflate the rate. APIs, queue workers, and batch services therefore share one useful catalog. A failed RED read stays an explicit, retryable failure. It does not become an empty chart.

For observed customer reliability, select one exact project and service and measure completed server-span attempts, including servers with parents. That population excludes consumers and root background work. It uses each measuring span's own person identity or explicit account pair, counts retries as attempts, and keeps HTTP and OTel outcomes, unknowns and latency samples together. Service activity, product-event account membership and struggling-customer discovery do not supply that denominator. Compare an account with its returned same-definition project comparison; do not divide error events by service activity or average member percentiles. Both readings are observed evidence with capture limits.

Order the services before the list is cut

The service snapshot is a top list. Anectico measures every service that reported activity in the window, orders all of them, and only then keeps the first ones. Choose the order:

Order (sort_by, --sort-by)	Means
request_count (default)	Entry spans served in the window, compared as exact integers
activity_rate	Entry spans per second over the window that was read
error_rate	Failing entry spans as a fraction from 0 to 1
p50_ms, p95_ms	Entry-span latency percentiles in milliseconds
health	Ascending is healthy, degraded, down; descending is down, degraded, healthy
service	The exact service name

sort_order (--sort-order) is asc or desc. It defaults to desc, and to asc for service. A service whose health is unknown comes last in either direction. Equal values break on the exact service name, ascending, whichever direction you chose, so the same question returns the same list twice. limit (--limit) keeps 1 to 200 services and defaults to 50. Any other order word, an empty value or a limit outside that range is refused rather than guessed.

Which five services had the worst p95 latency in production over the last hour?

anectico services list --env production --since 1h --sort-by p95_ms --limit 5

The answer says how many services exist in the window and how many the list left out. There is no next page and no cursor: to see more, raise the limit or change the order. A slow service with very little traffic is still ranked first by p95_ms, because the order is computed over every service, not over the busiest fifty.

The ordering options apply only to the snapshot. Asking for one service's series, or for a wait on health changes, together with an order, a limit or a selection below is refused, even when the value is the default. A health wait always watches every service, so a service far down the list still counts.

Ask only about some services

Name a health state, a part of a service name, or both, and Anectico keeps just those services before it orders them and cuts the list. The selection is made over every service that reported activity, so a degraded service with very little traffic is found even when it sits far below the busiest fifty.

Selection (health_filter, --health)	Keeps
healthy, degraded, down	Services whose derived health is exactly that state
unknown	Services whose health could not be classified. Every service that reports activity is classified, so this normally keeps none

Selection (service_match, --match)	Keeps
Some text	Services whose name contains that text, in any letter case. The text is matched literally: *, %, . and quotation marks are ordinary characters, not wildcards or patterns. At most 256 bytes

One health state per call. Another letter case, a comma-separated list and a padded word are refused rather than guessed. An empty value means no selection, and service_match is not the service argument that names one exact service for a series. Names come back exactly as they were measured.

Which degraded services have "checkout" in their name?

anectico services list --env production --since 1h --health degraded --match checkout

The answer carries four counts that mean different things: how many services reported activity (never changed by your selection), how many your selection kept, how many the list shows, and how many kept services it left out. With 80 services reporting, 7 kept and a limit of 3, those are 80, 7, 3 and 4. The selections you asked for are repeated in the answer, with the text trimmed of surrounding spaces.

A window that reported no activity says so: no observed service activity in that project and window. That is not a claim that an expected service is down, and history older than your retention cannot be read; the answer names the oldest history it covered.

A selection that keeps nothing says that no observed service matched it, and how many were observed. It does not say that your services are healthy. A service that reported no activity in the window is not observed at all, so asking for its name matches nothing whether it is running or not, and Anectico keeps no list of the services you expect. Treat an empty match as "none of the services that reported activity", and check separately that a service you expect did report. When only part of the window is still retained, the answer says which part was read, and that an empty match covers only that part. If a window holds more than 10,000 services, or the read exceeds its per-query limits, the request is refused with no list at all rather than a partial ranking. Narrow the window, the project or the environment and ask again. A window whose end is not after its start is refused too.

Each server measures only a few service snapshots at once, at most two for one organization. When it is busy for about two seconds the request answers 429 with Retry-After: 1 and details.reason: "READ_ADMISSION_BUSY". Nothing was measured: ask again after the second, and do not read it as an empty list. A program that shows the services to many people should read the snapshot once in its own backend, for one project and an explicit window of a day or less, no more than once a minute. See Busy expensive reads.

The service map shows upstream and downstream dependencies from distributed traces. The map is incomplete when services do not propagate trace context or when sampling removes the relevant calls. It is evidence from observed traces, not a configuration inventory. Parent relationships produce synchronous HTTP, gRPC, and database edges. Retained span links keep asynchronous producer-to-consumer edges and the queue delay, even when an asynchronous consumer starts a fresh trace. Explicit external peers and missing peers are labeled separately. Anectico does not invent a service name. Cycles, bottlenecks, and the service-level critical path are computed by the server, so every client sees the same analysis. For each directed edge, the result gives the call and error counts, the average and p95 latency, the protocol, the dependency kind, and the asynchronous queue wait. A truncation warning means that the bounded server analysis reached its span limit and the graph covers an analyzed subset.

The RED values and the health on an observed service node use exactly the same entry spans, environment, time window, counts, percentiles, and thresholds as get_service_health. External and unknown boundary nodes have no health, because Anectico has no service-entry telemetry for them.

Explain the symptom

1. Fix the project, environment, and time window.
2. Identify the service where the rate, errors, or latency changed.
3. Open representative traces from that same window.
4. Follow the critical path and the error spans into correlated logs. On asynchronous paths, the queue gap is shown separately from span work, and it is included in the server’s wall-time total. If the analysis request fails, retry it. The span timeline is not lost.
5. When a customer or an Issue appears, switch to that connected story for impact and replay evidence.

The trace page puts the span timeline first. Expand Critical path to read the computed span sequence and its diagnostics next to the correlated evidence.

A trace page loads at most 1,000 spans. A Partial trace notice shows the loaded and total span counts when more spans exist. Duration, service counts, error counts, the timeline, and the flamegraph describe only the loaded spans. If none of those spans has an error, the status is Incomplete: an omitted span could still have failed. An error in a loaded span still establishes failure, but the observed error count can leave out other failures. Critical-path analysis is explicitly incomplete while spans are missing. Correlated Issues stay available even when the span that caused an error is outside the loaded subset. Trace previews within an Issue also say when their timeline shows only part of a trace.

A Cycle detected badge on a trace’s critical path means that the analyzed parent and link graph contains a cycle. Inspect the spans’ parent IDs and links. The displayed path does not revisit a span to follow the loop. OTLP ingestion accepts graph relationships without checking that the whole trace is acyclic, so acceptance alone is not a graph-quality check.

Metrics show where and when behavior changed. Traces and logs explain why.

Save a dashboard

Ask the agent to create a dashboard for a question the team expects to ask again, and to add the widgets. Members with dashboard write access can create and clone dashboards, and add, replace, or remove widgets. The dashboard owner and organization admins can also change its name, description, tags, and variables. Deletion additionally needs dashboard delete access. Viewers are read-only, including when they were previously recorded as the dashboard owner.

A new dashboard belongs to the selected project. A clone keeps its source dashboard’s project. Creating or cloning checks that the project currently exists, is active, and belongs to your organization. An invalid project or unavailable verification refuses creation. See Creating project-bound saved resources for the project selection and retry contract.

A widget’s position is part of the dashboard’s layout. On a phone, widgets appear in a single-column stack. Returning to a wide screen shows the stored arrangement. The CLI body of anectico dashboards create accepts a layout.

Ask your agent to publish the Service Health starter. It creates four panels and single service and environment selectors together after your approval. The agent discovers the project's actual instruments and readable defaults first.

Request count is a line chart of a verified monotonic counter summed per bucket, grouped by service. Its title says requests per bucket because the chart does not draw the stored unit. A 60-second bucket holding 120 requests shows 120 requests. A gap is missing data, never a measured zero.

P95 latency shows the last bucket with data in the instrument's native seconds or milliseconds, with explicit decimal precision: 0.25 s or 250 ms. A display unit only labels a value. Custom conversions need a formula and verification of the displayed transformed value. Histogram percentiles are bucket upper bounds; Summary percentiles are refused. Missing values are unavailable.

Both metric panels use both selectors. Active alerts remain selected-project context. Topology uses the selected service neighborhood across recorded environments; changing environment does not filter it. Compare each panel with its source on the returned proof page before calling the starter verified.

Native metric Stat and Gauge widgets show the last available point by default, also when only sorting or a display limit is set. Choosing another reducer (reducer: first, min, max, sum, avg or count) changes how the returned points become the shown value.

Native metric Heatmap widgets show seconds on the time axis for intervals below one minute. When the shown timestamps cross a daylight saving clock change, the axis labels include the timezone to tell repeated local times apart. Hover a cell to see its date and time in your browser’s timezone, the metric bucket range, and the observation count, including zero.

A logs widget such as Log volume by service counts every matching record in the selected project and time range, including older records beyond the recent-log preview. Service, environment, text, and level filters apply to the count. The chart ranks the complete groups before it shows its top ten. Recent logs shows at most 100 records. Log volume widgets can read up to 10,000 matching records across the selected levels. Larger results show an error that asks you to narrow the time range or add filters. A failed page, a missing total, or a detected change during paging also shows an error instead of a partial count. Retry, or choose a fixed, older range if new logs keep arriving within the selected window.

Widget filters must be supported by the selected source. Trace RED is service-wide and rejects operation filters. Use trace records or aggregates for one operation. Operation aggregates count and time the matching spans, while service aggregates attribute errors to spans in that service. Trace grouping supports service and operation names. Log grouping uses fields available on log records, including service, environment, and level. Unsupported dimensions are rejected. Affected-people error widgets support service and Issue filters, but reject Issue-status filters.

Metric and event dimension filters accept multiple variable selections. Scalar fields such as service, environment, and text queries accept at most one selection. Multiple selections show a query error and do not silently select the first. Compound refresh intervals such as 1m30s are supported up to the browser timer limit (2,147,483,647 milliseconds).

Product-event widgets measure event count or unique customers through the same frozen-query API as customer agents. Direct metric values use whole-window totals. Time series and formulas use buckets. Each event target’s previous-period comparison shares its result snapshot. A new measurement and a scheduled refresh create fresh results. A retry keeps the original attempt. Guarded reads, expiry, and permission changes can hide previously shown values. See product analytics for typed breakdowns, exact counts, coverage, and required permissions.

Rename or delete a dashboard only after you check who relies on it. Avoid dashboards that merely duplicate a person page, an Issue page, or a service view. Give each dashboard a question-oriented name such as “Checkout latency by environment”, and keep time and project assumptions visible.

• Search logs, traces, and metrics
• Explore and compare metrics
• Create alerts

Start from the Overview

Ask your agent for an Overview and it publishes one dashboard with six panels, in one step. The dashboard is an ordinary read-only page: your agent creates it, and you open the link.

Set up an Overview for the checkout project. Check that every panel has something behind it before you create it, and show me the preview first.

Panel	What it shows	What it does not show
Request volume	Requests in each time bucket. The bucket width follows the range you pick, so a wider bucket holds more requests	A rate per second. A gap is a bucket with no data, not a zero
P95 latency	The last bucket that has data, in the unit your service reports, with a previous-period comparison when there is one. For a histogram it is the upper bound of the bucket that holds the 95th percentile	The percentile of the whole range, or an exact value
Recent issues	Up to 20 issues from the range, the most events first	Every issue
Active alerts	Alerts that are firing, pending or acknowledged right now, refreshed every 30 seconds	Silenced alerts, or that nothing is wrong when it is empty
Service topology	Services and the calls between them that appear in your traces	A list of the services you run, or the absence of one you do not see
Live logs	Log lines that arrive while the page is open	The log volume. A quiet panel does not mean there is no traffic

The Overview names no metric of its own. Your agent looks at what the project really sent in the last 24 hours, with each metric's type and unit, and chooses the request counter and the latency histogram from that. It reads the five other sources too. If a panel has nothing to read, your agent tells you which one and does not create a dashboard that looks complete: a missing metric is never drawn as a zero. A metric the project sent only before those 24 hours does not appear in what the agent can list; ask it for the exact name if you expect one.

You approve one preview that shows all six panels and the project. The creation is atomic: the dashboard and its six panels exist together or not at all. If an answer is lost, repeating the same request returns the first dashboard and creates nothing new; a changed request under the same key is refused.

Your agent then reports three things separately: what is stored (the version and the six panels), what it measured before you approved (the readable state of each source), and what you can see on the page. The page needs your signed-in session, so open the link yourself. A request-volume chart shows its values without a unit, so its title says what a value is. A dashboard that is only stored has not shown that your services sent anything.

Saved-insight widget status and execution

The pre-production saved-insight widget lifecycle is available through MCP, CLI, and REST. A person opens the result on the dashboard page. A saved widget pins one exact insight revision and uses that recipe’s own window. Dashboard time controls never replace its window, and a newer insight head never silently changes the pin.

After a project or organization deletion reaches Dashboards, its dashboards and widgets become unavailable while stored content is removed in the background. Retrying a stale write or worker acknowledgement cannot restore them. Project deletion keeps dashboards in other projects. An unavailable deleted scope must not be retried as a temporary server error.

Add a saved insight

Ask the agent to find the saved recipe in the project, to review its exact revision and measurement settings, and to attach it as a saved_insight widget. To use an earlier retained revision, give its revision number. Attaching does not execute the recipe. The saved widget waits for dependency confirmation before it measures, and a pending check updates by itself. New saved widgets default to manual refresh.

To send a dashboard’s saved-insight widgets to your team on a schedule, ask the agent to create a report subscription for the dashboard. See Send a scheduled report.

Saved widgets in the same project measure one at a time in the current dashboard session. A widget that is waiting for another measurement is queued, and it starts automatically. Leaving the dashboard or changing access cancels pending measurements. Other activity can still make analytics busy. Repeat the same request after capacity becomes available.

A saved widget shows its native trend, ordered funnel, funnel correlation, retention, engagement, paths, web analytics, revenue, survey, or heatmap result, including coverage, unavailable values, and maturity where they apply. A survey widget shows counts only: the three outcomes and each question’s counts, never an answer text and never a person. A heatmap widget shows a compact summary, the totals and the top cells, elements, or scroll depths, never the full grid. Trends with a comparison let you switch between Current period and Comparison period, each with its own coverage. The Revision link opens the pinned recipe. Every saved widget shows Uses saved dates, its measured window in UTC, and a Measured timestamp. Comparison recipes show both windows. Dashboard time filters and variables do not override the saved definition. A dashboard that contains only saved insights and notes says this in place of the range selector. A mixed dashboard keeps the selector and explains its scope.

Days-active widgets lead with the observed people count, with the window length as context. If any bins are unavailable, the headline is unavailable and not a partial total. Funnel widgets keep conversion, pending, and indeterminate counts. Additional conversion timing and entry-period charts expand on request. Coverage notices stay visible next to the result. Freshness and the detail link stay below the chart, also when a dense result needs scrolling.

A repeat of the same execution checks current access and widget state first. A new execution starts only when the agent deliberately uses a new execution key. Cached values are hidden during access revalidation or after a source or access failure. Expired results need a new measurement. An available newer recipe revision never changes the widget’s pin. The agent has to replace the pin explicitly (update_widget). To remove an unavailable widget, use delete_widget. Removal does not need access to its old recipe.

Attach, replace, clone and remove

For MCP, use execute_internal_action with action: "add_widget". Supply dashboard_id, the current dashboard expected_version, type: "saved_insight", title, and saved_insight: {"id": "INSIGHT_UUID", "revision": "1"}. The revision is an exact positive decimal string. Omit ordinary targets, expressions, transforms and display overrides: the recipe renders as its native trend, funnel, funnel correlation, retention, engagement, paths, web analytics, revenue, survey or heatmap result. Attachment needs dashboard:write and insights:read, as well as MCP write access. It validates the retained recipe without executing it. A successful attachment can be pending at first. The owning worker confirms its dependency before execution is allowed.

The existing update_widget action replaces the complete configuration after preview and confirmation, using the current dashboard version. Replacing a pin or cloning its dashboard validates each exact source under current permissions. A concurrent dashboard edit refuses the clone instead of copying a recipe that was never checked. Removing a saved widget or dashboard needs current dashboard:delete authority, without needing access to the old source recipe. Replacing an unavailable saved widget with an ordinary widget needs dashboard:write.

For CLI attachment, write a JSON body such as this to widget.json:

{
  "expected_version": "1",
  "type": "WIDGET_TYPE_SAVED_INSIGHT",
  "title": "Checkout activity",
  "query": {
    "targets": [{
      "ref_id": "A",
      "saved_insight": {
        "saved_insight": {"id": "INSIGHT_UUID", "revision": "1"},
        "revision_policy": "SAVED_INSIGHT_REVISION_POLICY_PINNED"
      }
    }]
  }
}

anectico dashboards widgets add DASHBOARD_UUID --idempotency-key widget-add-1 --file widget.json
anectico dashboards widgets update DASHBOARD_UUID WIDGET_UUID --file widget.json
anectico dashboards clone DASHBOARD_UUID --expected-version VERSION --idempotency-key dashboard-copy-1
anectico dashboards widgets delete DASHBOARD_UUID WIDGET_UUID --expected-version 2
anectico dashboards delete DASHBOARD_UUID --expected-version 3

Read the dashboard before each mutation and use its actual version, not the example numbers above. REST widget POST and PUT use the same body. Widget and dashboard DELETE carry expected_version in their JSON body. Stale writes fail. If a write response is lost, read the dashboard to resolve its state before you retry. A receipt that is withheld after credential revocation does not roll back an already committed change. Removal records survive until reconciliation, so source retirement can stay blocked briefly after you remove the last widget.

Inspect and execute

Use MCP execute_read_action with get_saved_insight_widget_status and the exact project_id, dashboard_id, and widget_id. Status includes the pinned saved_insight, the decimal-string owner_revision, and one of AVAILABLE, PENDING_CONFIRMATION, NEWER_REVISION_AVAILABLE, or SOURCE_UNAVAILABLE (the enum names carry the SAVED_INSIGHT_WIDGET_STATUS_ prefix). Missing or retired sources share the unavailable state. Status needs dashboard:read and insights:read. It does not execute the recipe and does not guarantee that the source is complete.

To execute a confirmed widget, call query_saved_insight_widget with the same coordinates, the exact decimal-string owner_revision, and a UUID execution_key. Execution also needs analytics:query, analytics:read, persons:read, and all inherited source permissions. Keep the owner revision and the key unchanged for retries. An intervening widget edit or removal refuses the old operation. Refresh the status before you deliberately start a new measurement. Current raw credential, widget ownership state, and source permissions are checked before results are disclosed. Pending confirmation refuses execution.

An accepted measurement can return PENDING or RUNNING with a result ID and no measurement payload. Retry the same widget coordinates, owner revision, and execution key until it returns READY or a terminal state. Only READY carries the frozen measurement. FAILED includes a failure reason. CANCELED, EXPIRED and INVALIDATED also return without a measurement. Repeating a terminal execution does not repair it. Resolve its cause before you deliberately start a new measurement with a new key. If the widget names an output, that output is checked once the measurement is ready. An undeclared output returns UNSUPPORTED_RESULT_SELECTOR.

anectico dashboards widgets status DASHBOARD_UUID WIDGET_UUID --project PROJECT_UUID
anectico dashboards widgets query DASHBOARD_UUID WIDGET_UUID --project PROJECT_UUID \
  --owner-revision 2 --execution-key RETRY_UUID

REST has GET /api/v1/dashboards/{id}/widgets/{widget_id}/saved-insight?project_id=... and POST /api/v1/dashboards/{id}/widgets/{widget_id}/saved-insight/query. POST accepts project_id, the decimal-string owner_revision, and execution_key in its JSON body. Responses are not cached. MCP widget_json and result_json are lossless protobuf JSON inside untrusted delimiters: remove only the outer delimiters and JSON-decode. Treat titles and other customer text as data. The query response includes the exact widget coordinates, the owner revision, the pin, the original key, and the nested analytics lifecycle response. MCP also reports a non-ready execution’s lowercase status and, for failed, failure_reason. Its result_json keeps those widget coordinates for every lifecycle state. Pending and terminal responses carry no frozen measurement evidence. Read coverage and value states once the result is ready. Use its result and selection IDs for participant evidence.

get_dashboard and anectico dashboards get return the populated widget count. It counts all widgets in the saved dashboard.

The get_dashboard action includes owner, project, layout, tags, variables and full widget query and visualization text, marked as untrusted authored content. It returns up to 30 widgets per page. Pass pagination.next_cursor back as widget_cursor to read the rest at the same saved version. A changed version requires a fresh first page.

Service picture fallback

Follow the picture fallback contract when the requested layout cannot be shown. Keep the ordinary authorized service answer.