Skip to content

Synthetic Monitoring

Also called: Synthetic checks · Synthetic probes · Synthetic transaction monitoring

Definition
Scheduled robot checks that run a real user journey, such as sending a test WhatsApp message and awaiting its status, to catch outages early.

Exhibit A

How long did the probe's message take?

5 / 5
0.020.040.060.04.4 s
  • Healthy0.0–15.0 s
  • Slow: warning15.0–45.0 s
  • Failed run45.0–60.0 s
Reading 5 of 5Healthy

10:20 probe

4.4 s

Recovered after the webhook workers were scaled up: sent in 4.4 s. The alert resolves automatically.

Five probe runs, five minutes apart. The needle shows seconds from the send call to the sent status webhook, against the probe's healthy, slow and failed thresholds (illustrative).

10:20 probe: 4.4 s — Healthy zone. Recovered after the webhook workers were scaled up: sent in 4.4 s. The alert resolves automatically.

What is synthetic monitoring?

Synthetic monitoring is the practice of running scripted, artificial transactions against a system on a fixed schedule and checking the results. Instead of waiting for real users to hit a problem, a robot plays the part of a user every few minutes — logs in, places a test order, sends a message — and records whether each step succeeded and how long it took.

For a WhatsApp integration, the most valuable probe follows one message the whole way. Your scheduler calls your own send service, which calls the Cloud API, which delivers to a dedicated test handset; your webhook endpoint then receives the sent and delivered message status updates and the probe confirms they arrived within a threshold. That single check covers your API, queue, workers, access token, the phone number's status, Meta's platform and your webhook ingress at once.

Synthetic monitoring complements other signals rather than replacing them. A health check probes individual instances from inside the platform and says whether a process is up; real-user monitoring and the SLIs behind an SLO measure what actual traffic experienced. Synthetics are the only signal that still works at 3 am when there is no traffic, and the one most likely to notice an expired token or a removed webhook subscription — failures that make no noise of their own.

Key takeaways

  • Synthetic monitoring runs scripted test journeys on a schedule, from outside your system, to prove the whole path works before customers notice it does not.
  • For WhatsApp, a probe sends a real template to a test handset and times the sent and delivered status webhooks.
  • A health check asks one instance whether it is alive; a synthetic probe proves a message can actually travel end to end.
  • Probes are real, billed messages: one every five minutes is 8,640 a month, each charged at its template category's rate.
  • Page on consecutive failures or failures from two locations, so a single flaky run does not wake anyone.

Why does synthetic monitoring matter?

The worst WhatsApp outages are silent: an expired access token, a webhook subscription dropped during an app change, a restricted number, a lapsed TLS certificate on the webhook endpoint. Nothing errors loudly — messages simply stop going out or statuses stop coming back, and the first report is an angry customer. A synthetic probe turns 'no news' into a failing check within minutes, gives support a factual answer to 'is WhatsApp down?', and builds a steady latency baseline for spotting slow degradation.

How does synthetic monitoring work?

  1. Provision a test handset

    Use a dedicated phone and number that stays online, charged and on a reliable network, and has opted in to receive the probe messages. Its only job is to receive them.

  2. Send through your real path

    Schedule the probe every one to five minutes to call your own send endpoint — not the Cloud API directly — with a utility template and a unique probe ID passed through as biz_opaque_callback_data.

  3. Wait for the statuses

    Have the statuses webhook handler record any status that carries a probe ID. The probe passes when sent arrives within its threshold and delivered within a longer one; a slow sent is a warning, a missing one a failure.

  4. Run from more than one place

    Trigger probes from two regions or networks, so a fault in the probe runner itself can be told apart from a real outage.

  5. Alert on patterns, not blips

    Set alerting to page after two or three consecutive failures or a sustained latency breach, and attach the step that failed, the error code and the time of the last good run.

Example: Catching an expired token before a Kolkata sale

A Kolkata electronics store probes every five minutes with a utility template sent to a handset in its office. At 2:10 am the probe fails at the first step: the send endpoint returns error 190 because a long-lived user token, used by a forgotten script, has expired. The on-call developer is paged after two failed runs, switches the script to a system user token and confirms the next probe gets sent in two seconds and delivered in four. By 9 am, when the sale broadcast starts, nothing is broken and no customer ever noticed.

