Publish a Service Health starter

Ask your agent for Service Health when you want request counts, p95 latency, active alerts and an observed service neighborhood on one read-only proof page. Your agent discovers the sources, shows the server's complete preview and creates the dashboard only after your approval. The versioned recipe is service-health-starter-v1 in the dashboards and reports skill.

What the dashboard shows

Panel	Shows	Selectors
Request count (requests per bucket)	Sum of a verified monotonic request counter per bucket, grouped by service, as a line chart	Service and environment
P95 latency (last bucket with data)	Native seconds or milliseconds, with a sparkline and previous-period comparison when readable	Service and environment
Selected-project active-alert context	Firing, pending and acknowledged alerts, refreshed every 30 seconds	Neither; project context
Selected-project service neighborhood across recorded environments	The selected service and its observed direct neighbors	Service only; environment does not filter

Selectors and defaults

The agent discovers one readable service and environment as defaults for both instruments. Empty defaults in an approved definition mean all-observed: they remove that metric filter; empty service shows the observed project map. This template uses nonempty discovered defaults. Clearing a selection on the current proof page restores its default; it does not select all-observed. No selection expands the credential's project or authority. Source reads can be bounded or incomplete, so a filtered neighborhood is not an exhaustive service inventory.

Discovering the sources

Use a project-bound API key. Today metadata discovery is anectico metrics list -o json over that project's last 24 hours, subject to retention. Organization-scoped MCP name discovery does not carry the metadata this recipe needs. The agent must not certify an arbitrary catalog window or infer absence from a truncated catalog. Discover selector values with anectico metrics labels METRIC -o json. Grouped CLI metric reads can check a selected service and environment; exact proof-page request filters and displayed values still need checking. An unqueried selection stays unverified.

Reading the numbers

A 60-second bucket containing 120 requests shows 120 requests. It is not a requests-per-second rate, nor a count of stored samples. Delta counters represent interval increments; cumulative counters use per-stream differences and reset handling. Deduplication does not prove upstream delivery completeness. Missing buckets have no measured value.

Latency retains the discovered unit: 0.25 s or 250 ms. This recipe applies no conversion. A histogram p95 is a bucket upper bound, with a terminal bucket clamped to the largest explicit bound; a scalar gauge p95 is a sample quantile. Summary percentiles cannot be combined and are refused. The stat uses the last available bucket, rather than a percentile of the whole window. Missing instruments, last intervals and previous periods are unavailable, never zero.

Creating and checking it

The agent fills the native template and previews one creation:

anectico dashboards create --file dashboard.json --idempotency-key service-health-v1-1

After you approve the complete project, variables and four widget definitions, it repeats the same file and key with --confirm-token TOKEN. MCP uses create_dashboard through execute_internal_action. Both store the dashboard, all four widgets and both variables together. An identical retry returns the original receipt marked as replayed and creates nothing new.

Read-back uses anectico dashboards get DASHBOARD_ID or get_dashboard: check project, version 1, variables and defaults and every complete widget. Open the returned project-qualified proof link in your signed-in session and compare native source values with the chart and stat for two services and two environments. Alerts remain project context; topology spans recorded environments. If the page was not opened, say that rendering and selector behavior remain unverified.

Permissions

Creation needs dashboard:write, read-back dashboard:read, and MCP mcp:read / mcp:write. Sources need metrics:read, alerts:read and traces:read for topology. services:read applies only when additionally reading the service snapshot. Each independent verification is a separate query operation; creating configuration measures nothing. Existing content permissions and policy still apply.

What to report

Report what was stored, measured before approval and seen on the page separately. Name readable data, empty, withheld, unavailable and truncated sources separately. Empty results concern retained visible data in the queried window; they never establish universal health or everything emitted upstream.

Current environment dimension filters also require agents:content:read and an allowing current content policy. If either is withheld or unavailable, stop verification; never remove that filter to get data. This authority is conditional on the selected source operation, not permission to read every source.