Journal and exports

Since version 0.0.65, retain manual and automatic actions, their outcomes and supported notifications, then export them or forward them over HTTPS.

Events and identity

Each event includes a UTC timestamp, unique ID, manual or automatic source, actor and result. Lifecycle events share a correlation ID. Commands and secrets are excluded. Identity comes from the local CLI account or an explicitly trusted authentication proxy; without a trusted identity, it is anonymous.

Visitors to the public demo are anonymous. Its shared Journal page shows real demo actions and results, with filters and CSV/JSONL exports of the displayed page. Fixture recovery by the VPS timer is recorded separately in the system journal.

Persistent storage and retention

Mount a persistent volume on the journal directory. Defaults retain five files of at most 5 MiB each, with mode 0600. Oldest events expire by size. Structured events are also written to stderr for log collectors.

monit-docker --audit-file /var/lib/monit-docker/events.jsonl \
  --audit-max-bytes 5242880 --audit-files 5 \
  serve --state-file /var/lib/monit-docker/state.json --cmd 'status == exited ? start'

If the initial event cannot be persisted, the action does not begin. A write failure after execution preserves the actual outcome and emits a stderr diagnostic; it does not trigger another execution.

Version 0.0.65 used 10 MiB per file. The new limit applies to subsequent writes and rotations; existing archives are not truncated. To export a larger archive, temporarily retain its original size setting.

Browse the journal in the interface

Since version 0.0.66, the Journal page displays actions, notifications, timestamps, actors and outcomes. Filter by date range, container, manual or automatic source, category and result. Each page contains at most 100 events; CSV and JSONL buttons export only that page. Use the CLI to export all retained history.

For a fresh private installation, from the v1.3.3 checkout:

cd examples/ui
python3 prepare.py --journal --self-signed
docker compose -f compose.yaml -f compose.journal.yaml up -d

Sign in at https://localhost:8443/logs. The self-signed certificate is for local testing; use a trusted certificate remotely. The journal may be empty until actions or notifications occur. This variant does not enable manual actions.

Access is disabled by default and requires a separate read secret kept on the proxy. All authenticated users of that proxy can read the configured journal. For an existing installation, preserve your secrets and follow the activation guide: Compose overlays replace the agent command and must not be stacked without combining their options.

Reads scan at most 1 MiB per request, without loading the entire journal or polling automatically. A sparse filter may return an empty page with a continuation button. Refresh if pagination expires after rotation or restart. Only the dedicated demo journal is public; keep authentication on your own installations.

Export or forward

Journal options go before the subcommand. These commands do not connect to Docker. Use the same retention settings as the service.

umask 077
monit-docker --audit-file /var/lib/monit-docker/events.jsonl audit-export > events.jsonl
monit-docker --audit-file /var/lib/monit-docker/events.jsonl audit-export --format csv > events.csv
monit-docker --audit-file /var/lib/monit-docker/events.jsonl \
  audit-send --url https://logs.example.org/events --token-file /run/secrets/logs-token

HTTPS forwarding sends one JSON event per request, verifies certificates and refuses redirects. The receiver must accept this contract and deduplicate by event ID. There is no queue or automatic retry; local events remain available after a failure.

Shared text protection

Schema 2 protects textual fields before storage and export: controls, formatting characters and formula prefixes become visible escapes. Accents remain readable. Legacy journals are converted on read without rewriting files. Consumers must preserve these escaped values and use the serializer appropriate to their format.

Notification outcomes

The Alertmanager webhook journals alert receipt without asserting email or Slack delivery. Redis and DWho HTTP adapters record attempts and destination acceptance or failure. See the complete guide for private webhook setup, adapter volumes and recovery.

Since 0.0.71, events appear as contextual alert cards: green for success, red for failures or rejections, yellow for skipped actions, blue for queued work or notification acceptance, purple for work in progress (since 0.0.72), and neutral for simulations. English titles and visible reasons explain each event; raw fields remain available in Event details and exports. Acceptance is not proof that a person received a notification.

Small metadata alerts distinguish manual actions (blue) and automatic actions (amber), with actor and host labels in light gray.

Since 0.0.73, compact cards show action, host and date in the heading, separated by middle dots, with Event details on the right. Container, source and actor labels appear below.

The HTTP API and metrics contract covers responses, errors, freshness and exports, with curl examples.

See journal compatibility for retained schemas, export limits, backup and rollback.

See the 1.3.3 release notes for the compatibility contract, tested upgrades and validation limits.

Use separate secrets for actions, notifications, journal reads and metrics. For per-user journal cursors, enable --trust-proxy-user only behind an authenticated proxy that overwrites the actor header and restricts direct access to the agent. Otherwise readers share the anonymous cursor.