Home/Toolchest

HTML operations email reporting starter

Reusable template for infrastructure scripts that produce an HTML email report with summary tiles, per-host results, failure sections, runtime metadata, operator notes, and a plain log. Designed to give admins a repeatable evidence format for tickets, maintenance summaries, and validation drills without embedding unsafe credential handling.

Good For

  • Scheduled health summaries
  • Post-maintenance evidence emails
  • Remote host list reporting
  • Ticket attachments and change records
  • Standardizing script output across teams

How to Use It

  1. Define report metadata and run context: Capture RunId, script name, script version, operator, execution mode, start time, end time, duration, environment, and target scope. Include a clear report subject pattern such as: [Ops Report] <CheckName> | <Environment> | <Status> | <UTC Timestamp>. Record whether execution was local or remote-host-list and include the exact input source used.
  2. Build the minimum data model before rendering HTML: Use structured sections: Summary, Targets, Failures, Warnings, Evidence, Runtime Metadata, Operator Notes. For each target, capture Hostname, Reachable, CheckStatus, KeyFindings, ErrorText, StartTime, EndTime, DurationMs. Keep the same property names across scripts so CSV, JSON, and HTML outputs line up.
  3. Render an operator-focused HTML layout: Add summary tiles for Total Targets, Passed, Warning, Failed, Unreachable, and Duration. Use a compact table for per-host results with color-coded status values and a dedicated failure section that surfaces ErrorText first. Add a footer with runtime metadata, script path, version, account context, and machine that generated the report.
  4. Produce companion evidence artifacts: Write the raw per-host dataset to CSV for sorting and ticket attachment. Write a plain text log with timestamps for each phase: input load, target checks, render, email send attempt. Save operator notes separately so manual observations are not mixed with machine-collected evidence.
  5. Send email safely and keep a local copy: Send the HTML as the message body or as an attachment, but always save a local copy of the rendered report. Do not hardcode credentials or SMTP secrets in the script; retrieve them from a vault, managed identity flow, or secure prompt path. If email send fails, preserve all outputs locally and record the failure in the log and report metadata.

Execution Modes

  • local

Inputs and Outputs

Inputs

  • Target list
  • Report metadata - (required)
  • Mail settings
  • Credential source

Outputs

  • future-html-report
  • log-file
  • operator-notes

Validation

  • Rendered HTML shows correct summary counts, result rows, and runtime metadata for a known sample run.
  • Companion CSV and plain-text log contain the same host set and status values as the email body.
  • If email delivery is enabled, the message arrives with expected formatting and without truncating failure details or metadata.
  • When email delivery is intentionally blocked or fails, the local HTML, CSV, and log artifacts are still written and referenced in operator notes.

Reporting

  • Delivery summary: subject, recipients or target group, delivery result, and fallback artifact paths.
  • Run summary: total targets, passed, warning, failed, unreachable, start/end time, and duration.
  • Evidence summary: HTML report path, CSV path, plain-text log path, and ticket or change identifier.

Safety Notes

  • Do not embed SMTP passwords, API tokens, or service account credentials in source code, scheduled task arguments, or transcript logs.
  • Avoid including secrets, full connection strings, or sensitive personal data in HTML output, CSV exports, or email bodies.
  • Treat email as a delivery channel, not the system of record; always save local evidence artifacts before send attempts.
  • If reporting on remote hosts, record unreachable targets as evidence instead of retrying aggressively in a way that could amplify outages.