Reports

The Reports page turns what obserae observed into a document you can send, file or hand to an auditor. Two report templates are available, both rendered as a self-contained HTML page and as an A4 PDF.

The Cockpit and the Detection page answer “what is happening right now?”. Reports answer “what happened over this period, and what can I show for it?”.

Reading and downloading a report requires the reports:read permission. Generating one, scheduling one or deleting one requires reports:manage.

The Two Report Templates

Both are produced over a time window you choose, from 1 to 92 days, ending now.

Generate A Report Now

1. Open Analysis → Reports.
2. In the Generate now panel, pick the template, the report language and the window in days.
3. Choose the formats you want — PDF, HTML, or both.
4. Click Generate.

The report is produced while you wait, and the new run appears at the top of the history as soon as it is ready. From there you can:

• Preview — read the HTML report in the page, without downloading anything.
• PDF / HTML — download the document.
• Delete — remove the run and its files.

What The Operations Report Contains

The report reads in two halves: what your network is, then what happened on it. That order is deliberate — someone who has never seen your console can open the document and follow it from the first page.

The Infrastructure Half

Everything here comes from your cartography, and nothing in it is measured: it is what you declared.

• Infrastructure at a glance — how many networks, hosts, interfaces, services, NAT rules and declared flows the site holds.
• Network map — the same map as the Cartography page, at the same positions, with the same colours and the same groups. Drawn as a real figure in both the PDF and the HTML.
• One map per network — the same picture restricted to a single network. A host with an interface in two networks appears on both, which is what you need to follow a path across a boundary.
• Networks — name, CIDR, VLAN, zone, environment, description, and how many hosts attach to each.
• Hosts and services — role, interfaces with their addresses, and the services each host exposes.
• Declared flows — your rules read as a connectivity matrix: which conversations you declared legitimate, and which of those rows are disabled.
• Address translation — the declared NAT. SNAT is what hides behind a shared address; DNAT is a port forward — where an inbound port lands.
• Operator documentation — the free-form notes you attached to networks, hosts and groups. Markdown is flattened to plain text, because the document draws paragraphs rather than markup.

If a cartography is very large, the global map is not drawn: the report says how many entities it holds and points at the per-network maps and the tables. A half-drawn topology would show a network that does not exist, so obserae would rather print the sentence than the picture. Long tables state their own limit (“200 rows of 341”) — a report never clips silently.

If this instance has no cartography at all, the report says so in one sentence and moves on to the alerts.

The Alert Half

• Headline figures — alerts raised, how many were high or critical, how many distinct rules and distinct entities were involved, and how many are still untouched.
• Severity breakdown — the same total, split across critical, high, medium, low and info.
• Volume over time — one bar per day, or per week on a long window, so the shape of the period is visible at a glance.
• Top rules — the twenty rules that fired most, with their first and last fire.
• Top entities — the twenty hosts, addresses or pairs that appear most.
• Handling posture — how much of the period has been acknowledged, closed or left new.

This is the report to send to someone who was not watching the screen.

What The Compliance Report Contains

Rule sets can tag a rule with the control it evidences — NIS 2, DORA, SOC 2, ISO/IEC 27001, CIS Controls, and MITRE ATT&CK techniques. The compliance report builds its control matrix from the tags of the rule sets you actually have installed, and states, control by control:

• how many rules claim it, and how many of those are enabled;
• whether any of them fails to compile;
• whether they are being evaluated;
• how many alerts they produced in the window, and when the most recent one was.

A Control With No Alerts Is Covered, Not A Gap

This is the point of the report, and it is worth stating plainly: a control whose rules are enabled, compiling and running, and which produced no alert in the window, is reported as covered. A clean period is a good result, not a finding. Reporting silence as a failure would train everyone to ignore the document.

The report separates three genuine gaps instead:

Each is actionable in one place: open Analysis → Rules, fix or enable the rule, and the next report reflects it.

The Rule Annex: What Is Actually Being Evaluated

A matrix that says “covered” asks to be believed. The last two sections of the compliance report are what make it checkable, and they are the part an auditor reads first.

Rule annex gives one line per rule that carries a framework tag — and only those, because this is a compliance annex, not a listing of your whole rule catalogue:

Rule definitions then writes each rule out in full: the same condition sentence, its description, the remediation procedure recorded for it, and the exact NFQL query the detection executes, reproduced as you saved it.

That last line is the point. Anyone can take the query out of the report, paste it into Investigation, and see for themselves what the control is watching. Nothing has to be taken on trust.

An anomaly rule prints its statistics too — the baseline scheme, the threshold in standard deviations, the warm-up, the window, the transform, the dead band, the direction — so the reader can see exactly what “abnormal” was defined to mean. Settings left at their default are not printed: what appears is what differs from the standard behaviour.

