What is ‘Monitoring - Interim Solution'?
Integration Monitoring provides visibility into the health, performance, and status of customer data integrations. It allows you to identify integration issues, review recent run times, and monitor data freshness — helping ensure your pipelines are operating as expected.
With this update, integration monitoring data is now available directly through two database tables: zproviders and ztasks. These replace the previous Tableau-based monitoring report and deliver equivalent information in a more flexible, queryable format.
Why did Two Circles add Integration Monitoring?
This change enables a more scalable and transparent monitoring process. By moving to a table-based structure, customers can:
Access integration health information directly via SQL.
Automate alerts and reports based on integration status and timestamps.
Gain faster, near real-time updates (within a few minutes of each integration run).
This is a temporary step toward a more comprehensive monitoring solution. More communications regarding this to come in Q1 2026.
What customers are affected by this change?
All customers with new/enhanced integrations will use this table-based monitoring approach.
Existing integrations will continue using the DWA Integration Status report until migrated to the new structure.
Customers will be informed when a release includes this monitoring enhancement as part of the integration release communication.
What’s new?
Integration status and task-level information are now stored in two new tables:
zproviders – Integration-Level Monitoring
Provides an at-a-glance view of each integration’s overall health and recent activity.
Column |
Description |
|---|---|
client |
The client name associated with the integration. |
provider |
The system name of the data source provider. |
friendly_name |
User-friendly name of the data pipeline. |
last_step |
The last completed process step ( |
last_timestamp |
UTC timestamp of the most recent pipeline run. |
last_logical_timestamp |
UTC timestamp representing when the pipeline’s status or data last changed. Used for SLA tracking. |
status |
Current state: |
last_error_type |
The class of the most recent exception, if applicable. |
last_error_message |
The description or stack trace message for the most recent error. |
ztasks – Task-Level Monitoring
Represents individual executions of endpoints or tables within an integration step (known as IF Tasks).
Each record can be joined to zproviders via both provider and friendly_name.
Column |
Description |
|---|---|
provider |
Integration provider key. |
friendly_name |
Friendly name of the integration. |
entity |
Endpoint or table associated with the task. |
entity_type |
Either |
step |
The integration step ( |
step_class |
Internal system class ( |
timestamp |
UTC timestamp of when the task executed and completed. |
logical_timestamp |
UTC timestamp of when the data changed, based on task logs. |
duration |
Duration of the task in seconds. |
row_count |
Number of records processed or modified — feature not yet complete; not recommended for monitoring at this time. |
status |
Task result: |
error_type |
The class of the exception that caused an error. |
error_message |
Error description or stack trace. |
Understanding Timestamps
Field |
Meaning |
|---|---|
timestamp |
When the task or pipeline was last run. |
logical_timestamp |
When the underlying data last changed. Used for assessing data freshness. |
Note: For load step tasks,
logical_timestampmay not populate as expected (often returning-1records). This will be resolved in future releases.
What is not affected or included?
Existing integrations not yet migrated to this model will continue to use the DWA Integration Status report.
row_count,inserts,updates, anddeletesare not yet fully implemented — they should not be relied upon for monitoring integration statuses at this time.The
last_logical_timestampfield is in early use and may not yet reflect all scenarios consistently.SLA notifications and automated dashboards are not part of this interim release but will be included in the Q1 2026 update.
How does a customer enable this feature?
No enablement is required.
For any new integration release, these tables (zproviders and ztasks) will be automatically available for you to query via SQL in your environment.
You can use standard SQL queries to monitor integration health.
Example queries include:
-- Identify failing integrations SELECT * FROM zproviders WHERE status = 'FAILING'; -- Review the most recent run times SELECT provider, last_timestamp FROM zproviders; -- Drill into task-level errors SELECT * FROM ztasks WHERE status = 'ERR';