3. Confirm Data Is Arriving

The third step of the Quickstart: prove that the source you just connected is actually delivering data, before you spend time searching for events that were never ingested. This page is for the administrator who has just installed an application.

It is built around three independent checks in three different places (application health, ingress volume, and storage-side queueing) because each one fails differently, and knowing which of the three is wrong tells you where to look.

Before You Begin

You have completed step 2, and some time has passed. How much depends on the feed:

Feed	Index	Expect first data
Entra sign-ins	AzureSigninLogs	Within about an hour
Entra directory audit	MSEntra (AzureAudit on an older deployment)	Within about an hour
Office 365 unified audit log	Office365	Up to 12 hours on a new subscription

The Office 365 figure is Microsoft's own warning about newly created Management Activity API subscriptions, not a Fluency delay. It is the single most common reason a correct install is mistaken for a broken one. Run the three checks below now (they will tell you the pipeline is healthy), then come back for the data.

The Three Checks, and Why There Are Three

The application status tells you whether the platform is trying. The ingress charts tell you whether bytes are arriving. The data lake tells you whether they are being written. A problem shows up in exactly one of the three, which is what makes the diagnosis quick: an application in error (v1: Aborted) is a credential or configuration problem, an application that is Running with no ingress is a source-side problem, and ingress with a growing queue is a storage-side problem.

Check 1: Application Status

v2 interface

1. In the navigation rail, open Applications. It lists every installed application as a table row, below a row of status counters.
2. Locate your application. Each row names the template with the instance's display name beneath it (Office365-Audit over Default for this quickstart, unless you changed the display name), so the same template installed twice appears twice under different display names. Type in the Search field to narrow the list.
3. Click the application's row to open its details page.

The status filters above the table (All, Running, Attention, Error, and Disabled) narrow the list to the applications in one state, and Board shows the same applications as cards.

Classic v1 interface

1. Open Platform → Applications. It opens on the Installed Applications view, one card per application.
2. Locate your application. Cards are named application type: instance name (Office365-Audit: Office365-Audit for this quickstart, Microsoft Defender: Default for another template), so the same template installed twice appears twice under different instance names.
3. Expand the card with the arrow at its left edge to see the pipeline the application built, and click the blue eye button at the card's right edge to open its details panel.

The round chevron button in the page header expands or collapses every card at once; its tooltip flips between Expand All and Collapse All.

What a healthy application looks like

v2 interface

A healthy application carries a green Running badge, and its row's Signals column shows a strip of activity bars with how long ago it last reported, such as 0s ago. In / Out gives the data it has received and sent.

Its details page opens with a summary card: the application, its status badge, and its In / Out, Error Bytes, Drop Rate, and Last Event. Below it, the Pipeline card draws the components the install created, left to right in the direction data flows: each Source with its type, the Router with the Pipes it runs, and the Destinations, with the data lake indexes the application writes to in a row beneath the diagram.

At the bottom, Parameters shows the values the application was installed with, in the wording of the install form, with the client secret masked (******), and Actions lists every setup step the install carried out, one addDatalakeIndex line per index it created among them.

Nothing an install records can be edited afterwards. Changing a credential means uninstalling the application and installing it again; to uninstall, click Uninstall at the top right of the application's details page.

Classic v1 interface

A healthy application carries a green Running status badge. Expanding its card draws the pipeline it installed, left to right from source to destination, each node labelled with its object name and object type, most nodes carrying a small throughput sparkline of recent volume. Outlines and connectors are colour-coded: green where data is flowing, grey where the path is idle, red on a node that is in error.

For this quickstart's application the diagram has three Plugin Data Source nodes, one per collection path, feeding two routers, which fan out to Data Lake and Mgmt Queue destinations.

The details panel behind the eye button is titled Viewing Office365Audit Application. It opens with Details: Application (the template it was installed from), Name, Display Name, and the Status badge, followed by the Parameters the application was installed with, shown back as tenantID, clientId, clientSecret (masked), datalake, index, and azureAuditIndex, and an Actions list of every pipeline object the install created.

Every field in this panel is read-only. Changing a credential means uninstalling with the red Uninstall button and installing again.

What an unhealthy application looks like

v2 interface

• A red Error badge means the application stopped on an error, or has reported errors in the last hour. Its details page shows the error message beneath the summary figures, a data lake index name already taken in that lake being the usual cause of an application that stops straight after install. A source that cannot start, a rejected credential for example, is listed there under Data source errors with the error the source reported. The Error counter and the Error filter on Applications gather the applications in this state.
• Non-zero Error Bytes on an otherwise-Running application means some of its data is failing even though the application as a whole is still running. Error bytes by component, a collapsed section in the details page's summary card, lists the error bytes per pipeline component, which tells you which stage to look at.
• Running, with a dash under In / Out and Last Event, is the "running but idle" case: the application is trying and nothing is arriving. That is normal inside the first-content window described above. Once past it, move on to check 2.

Classic v1 interface

