Skip to main content

Reports

Reporting turns stored events into a repeatable, shareable answer: an FPL processor gathers and shapes the data, a report binds that processor to a set of arguments, a schedule decides when it runs, and a dashboard displays the result. This section teaches the workflow end to end: how to author a report, how to build the dashboard that presents it, and how to schedule and deliver it. The screens involved are shown under The Reports Pages below.

What a Report Is​

The word is overloaded. A report is a saved FPL processor plus a declared set of arguments, which produces a result set that can be rendered as dashboard widgets, exported, or consumed by API. It differs from an ad-hoc search on Datalake Search (v1: Data Lake → Search) and from a streaming detection in Detections: a report runs on demand or on a schedule over stored data, and its output is a document, not a stream.

Report Categories​

On the FPL reports tab of Reports, report processors are grouped by folder (such as AD, Office365, SentinelOne, and System), with a filter button per folder.

Dashboard reports render widgets, plain reports produce tabular or document output, and tasks perform work (such as loading a resource table) rather than producing a report to read.

How Reporting Works End to End​

The lifecycle, in order, with each step naming the page where it happens.

1. Author the Processor​

Write the FPL that queries and shapes the data, in the report editor reached from + Add Report on the FPL reports tab of Reports (v1: Reports → Processors → Add Report). Covered in Creating a Report.

2. Declare Arguments​

The report's typed parameters and defaults (commonly a from/to window with defaults such as ago(7d) and now()) let the same processor be re-run over different ranges and subjects without editing code.

3. Run and Iterate​

Run the report from the editor (in the v1 interface, also from the Scheduler's run dialog), read the output, and refine. Trace and error logs in the editor are the primary debugging surface.

4. Present the Result​

The widgets that render the result, and the dashboard that groups them. Covered in Dashboards.

5. Schedule and Deliver​

Set the recurrence, timezone, and export targets, and monitor prior runs. Covered in Scheduling and Delivery.

6. Maintain​

Clone, export, and import report definitions to move them between accounts; review run cost and duration; retire reports nobody reads.

The Reports Pages​

How the product's screens map onto the lifecycle above.

Dashboard​

Reports, in the navigation rail, opens on its Dashboard tab (/v2/reports): System dashboard reports for this site. It holds one card per built-in report (the Event Ingress Report, the Ticket Analysis Report, and the Usage Report), each opening as an interactive dashboard over a time range you choose, with a Download report button. All, Behavior, and Ingress filter the cards by kind.

Reports page on the Dashboard tab, with a full-width search field above the All, Behavior, and Ingress filters, and cards for the Event Ingress Report, Ticket Analysis Report, and Usage Report

These are the platform's own reports, not dashboards rendered from your report processors; those are viewed in the v1 interface, on Reports → Dashboard: see Dashboards.

Processors​

The FPL reports tab of Reports (/v2/reports?kind=fpl) is the authoring surface: FPL report processors for this site. It lists the report processors in a table with Report (the name, with its description beneath), Folder, and Updated (UTC), with a search field (Search reports by name, description, folder, or FPL script…) above a filter button per folder, and + Add Report in the header. Click a row to open the report in the editor.

Reports page on the FPL reports tab, with a full-width search field above the folder filter buttons, and a table of report processors with their folder and last-updated date

The run history of every report processor is on Admin console → Management → Report Tasks: one row per run, with its report, schedule, user, status, duration, and cost. Click a row to open the report with that run's output loaded.

Scheduler​

Configuration → Report Scheduler (/v2/configuration/report-scheduler) is the operations surface: a table of schedulable reports with Edit and Schedule actions per row (and a red Delete on reports the site can remove), and a Prior Runs count that opens each report's run history (ID, status, launch time, duration, and cost).

Report Scheduler page with a Refresh button, a Search reports field, a Last Updated sort drop-down, and a table of reports with Group, Name, Description / Arguments, Schedule, Prior Runs, Updated On (UTC), and Edit and Schedule actions on each row

The table's columns are Group, Name, Description / Arguments, Schedule, Prior Runs, Updated On (UTC), and Actions. A Search reports field and a sort drop-down sit above it. Running a report on demand with its run dialog, and importing or exporting report definitions, are done in the v1 interface, on Reports → Scheduler.

How the Three Relate​

The three are easy to confuse: a processor on the FPL reports tab (v1: the Processors page) is the code, a report row on the Scheduler is that processor bound to arguments and a schedule, and a dashboard on the v1 Dashboard page is the rendered output of the most recent run. Note that a report's name and its processor's name can differ.

Cost and Resource Use​

Reports read stored data, and stored-data reads are billable. Run cost is visible in the Cost column of the Scheduler's run history (and, in the v2 interface, of Admin console → Management → Report Tasks). Bounded time ranges, index selection and avoiding overlapping schedules are what keep it down. See the Usage Report (v1: Platform → Usage).

Last updated on