Three limits, each stated in the document where it applies:

• the table lists up to 200 rules, and says so when there are more;
• the definitions detail the first 50, and say so;
• a query longer than 1200 characters is clipped, and says so.

On a community-only installation no rule carries a framework tag, so both sections are simply absent — the method paragraph already explains why the matrix is empty.

What The Report Claims

The claim is deliberately narrow and defensible: among the controls the installed rule sets declare they instrument, here is which ones have a living, evaluated rule and what evidence they produced. The report states this in its own method paragraph, so a reader outside the team draws the right conclusion from it.

Reports In French

A report can be produced in English or in French, chosen per report. Pick the language in Generate now, or set it on a scheduled job so every issue arrives ready to file. The whole document follows: titles, explanations, table headers, severities, the truncation notes, and the email that announces it.

The console itself stays in English. What changes is the document you hand to someone else.

Two things stay as they are, in both languages, because changing them would make the report harder to use rather than easier:

• Names and identifiers are never translated — framework names (NIS 2, ISO/IEC 27001, MITRE ATT&CK…), control identifiers, your rule, host and network names. They are what an auditor matches against their own paperwork.
• Dates stay numeric and UTC (2026-03-05 14:30 UTC). No month name appears, so the same stamp reads the same way in both languages.

In a French compliance report, the Méthode et limites section prints the French text and then the original English version underneath it. That section states what the report proves and what it cannot detect — the part a reader outside your team relies on — so the English original travels with it and anyone can check the two against each other. It is the way regulated bilingual documents are published.

Control mappings ship with the enterprise rule sets. On a community-only installation the compliance matrix is therefore empty, and the report says so rather than implying full coverage. Installing a rule set that carries the mappings — see Rule Sets — fills the matrix on the next generation.

Schedule A Report

The Scheduled reports panel keeps up to sixteen jobs. A job carries a name, a template, a report language, a window, the formats to produce, and a cadence:

A report is filed on a date, so there is no “every N seconds” cadence. If you pick the 31st, a shorter month fires on its last day — 28 or 29 February, 30 April — rather than slipping into the following one. That is what makes “the month-end pack” arrive at every month’s end.

Click New job, fill the form, and save. The list then shows each job’s next run time and the outcome of its last one. A job created now is armed, not run: its first document lands at the first slot of its cadence, so a monthly report covers a month rather than the minutes since you created it.

• Run now asks for the document immediately, whether or not the job is enabled — the toggle governs the schedule, not your ability to ask for the document. The request is queued on the daemon, and the row updates when the run finishes; clicking several times produces one report, not several.
• Disable stops the cadence and keeps the definition.
• Reports to keep is this job’s own retention: set it to 12 and the job keeps its twelve newest documents, dropping the older ones after each successful run. Leave it at 0 to keep every one. It applies to this job alone — another job’s history is never touched — and the store’s global limits below still apply on top of it.
• Jobs travel in the configuration bundle, so a schedule you author here is restored with the rest of your configuration.

Email The Report

A job can mail its PDF when it finishes. Pick an SMTP destination in the job form’s Email the PDF to list — it offers the SMTP outputs configured on the Outputs page, and nothing else. Leave it on No email to produce the documents and notify nobody.

The mail carries one attachment, the PDF: it is the format an auditor asks for and the one no mail client rewrites. The HTML stays a download here, where the preview is built for it.

A report over 6 MiB is not attached — most mail systems refuse a message that large. The email still goes out, saying how big the document is and where to get it, and the run records skipped too large so you can see what happened. For the link in that message to be usable, set the GUI’s public address in the daemon configuration:

web:
  public_url: "https://obserae.example.com"

Without it the message is still delivered, simply without a link — Obserae will not guess a URL it cannot verify.

Delivery outcomes appear on the run: sent, skipped too large, or failed with the reason. A mail server that is down never loses the report: the document is produced and stored either way.

History And Storage

The page lists the most recent runs, newest first, with their status, window, sizes and the formats available. The store keeps itself bounded on your behalf:

When a bound is reached the oldest runs are removed, oldest first, so the newest report — the one you are most likely to want — is always the one that stays. The four global bounds cover the whole store, one-off generations included; Reports to keep narrows one job on top of them, which is how a quarterly pack survives a chatty daily report. Rendered documents live under <data_dir>/reports/, and the Lifecycle page accounts for them alongside every other store.

Run history travels in a backup archive; the rendered files themselves do not, since they can be regenerated from the data that does. After a restore, produce the report again and it comes back with the same content.

Where To Go Next

• Alerting — the rules whose fires the operations report counts.
• Rule Sets — install the packs that carry framework mappings.
• Lifecycle — retention, storage accounting and backups.