WhatsApp error 131016 (service temporarily unavailable): check Meta's status, then retry without duplicates

WhatsApp error 131016 is the Cloud API saying "not now". Meta's error codes page describes it as "A service is temporarily unavailable" and gives one instruction: "Check the WhatsApp Business Platform Status page to see API status information before trying again." It is not about your template, your recipient or your account. Some part of Meta's infrastructure that your request needed was down or overloaded at that moment, and the right response is to wait, confirm, and resend carefully.

What 131016 tells you, and what it does not

The closest relatives are error 131000 ("Something went wrong", an unknown error with no clear owner) and error 2 ("Temporary due to downtime or due to being overloaded"). 131016 is the more specific of the three: Meta is telling you the fault is a service on its side.

Step 1: confirm it is an incident

1. Open the WhatsApp Business Platform Status page (linked from Meta's error codes page and listed in the sources below). It shows current incidents and degraded components for the Cloud API.
2. Count the failures. One 131016 in a day of normal traffic is background noise. Dozens across different recipients and templates in a few minutes is an incident.
3. Send one test message from the same number to a team member's phone. If it fails with 131016 too, stop the queue. If it succeeds, the incident may already be over.
4. Write down the fbtrace_id from a couple of failures. If you need to raise a ticket with Meta later, the trace IDs are what support asks for.

Step 2: hold the queue, then retry with back-off

Hammering the API during an incident does not make it recover faster, and it fills your logs with thousands of identical failures. Instead:

• Pause bulk sends (campaigns, imports, scheduled reminders) the moment the failure rate climbs.
• Keep conversational replies flowing where you can. A customer waiting in a chat is worth a retry every 30 to 60 seconds; a marketing broadcast can wait an hour.
• Retry with exponential back-off and jitter: 30 seconds, 1 minute, 2 minutes, 5 minutes, then hand the message to a slower queue. Random jitter stops every worker retrying in the same second.
• Set a cut-off for time-bound messages. An OTP that is 15 minutes late is useless; generate a new code instead of resending the old one.

Step 3: avoid sending the same message twice

This is the part most integrations get wrong. During an outage, a request can reach Meta, be accepted, and still come back to you as an error or a timeout. The Cloud API has no idempotency key on /messages, so if you blindly resend, the customer may get the same order update twice.

Before resending a message that failed with 131016:

1. Check whether you got a message ID (wamid) in the response. If you did, the message was accepted; do not resend it.
2. Check your status webhooks for that recipient and template in the last few minutes. A sent or delivered status means it went through.
3. Resend only when neither exists. Record the retry against the original job so a second worker does not pick it up as well.

What the error looks like

Values, title and trace ID illustrative:

{
  "error": {
    "message": "(#131016) Service unavailable",
    "type": "OAuthException",
    "code": 131016,
    "error_data": {
      "messaging_product": "whatsapp",
      "details": "A service is temporarily unavailable."
    },
    "fbtrace_id": "AzQ81mVtRk2pWn7cYbL3xHe"
  }
}

131016 can also arrive later, in a status webhook with status: failed and the code inside the errors array. The handling is the same: confirm, wait, check for a duplicate, resend.

A worked example

Sunrise Clinic in Pune sends appointment reminders every evening at 7 pm through its own script. One evening, 140 of 420 reminders fail with 131016 within three minutes (illustrative numbers). Priya, who looks after the integration, opens the status page and sees a Cloud API incident marked as being investigated. She pauses the script.

Forty minutes later the incident is marked resolved and her test message arrives. Before restarting, she filters the 140 failures against the day's status webhooks: 6 of them have a delivered status, so the request had gone through despite the error. She resends the remaining 134. No patient gets two reminders, and none misses one.

Preventing pain from the next outage

• Separate urgent from bulk. Give replies and OTPs their own queue with short retries, and let campaigns back off for longer.
• Alert on the rate, not the single error. For example, alert when more than 5% of sends in five minutes fail with 131016, 131000 or 2.
• Store message IDs and statuses so you can always tell sent from unsent.
• Send big campaigns in batches rather than all at once, so an outage hits one batch, not the whole list.
• Do not edit templates or rotate tokens in a panic. None of those cause 131016, and changing them during an incident adds new problems.

How Broadchat handles 131016

In the Broadchat panel, a campaign message that fails with 131016 is marked Failed for that recipient with Meta's message as the reason; Broadchat does not resend it automatically, which avoids double messages when a request half-succeeded. After the incident, open the campaign, filter by Failed and use Retarget to build a new campaign for those recipients. A template that fails at Meta is not charged to the channel wallet: the reserved amount is refunded. If you call a channel's Graph-compatible API from your own code, Broadchat returns Meta's response unchanged and your code owns the retry policy described above.

Other codes are covered in the WhatsApp API error codes cheat-sheet, and the basics of the platform in the plain-English guide to the WhatsApp Business API. Agencies that run sends for many clients can offer campaign reports and retargeting under their own brand through the white-label program.