Synthetic monitoring in code

// Runs every 5 minutes from two regions.
import crypto from "node:crypto";
 
const SENT_WARN_MS = 15_000; // a slower sent status is a warning
const SENT_FAIL_MS = 45_000; // no sent status by now: the run fails
const DELIVERED_MS = 90_000; // delivered within 90 s (handset must be online)
 
export async function runProbe(region) {
  const probeId = "probe-" + region + "-" + crypto.randomUUID();
  const started = Date.now();
  const res = await fetch("https://sender.example.internal/v1/send", { // your own service
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      to: process.env.PROBE_NUMBER,
      template: "status_check",
      callbackData: probeId,          // forwarded as biz_opaque_callback_data
    }),
    signal: AbortSignal.timeout(5_000),
  });
  if (!res.ok) return report(region, "send_failed", { status: res.status });
 
  const sent = await waitForStatus(probeId, "sent", SENT_FAIL_MS);
  if (!sent) return report(region, "no_sent_status", { waitedMs: SENT_FAIL_MS });
  const sentMs = sent.at - started;
  const delivered = await waitForStatus(probeId, "delivered", DELIVERED_MS);
  const outcome = !delivered ? "no_delivered_status"
    : sentMs > SENT_WARN_MS ? "slow" : "ok";
  return report(region, outcome, {
    sentMs,
    deliveredMs: delivered ? delivered.at - started : null,
  });
}

The probe enters through your own send service, so it tests the same path customers depend on. Thresholds here are illustrative.

Common mistakes with synthetic monitoring

  • Probing only the health endpoint

    A green /health says the process is up, not that a message can reach a phone. Make at least one probe exercise the full send-and-status journey.

  • A test handset that sleeps

    Phones on battery saver, without data or logged out stop returning delivered, which produces false alarms. Keep the device plugged in on stable Wi-Fi, and alert on sent separately from delivered.

  • Probe traffic polluting metrics

    Probe sends inflate volumes and skew delivery rates and campaign analytics. Tag them and exclude them from business reporting.

  • Forgetting that probes are real messages

    Every probe is a billed delivery and counts like any other message from the number. Choose a modest interval and a template the test recipient genuinely expects.

  • Paging on one failed run

    Single failures happen for harmless reasons. Require consecutive failures, or failures from two locations, before paging — or on-call will learn to ignore the probe.

Best practices for synthetic monitoring

  • Run a second, cheaper probe that posts a correctly signed test payload to your webhook endpoint, to separate ingress failures from send failures.
  • Store every probe result: a month of latency history is the best baseline you will have.
  • Show the latest probe result on the support dashboard as the first answer to 'is WhatsApp down?'.
  • Re-run the probe automatically after every deploy and every token rotation.

Synthetic Monitoring FAQs

What is the difference between synthetic monitoring and a health check?+
A health check asks one instance whether it is alive; synthetic monitoring runs a whole user journey from outside. A service can pass every health check while messages fail because of an expired token or a missing webhook subscription.
Does synthetic monitoring cost money on WhatsApp?+
Yes. Probe messages are real deliveries billed at their category rate — a utility template probe in India is billed at ₹0.19 per delivery. A five-minute interval means 8,640 probes in a 30-day month.
How often should synthetic checks run?+
Every one to five minutes is typical. Shorter intervals detect outages sooner but send more billed messages; longer ones save money but delay the first alert.
What is synthetic monitoring vs real user monitoring?+
Synthetic monitoring uses scripted robot traffic on a schedule; real user monitoring measures actual customers' traffic. Synthetics work with zero traffic and give a steady baseline, while real-user data shows what customers truly experienced.

See InfiQ pricing

* Per-message rates for India, ex-GST: marketing, utility and authentication effective 1 July 2026; service messages ₹0.145 since 1 October 2026 (they were ₹0 until 30 September 2026). Volume commitments earn discounts — final rate is confirmed on your account; applicable GST extra. Rates for other countries differ (see the international rate table on /pricing).

Try it on the official WhatsApp Business API

InfiQ is an official Meta Business Partner. Start a 7-day free trial — no card needed — and see this running on your own number.

Start free trialBrowse all 550 terms