• A red Aborted badge means the application stopped on an error. Its details panel adds an Error Message in red under Details explaining why, a data lake index name already taken in that lake being the usual cause.
• A red exclamation mark (!) after an otherwise-Running badge marks a component that is not healthy even though the application as a whole is still running. It matches a red-outlined node in that application's pipeline diagram, which tells you which stage to look at.
• Running, no error, no green outlines, and no sparkline volume is the "running but idle" case: the application is trying and nothing is arriving. That is normal inside the first-content window described above. Once past it, move on to check 2.

Check 2: Ingress Charts

v2 interface

1. In the navigation rail, open Reports, and on its Dashboard tab click the Event Ingress Report card.
2. Set the time range with the buttons in the upper left: 1H, 12H, 1D, 3D, 7D, 30D, or Custom. The report opens on 7D; 1H is the right choice for a source connected minutes ago.
3. Read the headline figures and the Ingress activity chart.
4. Read Top indexes and Ingress by index to confirm the data landed in the indexes you expected.

Classic v1 interface

1. Open Platform → Usage.
2. Set the time range for the Current Usage panel with the 1H, 6H, 12H, or 1D buttons; 1H is the default and the right choice for a source connected minutes ago.
3. Read the Ingress Bytes and Ingress Count charts.
4. Read Ingress Bytes By Data Lake and Ingress Count By Data Lake to confirm the data landed in the indexes you expected.

Reading the charts

v2 interface

The report has a Back to Reports link above its title and a Download report button in the upper right. Below the time-range buttons and the refresh button beside them:

• Headline figures: Ingress volume, Events stored, Datalake indexes (the number of indexes in the report), and EPR, the ingress rate per hour.
• Ingress activity: a line chart of ingress over the range, bucketed as the label above it says (for example Volume per 6 hours). Volume and Events switch what it plots, and the index drop-down (All indexes by default) limits it to one index.
• Top indexes: the busiest indexes, each with its volume, a bar, and its share of the total. Click an index to chart it alone.
• Ingress by index: every index with its Data volume, Events, EPR, and Volume share, sorted by data volume. Search indexes narrows it.

The per-index views are the useful ones here, because they answer a question the totals cannot: on a multi-index application, they tell you which of its indexes is actually contributing. Index names carry the lake as a prefix: managed-Office365 is the Office365 index of the managed lake. One index filling while another stays flat is the expected shape in the first few hours, and the sign-in index staying empty is also the expected steady state on a tenant with no premium Entra licence.

Classic v1 interface

The page is titled Platform Usage, subtitled The metrics for data ingress and data searched over the past 30 days, and holds two panels of five bar charts each: Current Usage, which follows the time-range buttons, and Usage In Last 30 Days, which is fixed at thirty days. Every chart shows its unit beneath the title, its total for the window on the right, and a legend beneath identifying the series:

• Ingress Bytes: bytes ingested per interval (Bytes (B)).
• Ingress Count: events ingested per interval (Count), stacked with one legend entry per data lake index.
• Ingress Bytes By Data Lake and Ingress Count By Data Lake: the same two measures stacked by data lake index.
• Search Cost: the cost of bytes scanned by searches, in Cost (millicents).

Hovering over a bar shows a tooltip with the series name, the Time of the interval, and the Value, a bytes figure such as 14.7 MiB. Long index names in the legends are truncated with an ellipsis.

The by-data-lake charts are the useful ones here, because they answer a question the totals cannot: on a three-index application, they tell you which of Office365, MSEntra, and AzureSigninLogs is actually contributing. Two of three filling while the third stays flat is the expected shape in the first few hours, and also the expected steady state on a tenant with no premium Entra licence.

When a chart has nothing to show

v2 interface

When nothing arrived in the range, Ingress by index reads No ingress metrics in this date range. in place of its rows.

Distinguish three cases before concluding anything is wrong: a time range too narrow to include the first delivery, a first poll that has not completed, and a source that is genuinely sending nothing. The first two are answered by widening the range to 1D or 7D and waiting; the third is a source-side question.

Classic v1 interface

A chart with nothing to plot displays No data available in place of the bars. On a fresh instance that is the normal state of Search Cost (nobody has searched yet), and it is not a problem.

On the ingress charts, distinguish three cases before concluding anything is wrong: a time range too narrow to include the first delivery, a first poll that has not completed, and a source that is genuinely sending nothing. The first two are answered by widening the range to 1D (or reading the Usage In Last 30 Days panel) and waiting; the third is a source-side question.

Check 3: Data Lake Index State

v2 interface

1. In the navigation rail, open Configuration and click the Data Lakes card.
2. Find the lake and the indexes your application writes to (for Office365-Audit, Office365 among them). Its details page from check 1 names them all: the datalake and index-name Parameters, and one addDatalakeIndex line per index under Actions.
3. Read each index card.

The page shows one panel per data lake, headed with the lake name and its totals, holding a grid of index cards. Each card summarizes one index:

• The index name and the schema it uses (Schema: followed by the schema name).
• Stored (24H), the events the index stored in the last 24 hours, and Est. Rate, its estimated ingest rate in events per hour.
• An activity sparkline of recent ingest volume.
• A footer with Queue (the number of items waiting to be imported), Merged (when the index was last merged), and Imported (when data was last imported into it).

