Composite, apdex × inverse error-rate × inverse incident-count × SLO compliance. The CXO single-number.
At a glance
A 0, 100 composite that compresses four Datadog signals (Apdex, error rate, open incidents, SLO compliance) into one number a non-engineering owner can read at a glance. Designed for the question “is my store fast enough and healthy enough to take orders right now, yes or no?” This is the merchant translation of an SRE dashboard.
Calculation
Calculated automatically from your Datadog data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK home and garden brand on Shopify with Datadog APM instrumented across web, checkout, search, and the inventory worker. Snapshot taken on 28 Apr 26 at 14:05 GMT.- Error rate is dragging the composite the most. A 1.6% error rate cost six composite points. The merchant should open Error Rate by Service to see whether it concentrates on the checkout service (where it directly maps to lost orders) or on a non-revenue path like the inventory worker (where it costs operations team time but not revenue today).
- One open SEV-2 incident. Search latency degraded means shoppers can browse but find-product is slower than usual. Conversion will dip if it persists; pair with Conversion Drop During Incidents to quantify.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in Datadog: Datadog does NOT provide a single “Operational Health Score”. This card is a Vortex IQ composite synthesised from four Datadog-native screens. Open each independently to verify a component:Service Catalog for per-service Apdex and error-rate context. APM → Service List for the latency and throughput inputs feeding Apdex. Monitors → Manage Monitors for the alert/monitor-state count feeding the incident component. SLO List for the SLO compliance component. Incidents for the open-incident severity feed.Why our number may legitimately differ from Datadog’s component values:
Cross-connector reconciliation:
Known limitations / merchant FAQs
I am a non-engineering founder. Why is this card on my dashboard? Because every minute the score is below 70 is a minute when shoppers are bouncing, checkouts are timing out, or search is failing. The score is the merchant-readable version of an SRE dashboard. You do not need to triage Apdex or read traces; you need to know when to phone the engineering team, ask whether the on-call has acknowledged the page, and whether to pause paid-media spend until it is fixed. What is the difference between this card and “Active Incidents”? Active Incidents is a count (1 SEV-1, 2 SEV-2, etc). Operational Health Score is a 0, 100 number that also reflects performance degradation that has not yet triggered an incident. The composite goes amber before incidents are declared, which is its highest-leverage use: catch the problem during the 5-15 minutes between “metrics moving” and “human declares incident”. Why is the score below 70 but everything looks fine on Datadog? Three usual causes: (1) An open SLO breach you have not noticed, the SLO compliance component reads the worst SLO in your account, so a single neglected90.0% target on an internal API can drag the score; (2) A SEV-3 incident that nobody resolved, the incident component still penalises 10 points per open SEV-3; (3) Apdex below 0.85 on the storefront service even when there are no errors, which is the “site is up but slow” pattern. Open the four component cards listed in At a glance to identify which one is dragging.
Does this score include log volume or log errors?
No. The composite uses Metrics, Monitors, Incidents, and SLOs. The Logs API is intentionally excluded because Log Management is a paid tier add-on and many merchants have it disabled. If your Datadog account does not have Log Management enabled, the Logs API returns 400 No valid indexes and Vortex IQ logs that as INFO once and skips remaining log KPIs, but the Operational Health Score itself is unaffected.
My Vortex IQ account dashboard says my store is healthy but a customer just emailed to say checkout is broken. Is the score wrong?
This is the classic “Datadog says everything is fine but customers are complaining” pattern, and it is real. Three places to check, in order: (1) Open Critical-Path Tests Status, if the synthetic checkout test is failing while APM looks fine, the regression is in a code path Datadog is not instrumenting (third-party script, payment iframe, browser-only error); (2) Open GA4 Property Health and JS Errors / Session, browser-side errors do not appear in server-side APM; (3) Check your store on a fresh device and incognito tab, real-user monitoring (RUM) catches what synthetic and APM cannot. The composite is good for server-side health; for shopper-side health, RUM and synthetic are required.
What does “RUM vs APM” mean in plain English?
APM (Application Performance Monitoring) measures the server: how fast did your code respond when the request reached it. RUM (Real User Monitoring) measures the browser: how fast did the page actually feel for a shopper, including network time, JavaScript execution, third-party scripts, and ad-blocker interference. APM can be perfect while RUM is broken (slow CDN, broken payment widget, blocked tracking script). The Operational Health Score reads APM-side; for RUM-side use Frustrated User Sessions and Page Load p95.
My account spans three Datadog organizations (multi-account aggregation). What does the composite show?
Vortex IQ supports multiple Datadog connector instances (one per organization) via the standard “Add another connection” flow. Each instance gets its own Operational Health Score; the dashboard does not blend them. If you want a single number across all three, use the “Stacked Panel” feature on the Nerve Centre to compare three scores side-by-side.
Why is the alert threshold 70 and not 80 or 90?
The 70 threshold is calibrated against historical merchant data: scores of 70-89 are common during normal noisy operations and most resolve themselves within 30 minutes. Scores below 70 statistically correlate with measurable revenue impact within the next hour. Setting it at 80 produces too many false-positive pages; setting it at 60 misses real incidents. You can tune the threshold per organization in Vortex IQ → Settings → Alerts, but 70 is the default for a reason.
The score has stale-looking values during overnight hours when traffic is low. Is something wrong?
At very low traffic (under 50 req/min) Apdex and error rate can both be statistically noisy, a single slow request moves Apdex meaningfully. Vortex IQ marks the score as “low-confidence” between 02:00 and 06:00 in the account timezone if request volume drops below the threshold; the displayed score is still computed but the alert engine widens its tolerance. This prevents 04:00 false pages.