Generate HTML Reports

The ajat report commands turn an export snapshot into a single self-contained HTML file you can open offline, attach to a ticket, or archive for compliance. There are five reports, each a different lens on the automation estate. Pick the one that answers the question you have.

Every report reads the local JSON catalog on disk — no live Jira call is made. That means you can generate, review, and share reports without credentials and without touching the tenant.

The five reports

Each report ships with its own accent palette so it is recognisable at a glance. All five share the same navigation chrome — client-side search, foldable sections, light/dark themes, a Print button, and links back to the Jira automation for each rule when the snapshot captured the site.

The reports exist for the problem that appears once Jira Automation grows across an organization: no single project screen explains the whole automation mesh. An export snapshot may contain local project rules, multi-project rules, global rules, copied rules with small differences, labels that mean different things in different teams, and webhook or email actions that connect Jira to other systems. The reports turn that local JSON estate into an inventory and review surface that administrators, auditors, and migration teams can discuss without live Jira access.

Inventory

What it does: catalogues every rule in the export snapshot, grouped by scope. It is the baseline map of the automation estate — what exists, where it lives, whether it is enabled, and which triggers, conditions, actions, labels, actors, and branches make up each rule.

ajat report inventory \
  --input-dir ./jira-automations-backup \
  --output-file inventory.html

What you get:

• Headline hero card plus metric cards: total / enabled / disabled / unique scopes / branching / chain-capable / unlabeled.
• Scope-family breakdown with inline bar charts (global, single-project, multi-project, other-scope, unknown).
• Recently edited and Oldest rules tables — the first surfaces current activity, the second surfaces potentially stale rules nobody has touched in a long time.
• Unlabeled rules list (rendered only when any are missing labels).
• Top scopes / triggers / actions with bars proportional to count; trigger and action types are humanised (e.g. jira.jql.scheduled → Scheduled (JQL)).
• Top labels chips and Top actors table.
• People section — a per-account table covering everyone the estate references (owners, actors, collaborators, and component references), with per-role rule counts, total rules, account type, and active/deactivated status.
• One expandable card per rule with status badges, a Trigger → Conditions → Actions → Branches flow diagram (with inline hints such as the cron expression for scheduled triggers, JQL excerpts, and target field names), a copy-to-clipboard button for the UUID, and a metadata grid (UUID, state, labels, updated, created, actor, notify-on-error, source file).

Integration footprint

The inventory report answers a security and compliance question the Jira UI cannot: where does our automation send data, and to whom? The integration footprint inventories every external service the estate reaches — chat spaces, email recipients, webhook endpoints, and cloud services. Use it during vendor reviews, data-egress audits, and access reviews to see the automation’s outbound dependencies in one place.

The inventory report is the right first stop when a team asks, “What automation do we actually have?” It shows the global and cross-project rules that are easy to miss when each project is reviewed in isolation.

Collision

What it does: finds rules that overlap or do the same thing — the copy-paste sprawl that accumulates as automation is cloned across projects.

Why it’s useful: duplicated rules are extra maintenance, extra runtime, and extra places for the same logic to drift out of sync. This report gives you a shortlist of consolidation candidates and conflicting rules that fight over the same issues.

ajat report collision \
  --input-dir ./jira-automations-backup \
  --output-file collision.html \
  --similarity 0.7

Two kinds of duplication are detected:

• Behavioural duplicates — rules whose steps are near-identical (trigger, conditions, and actions with their key parameters), clustered by Jaccard similarity regardless of scope, so the same automation copy-pasted into many projects surfaces as one family. Each cluster shows the shared behaviour, each member’s similarity, and what it differs by. Tune with --similarity.

• Overlap fingerprints — coarser structural matches:

  Group	Confidence	What it surfaces
  Exact fingerprint	HIGH	Same scope + trigger + condition bundle
  Shared trigger	MEDIUM	Same trigger in the same scope
  Shared condition	LOW	Repeated condition fragment under the same trigger
  Shared label	LOW	Rules tagged with the same automation label

Confidence reflects how specific the match is. Always inspect the listed rules before consolidating — duplicates are sometimes intentional (e.g. one rule per project clone). The report surfaces candidates for human review; it never claims a rule is wrong.

Consistency

What it does: audits label hygiene, naming, ownership, and governance posture across the estate.

Why it’s useful: it is the readability lens. As more projects and admins participate, labels and names drift and ownership gets murky. This report shows whether teams use the same language for the same kinds of automation — valuable before migrations, platform cleanup, and access reviews.

ajat report consistency \
  --input-dir ./jira-automations-backup \
  --output-file consistency.html

What you get:

• Label inventory: every label with its rule count and the scopes it appears in.
• Similar labels: clusters detected via normalized Levenshtein distance (threshold 0.82) — catches typos like triage vs triag.
• Similar rule names: the same algorithm on rule names — surfaces copy-pasted rules with slightly different names.
• Capability families: rules grouped by inferred action family (issue creators, issue modifiers, email senders, webhook callers).
• Governance & hygiene: error-handling and edit-access distributions, plus drill-downs of silent-failure and restricted-access rules.
• Ownership: who authors and runs the automation, and the “orphaned” rules whose author or run-as identity is deactivated.

