Repository navigation
Add the data connector health endpoint to the Preview spec - #631
Merged
Merged
Conversation
GET /data_connectors/{data_connector_id}/health returns aggregated execution
health for a data connector over a requested time range: success rate, latency
and payload size percentiles, breakdowns of HTTP statuses and failure reasons,
and a time series of intervals.
Six details a developer would otherwise have to discover by calling the endpoint: - The default `bucket_size_minutes` divides the range into 300 intervals or fewer, rather than "a width chosen to suit the range". - Interval boundaries align to multiples of the width from the Unix epoch, not to `start_ts`, so the first interval may begin before `start_ts`. - A time-series latency field reports 0 when nothing in that interval carried the measurement, which is indistinguishable from a true zero. - An execution counts as successful only when it completed AND returned a 2xx status; one with no recorded status counts as a failure and appears under `unknown`. - `http_status_distribution` omits executions with no recorded status, so its counts may add up to less than `total_executions`. - Responses are cached for up to a minute. The 200 example's `bucket_start` moves to an epoch-aligned value so it illustrates the alignment rule rather than contradicting it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
zilleeizad-inter
marked this pull request as ready for review
November 3, 2026 15:04
…-openapi # Conflicts: # descriptions/0/api.intercom.io.yaml
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
anubhav-intercom
previously approved these changes
Nov 4, 2026
anubhav-intercom
left a comment
anubhav-intercom
left a comment
Contributor
There was a problem hiding this comment.
Approving. One wording fix inline.
|
|
||
| Metrics from the last 7 days are returned by default. Use `start_ts` and `end_ts` to set the range, which may span at most 14 days. How far back data is available depends on your workspace's data connector log retention. | ||
|
|
||
| An execution counts as successful when it completed and the external service returned a 2xx status. An execution that recorded no HTTP status counts as a failure, and appears in `failure_types_distribution` under `unknown`. |
Contributor
There was a problem hiding this comment.
Drop "and appears in failure_types_distribution under unknown". A failure with no HTTP status is still counted under its own error_type. For example, a timeout records status 0 (app/lib/workflow_connector/http_client.rb:52) with error_type faraday_error. unknown only covers failures with no recorded reason, as the changelog and the error_type description already say.
The failure breakdown is keyed on error_type alone, independent of HTTP status: a timeout records status 0 with error_type faraday_error and is counted under that code. unknown covers only a failure with no recorded reason, which the error_type description already states. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
anubhav-intercom
approved these changes
Nov 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why?
Developers using data connectors can fetch execution results one at a time, but nothing tells them how a connector is doing overall — how often it succeeds, how slow it is, and what its failures actually are. This adds the Preview spec for the endpoint that answers that.
How?
Adds the path and its response schemas to the Preview description, keeping the failure-reason values aligned with the vocabulary the execution results endpoint already filters on.
Notes for reviewers
Draft until the endpoint it describes is available, so the spec does not land ahead of the API.
Generated with Claude Code