Post 1 of the Integration Health series
- Green status pages coexist with broken integrations. Expired OAuth tokens, schema changes, missed schedules, and deleted webhooks never show up as platform outages.
- Teams define what counts as expected work. Prismatic supplies execution history and an Execution Overdue alert, while your team decides the exclusions, how retries count, the segmentation, and the target.
- Per-customer results come before portfolio averages. Report per integration and per customer over a rolling window like 30 days, and track first-run successes separately from successful retries.
Your dashboard reports 100% success because every recorded execution completed.
Meanwhile, a scheduled Salesforce sync never ran, so the customer's data is outdated. Why? A metric based only on recorded executions cannot count work that never produced an execution record.
The expected execution success rate closes that gap. This post explains how to define expected work, calculate the rate, and then break out the results so specific failures aren't hidden by the portfolio average.
If your team measures platform uptime but you hear about outdated data from customers, this is for you. The expected execution success rate is useful as soon as you have scheduled or otherwise measurable expected integration work in production.
Watch the video
Watch the overview, or keep reading for the details.
Expected execution success rate
The expected execution success rate is the percentage of expected execution opportunities that complete successfully during a defined period.
Expected execution success rate (%) = Successful expected executions ÷ Total expected executions × 100
The denominator is critical. It includes expected executions that never produced an execution record, such as a missed scheduled run.
For scheduled integrations, define the expected executions first. For event-driven integrations, use this measure only when you have an independent value for the denominator, such as an expected trigger baseline.
For example, if an integration is to run hourly and 695 of 720 expected executions complete successfully in an uninterrupted 30-day schedule, its expected execution success rate is 96.53%.
Expected execution success rate
Platform uptime is something else
Before tracking the metric, separate platform availability from expected work completion:
- Platform uptime – Is the infrastructure available? Unless you run an in-house platform, the vendor is primarily responsible for this.
- Expected execution success rate – Did each expected execution complete successfully for this integration and customer? This is the operational outcome your team needs to monitor.
Your status page can show green while an integration is broken. This can happen when a customer's OAuth token expires, an API returns an unexpected response, a schema change breaks a transformation, a scheduled execution is missed, or someone deletes a webhook. None of these is an outage that shows up on a platform status page, but they can each stop data from going where it should.
Why the denominator matters
A metric that captures only recorded executions ignores those that should have run but never did. The expected execution success rate keeps that data visible because the expected execution remains in the denominator even when no execution record exists.
That makes the metric useful for discovering:
- Missed scheduled executions (including trigger failures)
- Customer-specific credential or configuration problems
- Schema and transformation failures
- API and dependency failures
What Prismatic provides and what you need to do
Out of the box, Prismatic provides:
- Per-instance execution history with timestamps and outcomes for successful and failed executions.
- Monitoring capabilities, including an Execution Overdue alert trigger that helps identify expected executions that didn't occur when an applicable expected-execution interval is configured.
- Alert and execution context such as instance, customer, flow, trigger, step, and execution ID, subject to product configuration and permissions.
- Routing to email, SMS, or webhook endpoints where configured.
You still determine how the metric is defined and broken out for your integrations:
- What counts as an expected execution.
- Which planned-maintenance (or other) periods are excluded.
- Whether recovered executions count as complete and how clean success is reported.
- How the metric is segmented by integration, customer, connector, and time window.
Prismatic provides execution data and operational tooling. Your team defines the rest.
Where you should start
If you are beginning to collect this metric from scratch:
- Define the expected execution opportunity for each scheduled integration and integration type.
- Count successful completions, not starts. Each run counts once, and retries aren't new executions.
- Keep missed executions in the denominator; exclude documented exceptions such as planned maintenance.
- Track successful first-run executions separately from successful retries when it matters for interpretation.
- Calculate the metric over a recent rolling timeframe, such as 30 days.
- Report results per integration and per customer before publishing a portfolio average.
- Monitor for execution failures and overdue expected executions.
Setting a useful target rate depends on the integration, dependencies, and customer impact. The important first step is to establish a baseline for the expected number of executions. Then, you can figure out everything else from there.
Series navigation
← This is Post 1. Start here if you have not already.
→ Post 2 (coming soon)
View all the posts in the Integration Health series.
