A report built on a table that stopped loading yesterday looks fine and is wrong. Data Freshness keeps a cadence for each source you register: a BigQuery table's storage_last_modified_time, a Snowflake table's LAST_ALTERED, a PostgreSQL table's insert counters, a Fivetran connection's succeeded_at, an Airbyte connection's last succeeded job.
Before each scheduled report it checks every input against its cadence. When one is late, it names the input, how late it is, and which reports depend on it, and proposes what to do: hold the report, disable its Power BI refresh schedule, trigger a re-sync, or open a ticket. None of those happens until a person approves it. Reports that depend on nothing stale go out as normal.
This is a reference listing. It documents what Fibric would read from Data Freshness and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.
Inputs
storage_last_modified_time per table from the BigQuery INFORMATION_SCHEMA.TABLE_STORAGE view, compared with the cadence you set
LAST_ALTERED and ROW_COUNT from the Snowflake INFORMATION_SCHEMA.TABLES view for each registered table
n_tup_ins and n_live_tup from pg_stat_user_tables in PostgreSQL, so a table with no new inserts since the last check is caught
sync_state, update_state, succeeded_at, and failed_at from Fivetran connection details
Job status, startTime, lastUpdatedAt, and rowsSynced from the Airbyte jobs endpoint, filtered by connection
The dependency map you keep: which report reads which tables, and when each report is due
Proposed actions
Target capability: propose a hold notice to the report's Slack or Teams channel naming the stale input and the last good load
Target capability: propose disabling a Power BI semantic model's refresh schedule (enabled: false) until the input catches up
Target capability: propose a Fivetran sync for the late connection through POST /v1/connections/{connectionId}/sync
Target capability: propose a Jira issue to the pipeline owner with the table, the expected cadence, and the observed gap
Target capability: propose lifting the hold once the input's load time passes the report's cutoff
Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.
What you can build
Hold the Monday report when Sunday's load failed
Fivetran shows failed_at after the last succeeded_at for the orders connection. Data Freshness proposes a hold notice in Slack for the two reports that read that table, and a re-sync of the connection.
Pause a Power BI refresh instead of publishing a gap
The Snowflake table behind a semantic model shows LAST_ALTERED two days old and an unchanged ROW_COUNT. The operator proposes disabling the model's refresh schedule and a Teams notice to its readers.
A PostgreSQL events table's n_tup_ins has not moved since the previous check, though the application is up. The operator proposes a Jira issue to the owning team with the counter history.
A registry of sources with an expected cadence each, and a map of which report depends on which source
Metadata read access: INFORMATION_SCHEMA in BigQuery or Snowflake, or pg_stat_user_tables in PostgreSQL
A Fivetran or Airbyte API key if sync state is part of the check
For refresh holds, a Power BI dataset owner's consent and the Dataset.ReadWrite.All scope
Authentication
Data Freshness keeps no credentials. It reads table metadata through the BigQuery, Snowflake, and PostgreSQL connectors, sync state through Fivetran and Airbyte, and acts through the Power BI, Slack, Microsoft Teams, and Jira connectors you connect.
Limits
A table can be modified and still be wrong. Freshness checks load time and row movement, not content.
Power BI refresh schedules can be changed only by the dataset owner, and a disable request must carry no other change.
Snowflake's LAST_ALTERED moves on background maintenance as well as on loads, so it is paired with ROW_COUNT before a table is called fresh.
It proposes holds and re-syncs. It does not repair a pipeline or edit a report.
Access and pricing
Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.
Each action separately: the hold notice, the refresh-schedule change, the re-sync, the ticket, and later the lift of the hold. Every proposal names the input, the expected cadence, the last good load, and the reports affected. You can approve the notice and decline the re-sync.
What record does it leave?
Per check: every source read, its observed load time or sync state, whether it passed its cadence, the reports it gates, each proposal made, and who approved or declined it. When a hold is lifted the record shows the load that cleared it.
Does it ever hold a report on its own?
No. A stale input produces a proposal, not a hold. Until a person approves, nothing changes in Power BI, Fivetran, Slack, Teams, or Jira. It reads metadata only.
Ask about Data Freshness
Ask about the capabilities and requirements in this listing.
This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy