Skip to main content

​
Orby campaign diagnostics

Three questions come up about campaigns more than any others: can this send?, why did it fail?, and what rules apply to it? Orby answers all three from your live workspace data with three read-only diagnostic tools: campaign_check_readiness, campaign_failure_reason, and campaign_governance_summary. All three are read-only. They inspect a campaign and report; they never send, never enqueue, and never change data, so they answer immediately without the proposal-and-approval step that data-changing tools require. The same is not true of the campaigns family’s action tools, pause_campaign and resume_campaign: those propose a change and wait for your explicit approval, exactly as described in Tool actions: proposal and approval. This guide covers the read-only half: what each diagnostic reports and how to read its answer. As with every Orby tool, the diagnostics run under your signed-in operator session and role. They read only what your role can already read (campaigns:read), scoped to your organization.

​
campaign_check_readiness — can this send?

Ask in plain language:
“Is the Spring Promo campaign ready to send?”
Orby resolves the campaign (using campaign_search first if it needs the id) and runs the same pre-launch dry run the dashboard’s launch banner reads. The dry run sends nothing, bills nothing, and enqueues nothing, so it is safe to ask as often as you like while you tune a campaign. The answer is grounded in ready_to_launch, which is true only when all five of these hold:
  1. No blocking warnings. warnings is empty: nothing flagged about the audience, the cost estimate, quiet hours, personalization tags, or the journey configuration.
  2. A deliverable audience. audience.deliverable is greater than zero after suppressed, opted-out, missing-address, and hold-out recipients are netted out.
  3. Sufficient balance. cost.sufficient is true: your wallet balance covers the estimated cost.
  4. A reachable primary provider. channel_waterfall.primary_provider_available is true for the campaign’s channel.
  5. Provider checks that actually passed. provider_readiness.status is pass. A status of unverified, meaning the connection state could not be confirmed, is not a pass and keeps ready_to_launch false.
A representative answer when one check fails:
When ready_to_launch is false, the warnings array names the specific failing checks, and Orby quotes those rather than guessing at a cause. When it is true, the same payload gives you the projected scale: deliverable recipients, estimated cost against balance, and any quiet-hours deferral to expect.

​
campaign_failure_reason — why did it fail?

“Why did the Spring Promo campaign fail?”
Orby reads the cause the platform recorded on the campaign: failureReason, with its machine-readable failureCode, the longer failureDetail, and the failedAt timestamp, plus autoPausedReason when the platform paused the campaign itself on a circuit-break. The sent, delivered, and failed counters come along so the cause reads with its scale. A campaign the platform auto-paused mid-send reads like this:
hasFailure is true when either a failure reason or an auto-pause reason is recorded. From your side, “it failed” and “it stopped on its own” are the same question, and both are answered here. When hasFailure is false there is no recorded failure, and Orby says so plainly instead of inventing a cause. If the answer leads you to act, for example pausing a misbehaving campaign, that step is a data-changing tool and pauses on the normal approval card before anything runs.

​
campaign_governance_summary — what rules apply?

“What rules apply to the Spring Promo campaign?”
Orby returns the governance rules in force for that one campaign in a single read: the A/B experiment block, the control hold-out cohort, the quiet-hours window that actually applies (together with the setting it came from), and your organization’s frequency-cap rules, each flagged with whether it bites on this campaign’s channel.
Read it as the answer to “why is this campaign throttled, delayed, or sending to fewer people than the audience size implies”:
  • Quiet hours resolve with precedence: a per-campaign override wins over your organization default, which wins over the platform default. source names the setting that is governing, so a surprising window traces straight back to where you change it.
  • Frequency caps list every organization rule, but only rules whose applies flag is true are in force for this campaign’s channel. The others are configured for your organization but do not bite on this send.
  • The hold-out shows the control cohort carved out of the audience. This is also why audience.deliverable on the readiness check is smaller than the gross audience: held-out recipients are excluded from the send by design.
  • The experiment block shows the committed variants, their traffic split, and the winner settings, so you can see whether a winner has been selected or an auto-promote rule is armed.
Every rule in this summary is a control you own: campaign and organization quiet hours, frequency-cap rules, hold-out percentages, and A/B settings are all configured in your workspace. The summary reports how they resolve for this one campaign.

​
See also