Jobs & Monitoring

Jobs

Navigate to Admin > Process > Jobs to monitor document processing and ingestion jobs.

Enrichment Jobs

Enrichment jobs (post-processing rules that enrich the knowledge graph) are managed separately. Navigate to Admin > Graph > Rules and use the Executions tab to view all enrichment jobs, or open a specific rule and go to its Jobs tab. Enrichment jobs support cancel and resume.

Job List

The jobs page displays a table of all jobs with:

• Job type and name
• Status (running, completed, failed)
• Start and end times
• Progress information

Starting Jobs

Click Start New Job to manually trigger a processing job. This is useful for:

• Initial document ingestion after setup
• Re-processing after configuration changes
• Running one-off processing tasks

Job Details

Click any job to view detailed information:

• Execution timeline
• Files processed and their status
• Error logs for failed files
• Processing metrics and statistics
• Graph evaluation (unstructured full-ingestion jobs) — see Graph Evaluation

Parse-Only Jobs

Data sources configured with Ingestion Type: Parse only run a shortened pipeline that stops after parsing. The job detail page surfaces parse-only mode with several visual affordances:

• Parse Only badge — The job header shows an amber “Parse Only” badge next to the scan type. Full ingestion jobs show an indigo “Full Ingestion” badge.
• Dimmed phases — The Processing Phases pipeline still renders all six stages, but Classify and Ingest appear dimmed with a “Parse-only mode” caption and a dashed border to indicate they are skipped. A section-level “Parse-only pipeline” badge is shown in the top-right of the card.
• Parsed status — Files that complete successfully show a green Parsed badge (terminal status parsed_only). This is the equivalent of Ingested for full-mode jobs.
• Context-aware file status filter — The status filter dropdown on the Scanned Files table hides statuses that cannot apply in parse-only mode (Pending Classification, Classifying, Classification Failed, Pending Ingestion, Ingesting, Ingestion Failed, Ingested). All failure variants are consolidated into a single Failed option.

Async Parse Jobs

The Jobs page has a Job type switch with two choices: Scans (the default) and Async parse. Async parse lists the files that async document parsing reads in the background for the knowledge-model copilot, the main chat, Agent Flows and Test Ingestion. These are not scans of a data source, so they never appear under Scans, and the scan search, filters and Start New Job button do not apply to them. The choice is kept in the page address (jobType=async), so you can bookmark or share the view. The list has one row per submission, newest first, 20 to a page. It re-reads itself every few seconds while a job on the page is queued or running. Click a job to open its page (/admin/jobs/async/<job id>). It shows the source, who asked, the files done, when the job was created, started and finished, and its Duration, then one row per file:

• File — its name, type and size
• Preview — an eye icon (tooltip Preview parsed text) that opens the text the parser stored for the file, in the window described under Previewing the text of a file. It is there for a Done file; any other file shows —, because it has no text to show. It is enabled for the person who requested the job only: for anyone else it is greyed out, and its tooltip says Only the person who requested this job can preview its text
• Status — Queued, Parsing, Needs OCR (a scan waiting for its owner’s Read with OCR or Skip), Waiting for OCR, Reading with OCR, Done, Failed or Cancelled. A finished file can carry a note: Scan not read (its pages are pictures and nobody read them with OCR) or Partial text (only part of the file could be read)
• Parser — the parser that read it
• Pages — the page count, when it is known
• OCR used — Yes when the text came from OCR (hover for the file’s OCR mode)
• Took — how long the file took, from its first start to when it settled (see below)
• Error — why a failed file failed

The page re-reads the job while any of its files is still moving. Back returns to the Async parse list. Duration and Took are written in at most two units: 20s, 1m 20s, 2m, 1h 5m, 1d 2h, and <1s below a second.

• Duration runs from the first time one of the job’s files started being read to the settling of the last file. While the job is running it counts up, in grey (tooltip Still running), and it keeps counting while the job’s only unfinished file waits for its owner’s OCR choice. It shows — until a file has started, and for a job whose files all came from earlier results and never ran.
• Took is the same for one file. A file being read counts up in grey (Still running). A file that waits shows — (tooltip Waiting for the parser, or Waiting for an OCR choice). The time of a settled file includes any wait for its owner’s Read with OCR or Skip, so a scan can show minutes where the OCR took seconds: when OCR ran, the tooltip says OCR took 47s. Counts from the first start, including any wait for an OCR choice. A file that reused an earlier result never started and shows —.

A finished job stays on the list for as long as one of its files does: files are deleted 7 days after they finish, unless a chat file or a copilot document still uses them (see What happens to a file that waits). The async parser’s limits and timings (how long a file may wait, how many files a person may queue, how much memory and time one reading may use, and the rest) are not set on this page. They are in the Async Parsing tab of Administer > System Settings; see System Settings.

Flow Executions

Navigate to Admin > Monitoring > Flow Executions to see the execution history of all automated flows. The executions page shows:

• Flow name
• Execution status
• Start and end timestamps
• Duration
• Error information (if applicable)

Click any execution to see step-by-step details.

System Logs

Navigate to Admin > Monitoring > Logs to view system-level logs.

Filtering Logs

Log Entries

Each log entry shows:

• Timestamp
• Log level (color-coded)
• Message content
• Source module

Logs stream in real-time, so you can monitor system activity as it happens.

Scan Order Statistics

Access scan order statistics from the admin dashboard to review ingestion metrics:

• Number of files discovered per data source
• Files successfully processed
• Files pending processing
• Files that failed processing with error details
• Processing throughput metrics

Service Scaling

Navigate to Admin > Monitoring > Scaling to monitor and manually scale platform services. The dashboard shows each service’s health, current and maximum replicas, and the ingestion pipeline flow. Core infrastructure services are always on and cannot be scaled manually. See Service Scaling for the full dashboard layout, per-service settings, force-scaling (single and batch), and the scaling event audit trail.

Startup Health

Navigate to Admin > Monitoring > Startup Health to verify app-level migrations, seeds, indexes, and cache readiness (including lineage indexes and the optional read performance indexes). This is separate from replica scaling. Reading the page requires Monitoring read access. Verify and Ensure require Monitoring write access. Force ensure on lineage indexes or read performance indexes must only run in a maintenance window — creating indexes on a populated FalkorDB graph can stall the database. See Startup Health for Verify vs Ensure, status meanings, and deploy notes.

Graph Health

Navigate to Admin > Monitoring > Graph Health to compare the live graph with the published ontology and repair mismatches from the same page. Scan does not change the graph. Fix does. Reading the page requires Monitoring read access. Scan and Fix require Monitoring write access. See Graph Health for each check, what it repairs, and what it only reports.