Classic v1 interface

1. Open Data Lake → Management.
2. Find the lake and the indexes your application writes to (for Office365-Audit, Office365, MSEntra and AzureSigninLogs among them). Its details panel from check 1 names them all: the datalake and index-name Parameters, and one addDatalakeIndex line per index under Actions.
3. Read each index card.

The page shows one panel per data lake, headed with the lake name, holding a grid of index cards listed alphabetically. Each card summarizes one index:

• The index name and the schema it uses (Schema: followed by the schema name).
• An activity sparkline of recent ingest volume.
• Last Merged and Last Imported timestamps.
• A Queue Length counter, shown only when events are waiting to be imported.

Reading the card, carefully

v2 interface

Read the Merged and Imported timestamps, which report two different things: Imported is when data last arrived in the index, and Merged is when it was last merged into it. An index that nothing has reached yet shows a placeholder date for both instead of a real one: Dec 31, 1 in the example above, on an index with Stored (24H) at 0.

So for a brand-new install, the sequence you should expect to see on each index card is:

1. Both timestamps at the placeholder date: the index exists, nothing has arrived yet.
2. A real Imported, Merged still at the placeholder: data is arriving but has not yet been merged. This is a healthy intermediate state.
3. Both timestamps recent: data has arrived and been merged, and Stored (24H) counts it.

Classic v1 interface

Red does not mean "no data"

Card colour reflects merge state, not import state. A card is green once the index has been merged, and red while its Last Merged value is still the zero-date placeholder Dec 31st 0000.

A red card can carry a perfectly real Last Imported timestamp: that is an index where data has arrived but has not yet been merged into it. Reading red as "nothing arrived" and re-opening an ingest investigation that is already solved is the most common mistake on this page. Read the two timestamps, not the colour.

So for a brand-new install, the sequence you should expect to see on each index card is:

1. Red, both timestamps at the zero date: the index exists, nothing has arrived yet.
2. Red, with a real Last Imported: data is arriving. This is a healthy intermediate state.
3. Green, with both timestamps recent: data has arrived and been merged.

What queue length tells you

v2 interface

Queue counts the items waiting to be imported. A queue that rises during a burst and drains is normal, and on a first backfill it is what you want to see. A queue that only ever grows is the signal that ingestion is outrunning writing; capture the number and raise a support ticket rather than changing anything.

Queue 0 is the normal steady state, meaning nothing is waiting. It is only good news if checks 1 and 2 also show activity: an index with an empty queue and no ingress is simply an index nothing is reaching.

Classic v1 interface

The Queue Length counter appears only when events are waiting to be imported. A queue that appears during a burst and drains is normal, and on a first backfill it is what you want to see. A queue that only ever grows is the signal that ingestion is outrunning writing; capture the number and raise a support ticket rather than changing anything.

No counter at all is the normal steady state, meaning nothing is waiting. It is only good news if checks 1 and 2 also show activity: an index with an empty queue and no ingress is simply an index nothing is reaching.

How to Tell It Worked

All three checks agreeing is the pass condition:

v2 interface

• The application is installed and badged Running, with traffic under In / Out and a recent Last Event.
• The Event Ingress Report shows non-zero Ingress volume and Events stored within the last day, attributed to the expected indexes.
• The Data Lakes page shows the application's indexes, with a real Imported time on at least one and no persistently growing Queue.

Classic v1 interface

• The application is installed, badged Running, with green outlines on its pipeline diagram.
• The Usage page shows non-zero Ingress Bytes and Ingress Count within the last day, attributed to the expected indexes.
• The Management page shows the three indexes, with a real Last Imported on at least one and no persistently growing queue.

Two of three passing is enough to continue if the third is the Office 365 index still inside its first-content window.

If It Did Not Work

What you see	What it means	Where to go
Application in Error (v1: Aborted)	A credential or configuration error; the error message names the cause	Back to step 2
Application Running, no ingress, and it is past the first-content window	The platform is connected and the source is producing nothing it can read	Verify unified audit logging is on, and that the nine permissions all read Granted
Ingress present, but in the wrong index	A sink pointed at the wrong destination, or an index name changed at install	Check the application's Parameters in its details
Ingress present, queue only ever grows	A storage-side or capacity problem	Capture the counter value and raise a support ticket
Everything looks right, but the volume is implausibly small	Filtering in a pipe, or a source scoped more narrowly than intended	No data arriving
AzureSigninLogs alone is empty	The tenant has no Entra ID P1 or P2 licence	Expected: nothing to fix

Next Step

4. Run Your First Search: go find the events you just confirmed.

Related

• Applications, Reports, Data Lakes: the three pages this step uses, control by control (v1: Platform → Applications, Platform → Usage, Data Lake → Management)
• No Data Arriving: the full diagnostic path when a source goes quiet
• Data Storage: how indexes and retention work
• Key Concepts: ingress, storage, and scanned volume defined
• FAQ