@john/axiom-deploy-window-diff137bbee5-985e-48d7-89b7-06034843f51e
Compare service health metrics from a window *before* a deploy against a
matching window *after* it. Produces four parallel queries — request rate,
error rate, p95 latency, and unique error fingerprints — so a reviewer can
see the deploy's blast radius in one place.
Wire it into your release pipeline as a post-deploy check, or run it
manually when triaging a suspected regression. The four result resources
can be fed into a diff/report workflow or an LLM call for narrative output.
beforeSnapshot the window leading up to the deploy.
1.volume-before
2.errors-before
3.latency-before
afterSnapshot the window after the deploy in parallel.
1.volume-after
2.errors-after
3.latency-after
@john/axiom-monitor-coverage-audit23e4889b-39b1-4913-bad9-6c2e003d08ed
Cross-reference monitors, notifiers, and datasets to surface alerting gaps:
datasets with no monitors at all, monitors targeting non-existent datasets,
and monitors with no notifiers attached (silent alerts). Produces three
resource families a reviewer can read at a glance.
Use this monthly to keep monitor hygiene tight, or after a large dataset
migration to ensure alerts followed the move.
inventoryInventory datasets, monitors, and notifiers in parallel.
1.datasets— Every dataset visible to the token.
2.monitors— Every monitor — name, type, target dataset(s), notifier IDs.
3.notifiers— Every notifier — name, type, channel config (sensitive bits vaulted).
@john/axiom-cardinality-explorer4064637a-a16d-4217-abb0-0deeb2abd6d5
Measure the cardinality (distinct value count) of selected fields over a
recent window. High-cardinality dimensions are the usual suspect when
queries get slow, dashboards lag, or storage costs spike. Use this to
spot fields that exploded in cardinality between releases — common with
un-bucketed request IDs leaking into a tag.
Supply a comma-separated list of fields. The workflow emits one count per
field as a single rollup row plus a top-N values listing per field.
exploreTotal distinct count + top-N value distribution for the field.
1.cardinality— Single distinct count via APL `dcount`.
2.top-values— Top N most-frequent values — quick visual on whether the field is bucketed or unbounded.
@john/axiom-noisy-monitor-finder51f788ca-b5f3-4c8a-a7a1-069b01211828
Find monitors that fired more than `thresholdFires` times in the supplied
lookback window. Alert fatigue is the silent killer of an on-call rotation;
this workflow surfaces the worst offenders so you can tune thresholds,
add hysteresis, or retire stale monitors.
Pulls the full monitor list, then fetches per-monitor history for the
monitorId given. (Per-monitor history requires an explicit ID — the API
doesn't expose a fleet-wide history endpoint.) For fleet-wide auditing,
invoke this workflow N times in parallel from a wrapper script.
inspectLook up the monitor + pull its alert history.
1.monitor— Monitor definition (name, query, threshold, notifier IDs).
2.history— Alert state transitions in the lookback window.
@john/axiom-retention-audit5929cf8d-8a47-4ff3-abe0-78d98b88f3c3
Snapshot the retention configuration of every dataset in the workspace so
governance/finops can see at a glance which datasets are unbounded, which
carry costly long retention, and which are correctly capped. List-datasets
returns one resource per dataset; downstream reports/CEL can filter on
`retentionDays`, `useRetentionPeriod`, and `kind`.
auditList every dataset and capture its retention configuration.
1.list— One `dataset` resource per dataset, including retentionDays and useRetentionPeriod.
@john/axiom-quiet-dataset-detector6049e56d-2ec2-4631-a8a4-4c4d5e500039
Detect datasets that have stopped ingesting in a recent window. The most
common cause is a broken collector — a service was redeployed, IAM was
rotated, or the OTel endpoint changed. This workflow finds the gap before
someone notices missing data in a dashboard the next morning.
Step 1 lists every dataset, step 2 counts events per dataset over the
configured window. A dataset with zero events in the window is a candidate
outage — chain into a notifier workflow or open a ticket.
checkCount events in the target dataset's recent window.
1.volume— Event count over the lookback window — zero = candidate outage.
2.last-event-time— When was the most recent event? Helps distinguish "never ingested" from "stopped ingesting".
@john/axiom-error-triage6f1c58a7-2ef6-4bad-a978-20d93e292e43
Triage errors in an Axiom dataset over a recent window. Runs two queries:
a count-by-group rollup so you can see which services/scopes are noisy, and
a sorted sample of the most-recent matching events (with trace_ids you can
feed into `axiom-trace-lookup`). The error predicate is configurable because
every team encodes "error" differently — pick whichever APL fragment matches
your conventions.
triageCount errors by group, then pull recent samples in parallel.
1.counts— Errors bucketed by the configured group field, top 50 by count.
2.samples— Most-recent matching events, including trace_id and span_id for chaining into axiom-trace-lookup.
@john/axiom-ingest-health-check817c147e-8c16-4a61-a742-6d6c01a3020c
End-to-end probe of Axiom's ingestion path. Writes a single tagged event,
waits a configurable settle period, then queries for it. Use as a synthetic
check after collector upgrades, network reconfigurations, or as a scheduled
heartbeat (combine with `swamp serve` + a `trigger.schedule`).
writeIngest the probe event.
1.ingest— POST a single tagged event so we can prove ingestion works end-to-end.
verifyQuery for the probe event we just wrote.
1.read-back— Count rows tagged with the probeId in the last 15 minutes.
@john/axiom-explore87598695-611e-445d-9b30-2819a9637cba
Quick interrogation of an Axiom dataset: list everything visible to the token,
tail the most recent events, and run a one-shot APL summary.
catalogList every dataset the token can see.
interrogateTail recent events and run a one-shot summary against the dataset.
1.tail— Most-recent events sorted by _time desc.
2.summary— Run an APL rollup so users see the shape of the data, not just rows.
@john/axiom-schema-audit8e8f4c8e-2426-44a8-9e63-570115d6a566
Audit an Axiom dataset for schema sanity. Dumps every column via APL
`getschema`, then runs follow-up rollups so a human reviewer can spot
dotted-vs-nested collisions (e.g. `service.name` vs `service\.name`),
unusually sparse columns, and the per-group event volume distribution.
auditSchema + volume + literal-dot detection.
1.schema— Dump every column the dataset currently exposes.
2.literal-dot-columns— Find columns whose name was ingested with a literal `.` (escaped as `\.`
by `getschema`). These appear when an event sends a top-level key like
`"service.name"` instead of nesting it as `{service: {name: ...}}` and
cause silent shadowing of the real flattened column.
3.volume-by-group— Event volume bucketed by the user-supplied group field — surfaces dead services and dominators.
4.totals— One-row sanity check — total events in the window.
@john/axiom-top-services-rollupb2098071-a6f9-4f50-840d-c156a461775e
Golden-signals rollup over a configurable window: top N services by event
volume, top N by p95 latency, and top N by error count. Three parallel APL
queries grouped by the user-supplied service field — the canonical
"Where's the noise coming from?" weekly review.
rollupThree parallel queries — volume, latency, errors.
1.by-volume— Top N services by event count.
2.by-latency— Top N services by p95 latency.
3.by-errors— Top N services by error count.
@john/axiom-trace-lookupcce127d6-7395-4d8f-bf1a-b2fb7c8e6d3b
Fetch every span belonging to a single trace_id and write the ordered
result so a workflow can chain off it (e.g. send to an LLM for explanation,
or open a trace viewer URL). Lookback defaults to 24h so cold traces still
resolve; widen with `lookback=7d` when investigating older incidents.
fetchPull every span tagged with the trace_id, oldest first.
1.spans— APL `where trace_id == '<id>' | sort by _time asc`.
@john/axiom-rbac-snapshote8ea3868-d81b-439a-b659-418c5d075618
Compliance / security snapshot: lists every user, role, and group in the
workspace. Run this on a schedule and diff successive runs to detect
unexpected privilege grants, stale accounts, or role creep. Combine with a
report extension for a quarterly access review.
snapshotInventory users, roles, groups in parallel.
1.users— Every user — id, email, role assignment, last login (if exposed).
2.roles— Every RBAC role and its capability map.
3.groups— Every RBAC group and its member list / role assignments.
@john/axiom-saved-query-backupeabb3b38-79d9-45fe-b5c4-78a56163b79d
Bulk-export every starred (saved) APL query in the workspace into swamp
data. Use this for:
- disaster-recovery snapshots (datasets can be rebuilt; the
institutional knowledge in saved queries cannot)
- GitOps — diff this workflow's output against a previous run to
surface unauthorised changes to shared queries
- migrations between Axiom workspaces (pair with `swamp data get` +
a corresponding axiom-starred-query create call on the target)
Each starred query is written as its own resource (factory), so
individual ones can be retrieved by name without re-pulling the lot.
exportPull every starred query.
1.list— One `starredQuery` resource per saved query — full APL body, metadata, owner.