Most automations do not break loudly. They break at 02:40 on a Saturday, the webhook returns HTTP 200, the log says delivered, and nothing lands in the CRM. The clearest case we have is our own: two sync bugs sat between payment confirmation and the CRM stage, unnoticed for weeks, because every layer that could have raised a flag reported success instead. By the time reconciliation caught it, roughly AED 15,000 in paid studio bookings were sitting in the CRM marked unpaid, dashboard fully green the whole time. Once found, the fix was small. Finding it was the hard part, and that gap between the break and the discovery is what costs money. Monthly monitoring exists to shrink that gap from weeks to hours.
I run the stack we sell. Our studio enquiries are handled by a WhatsApp agent that qualifies, quotes, books the slot, sends the payment link and writes the deal into the CRM. Everything below comes from running that thing in production, breaking it, and watching it break in client accounts across Dubai.
Silent failure: what it is and why it hides
A silent failure is an automation run that reports success while producing no result. The receiving endpoint answers HTTP 200, the delivery log shows a green tick, and the record that should exist in the CRM does not. Nothing raises an error because, from the sending system's point of view, nothing went wrong.
The mechanics are simpler than they sound. A webhook is a fire-and-forget delivery. Meta's platform sends the event, waits for a 2xx acknowledgement, and treats a 200 as proof of delivery. If your endpoint acknowledges first and processes afterwards, which is the standard and correct pattern for staying inside the acknowledgement window, then everything after the 200 happens out of Meta's sight. A queue worker crashes, a validation rule rejects the payload, a mapping fails on a null value, and the sender never learns about any of it.
Meta's documented behaviour on the other side of that boundary is worth knowing: if your endpoint returns something other than a 2xx, or times out, delivery is retried with decreasing frequency for up to seven days before the event is dropped. That retry window is generous and it is also a trap. Teams see "no failed deliveries" in the Meta dashboard and conclude the integration is healthy, when the dashboard is only reporting on the first three inches of a much longer chain.
Loud failures get fixed the same day because somebody sees red. Silent failures get fixed when a customer asks why nobody replied, or when a monthly reconciliation turns one up. Without reconciliation, they get fixed never.
What actually breaks, in the order I see it
The OAuth refresh token that quietly stopped refreshing
This is the most common cause of "the bot just went quiet" that I get called about. Access tokens are short-lived by design. Zoho issues access tokens valid for one hour, and the integration silently swaps in a new one every hour using a long-lived refresh token. The refresh token itself is where the trapdoors are.
Zoho allows a maximum of 20 active refresh tokens per user per client. Create the twenty-first and the oldest stops working. If three people in your office have "reconnected the integration" over eighteen months because something looked stuck, you have burned through that budget without knowing it, and one day the token your production automation depends on is the one that gets rotated out.
Google is stricter in a different way. While an OAuth app's publishing status is still Testing rather than In Production, Google revokes refresh tokens after seven days. Plenty of Dubai agencies wire a client's Google Ads or Sheets integration, never move the consent screen to production, and hand over something with a seven-day fuse in it. Google also expires refresh tokens that go unused for six months, which kills the automations that only run quarterly.
The failure mode is identical across vendors: the automation does not crash, it just gets a 401, retries, gets another 401, and stops. If nobody watches for the absence of activity, the silence looks like a quiet week.
An API version was deprecated or a field got renamed
Vendors ship breaking changes on a schedule and post them in a changelog nobody in your company reads. A CRM field renamed from Lead_Source to Source_Channel does not break the API call. It breaks the mapping, and the deal is created with an empty source, so your attribution report shows a growing bucket of unattributed revenue while every individual system reports success.
The version number in the endpoint URL is the other one. Meta's Graph API versions age out, and a call to a retired version fails cleanly. That at least is a loud failure. The quiet variant is a version that still works but changes a field's shape, for example a value that used to arrive as a string arriving as an object, and your parser writes the string "[object Object]" into a phone field for three weeks.
Rate limits and 429s that turn into a swelling queue
WhatsApp Cloud API allows a default throughput of around 80 messages per second per sender, with 1,000 per second available to eligible upgraded accounts. Exceed it and you get error 130429. Separately, your business portfolio carries a messaging limit that caps how many unique customers you can start conversations with in a rolling 24 hours, starting at 250 for a fresh number.
An automation without backoff handles this badly. It retries immediately, gets throttled harder, and the outbound queue grows faster than it drains. Exponential backoff means each retry waits longer than the last, roughly 1s, 2s, 4s, 8s, with random jitter added so that a hundred queued messages do not all retry at the same instant. Cap the attempts at three to six for transient errors and park the rest in a dead-letter queue that a human can see. A queue nobody can see the depth of stops being a queue and turns into a hiding place.
Duplicates, because retries happened without idempotency
An idempotency key is a unique identifier attached to a request so that the receiving system recognises a repeat of the same operation and processes it once. Payment gateways use them. CRMs mostly do not enforce them for you.
Here is how it goes wrong. Your endpoint takes 31 seconds to process a payment webhook. The gateway gave up waiting and retried. Now two payment records exist for one transaction, two invoices get generated, and the customer receives two confirmation messages. Or the milder version: a lead form submits twice because someone double-tapped on a slow 4G connection in a lift in Business Bay, and your CRM gets two deals for one person. Deduplication after the fact is a repair job, covered in our notes on CRM data hygiene and dedupe rules. Idempotency at the point of write is the prevention.
Time zones, and the Dubai-specific catch in them
Dubai runs at UTC+4 with no daylight saving. Most cloud infrastructure stores timestamps in UTC. Half the SaaS tools in your chain observe DST somewhere in their configuration because their defaults were written for Europe or North America.
The result is a reminder scheduled for 09:00 that goes out at 13:00, or a "next day follow-up" that fires at 20:00 the same evening because the date rolled over in UTC and not locally. Twice a year, when Europe and the US shift, an integration that was one hour off becomes two, or an integration that was correct starts drifting. Nobody logs an error. The messages send perfectly, at the wrong time, to real customers.
The rule I hold to: store everything in UTC, convert at the display and send layer only, and pin the automation platform's account time zone to Asia/Dubai explicitly rather than leaving it on the default.
The business changed and the automation did not
Your price went up in March. The bot still quotes February. You stopped opening on public holidays. The booking flow still offers those slots. A staff member added a new dropdown value in the CRM and no rule knows what to do with it.
This damages trust faster than any technical fault on this list, because the automation answers with total confidence. A customer who gets a wrong price in writing from your official WhatsApp number now has a wrong price in writing from your official WhatsApp number. Every price, schedule, service list and policy the automation can speak about needs an owner and a review date, and the review has to be a scheduled task rather than something that happens when someone remembers.
WhatsApp Business API: templates, the 24-hour window and number changes
WhatsApp deserves its own section because it is the layer most Dubai service businesses depend on, and it fails by policy rather than by bug.
Template pausing is the one that surprises owners. A template that Meta approved months ago can still be pulled. Quality rating reflects how recipients reacted over roughly the last day, driven by blocks, reports and low read rates. As documented by Meta and its solution providers, a template that drops to Low quality gets paused automatically: three hours the first time, six hours the second, and permanent disabling on the third. Recovery works the other way, with the template returning to approved status after about seven consecutive days back at Medium or High. If your appointment reminder is a single template and it gets paused on a Thursday, your reminders simply do not go out, and your automation platform will report those sends as errors that nobody is reading.
The 24-hour customer service window is a rule, not a bug, and it breaks automations built by people who tested only with fresh conversations. Free-form messages are allowed within 24 hours of the customer's last message. Outside it, only approved templates. A follow-up sequence designed to nudge a quiet lead on day three will fail entirely if step three is free-form. In testing it worked, because the tester was replying.
Number changes and migrations force re-authorisation. Moving a number between providers, changing your display name, or re-registering a number all require verification steps, and the tokens and phone number IDs your automation holds are tied to that registration. Every integration referencing the old phone number ID has to be updated. This is a planned outage if you treat it as one and an unplanned one if you do not. The mechanics of setting the connection up in the first place are in our guide to connecting WhatsApp to your CRM.
What monthly monitoring should actually cover
"Monitoring" in most support contracts means somebody looks at a dashboard when you complain. Here is the checklist I would hold a vendor to, and what a pass looks like on each line.
- Heartbeat with an alert on silence. A heartbeat check alerts when an automation has not run, rather than when it has failed. Set a threshold per flow: if the WhatsApp agent has logged zero inbound conversations in four hours during business hours, that is an alert, not a quiet day. Absence of activity is the only signal that catches expired tokens.
- Error log review with classification. Someone reads the run history and sorts errors into transient, structural and data. Transient errors that recur on a pattern are structural in disguise. The output is a short list of what changed since last month, not a screenshot of a green tile.
- Counter reconciliation between source and CRM. Count conversations at the source, count records at the destination, and compare. Ads clicks to WhatsApp conversations to CRM deals to payments. Any gap above a few percent gets investigated by name. This single check catches almost every silent failure, and it is the one most vendors skip because it takes real time.
- Message delivery and template health report. Sent, delivered, read, failed, by template. Current quality rating on each template and on the number. Where you sit against your messaging limit tier. A template drifting toward Medium quality is a month of warning before it gets paused.
- Deduplication audit. How many contacts and deals were created that look like duplicates of an existing record, and which flow created them. A rising duplicate count usually means retries without idempotency somewhere upstream.
- Config and credential backup. An export of the automation logic, the field mappings, and a record of every credential the system holds, stored where you can reach it without the vendor. If your integrator disappears tomorrow, this is the difference between a bad week and a rebuild.
- Token expiry tracked ahead of time. A dated list of every token, key and certificate in the chain with its renewal date, checked well before it lapses rather than on the day. Include the OAuth app publishing status, because a consent screen sitting in Testing is a seven-day fuse.
- End-to-end test of the critical path. Once a month, a human sends a real message from a real phone and follows it all the way through to the CRM record, the calendar entry and the payment link. Not a simulated payload. The real thing, on the live number. Ten minutes, and it catches what logs cannot.
Our own single-process automations ship with this loop attached rather than as an upsell, and what sits inside the monthly figure is written out on the AI automation page. The cost side of the build and the monthly is broken down separately in what one automated process costs.
Who fixes it, and how fast: what to put in the SLA
Support agreements in this market are mostly one paragraph of goodwill. Four things are worth pinning down before you sign anything, and none of them require the vendor to promise the impossible.
Define severity in business terms, not technical ones. Severity one is anything where customer messages are not being answered or money is not being recorded. Severity two is a flow producing wrong output that a human can work around. Severity three is cosmetic or a change request. Agree the definitions in writing, because "urgent" means different things at 09:00 Sunday and 23:00 Thursday.
Agree a response time and a workaround time separately, and understand what each covers. Response time is when a named human acknowledges and starts. Workaround time is when the bleeding stops, which often means routing conversations to a phone instead of the agent. Permanent fix can take longer, and a vendor who promises a fix time for a fault inside a third-party API is promising something they do not control. Ask instead what happens in the meantime.
Name the escalation path with a person on it. Which channel, which name, and who is reachable when that person is not. An escalation path that terminates in a shared inbox is not a path.
Settle credential ownership before there is a problem. Accounts in your name, your billing, your admin access, vendor added as a user. If a fix requires re-authorising an integration and only the vendor can do it, your recovery time is their availability. This one clause has saved more client weekends than any monitoring tool.
The first thirty minutes of an outage
When something stops, the order of checks matters more than the depth. Work outward from the cheapest thing to verify.
Start with authentication. Open the integration's connection settings and look at the token status and the last successful sync timestamp. Expired credentials account for the largest share of sudden stops, and this takes two minutes.
Then check whether the source is still sending. Look at the platform's own delivery or webhook log. If events are arriving and your side shows nothing, the fault is in your endpoint or your queue. If nothing is arriving, the fault is upstream, in the token, the subscription, or a policy action against the number.
Then look for a change. Ask what changed in the last 72 hours across all of it: a field renamed, a user removed, a plan downgraded, a password rotated, a template edited, a new dropdown value added by someone in sales. In my experience the answer is almost always yes, and almost always something nobody thought was connected.
Then check the queue depth and the dead-letter queue before you restart anything. Restarting a service with a full retry queue can flush hundreds of stale messages to real customers, which is a much worse day than the outage.
Last, before you declare it fixed, run the end-to-end test from a real phone. A restored connection is not a restored process.
If you would rather find these before they find you, a growth audit maps the whole chain and lists the specific points where it can fail quietly. If the flow in question is first reply and qualification on WhatsApp, that one is productised as a WhatsApp AI sales agent with the monitoring already attached.
Written by Artur Gall, founder of slgo.ai. We connect the CRM, chat, ads and payment tools you already run. We do not sell those tools, and we do not resell licences.