Risk

What it does: scans the estate for governance and operational risk, scores each rule, and ranks the ones that need attention — a health dashboard with an overall grade.

Why it’s useful: scale hides problems. This report finds the automation that is quietly failing, unowned, stale, wasteful, or leaking data — the issues you cannot see rule-by-rule in Jira. Run it quarterly, or diff it over time.

ajat report risk \
  --input-dir ./jira-automations-backup \
  --output-file risk.html

Findings, each weighted by severity (the report explains the scoring):

• Silent failures — notifyOnError = NEVER; when they break, nobody is told.
• Orphaned ownership — the author has left (deactivated account); the rule runs unowned.
• Runs as a deactivated account / deactivated in-rule references — the rule executes as, or references, an account that no longer exists.
• Stale but enabled — untouched for over a year, yet still live (drift risk).
• High-frequency schedules — hourly or sub-hourly firing: the main runtime cost and load hotspot.
• High complexity — the hard-to-maintain long tail.
• External data egress — rules reaching third-party services.

The overview grades the estate A–F and lists the top at-risk rules with the exact reasons; a Risk by project table routes findings to the owning team.

Workflow

What it does: renders every rule as a top-down flow diagram plus a step-by-step “runbook” of exactly what it does — print-friendly, one rule per page.

Why it’s useful: it is the fastest way to understand an automation without reading raw JSON or clicking through the Jira builder. Perfect for reviews, audits, change approvals, and onboarding someone new to the estate. Print or Save-as-PDF for a clean per-rule document.

ajat report workflow \
  --input-dir ./jira-automations-backup \
  --output-file workflow.html

Each rule shows its component tree as an inline-SVG flowchart (trigger → conditions → actions, with branches indented) alongside a plain-language step list (“When scheduled every 5 minutes → For related issues → Then edit Expected Release”), the owner and run-as identities, complexity, and the external systems it integrates with. Diagrams are inline SVG with no JavaScript, so the browser’s Print / Save-as-PDF produces a clean per-rule runbook.

Navigating the reports

Every report shares the same chrome:

• Global search. The sidebar input filters every searchable element on the page — rule cards, recently-edited rows, label rows, cluster headings. Matches are highlighted inline.
• Filter chips (inventory only): toggle Enabled, Disabled, With branches, Chain-capable, Unlabeled, or any scope-family. Combine freely with the text query.
• Sort dropdown (inventory only): name A→Z / Z→A, updated newest / oldest.
• Foldable sections. Every titled section collapses; expand or collapse all from the sidebar buttons or the e / c keyboard shortcuts.
• Light / dark theme toggle in the top-right toolbar; the choice is persisted in localStorage. Without an override the report honours the OS preference.
• Keyboard shortcuts: / (or ⌘F / Ctrl+F) focuses the search, Esc clears it, e expands every fold, c collapses every fold.
• Print stylesheet. The toolbar, sidebar, search, chips, and copy buttons are hidden; sections render in a paginated layout suitable for PDF export (⌘P / Ctrl+P).

Reports use modern HTML (<details>, CSS Grid, custom properties) and target evergreen browsers — current Chrome, Safari, Firefox, and Edge.

Common flags

Every report subcommand accepts:

collision additionally accepts --similarity (default 0.7) to tune the behavioural-clustering threshold from 0 to 1.

Theming for white-label use

Reports use CSS custom properties for every color and radius. Override them with a YAML theme file to match your organization’s brand:

# brand-theme.yaml
colors:
  bg: "#0d1117"
  surface: "#161b22"
  ink: "#e6edf3"
  accent: "#7c3aed"
  trigger: "#f59e0b"
  condition: "#a855f7"
  action: "#22c55e"
  branch: "#06b6d4"

ajat report inventory \
  --input-dir ./jira-automations-backup \
  --output-file inventory.html \
  --theme-file ./brand-theme.yaml \
  --title "Acme — Jira Automation Inventory"

Theme values are restricted to a conservative set of CSS tokens — anything containing {, }, ;, comment markers, or quote characters is rejected, so the inline <style> block stays injection-free.

Sharing reports securely

If you ran ajat export --redact-sensitive-fields, Jira pre-redacted obvious secrets. Even so, scan a report before mailing it externally:

grep -i 'webhook\|password\|token\|secret' inventory.html

A report enriched with resolved identities contains personal data (display names, and any email addresses Jira exposed). Handle it as you would any file containing personal data.

Related

• ajat export — build the local export snapshot that reports consume.
• ajat diff — compare two export snapshots to review drift over time.
• ajat search — query the live tenant for fresh rule summaries without exporting.
• Utilities — doctor, tree, support, and the rest of the diagnostic surface.