The mechanic: WHMCS does not automatically retry failed module actions. When the upstream cPanel, Plesk, or SolusVM module returns an error during account creation, WHMCS quietly drops the failure into its Module Queue and waits for you to notice. The customer paid the invoice. The order shows Active. The portal login works. The hosting account does not exist. A browser login monitor on clientarea.php (the WHMCS portal monitor we covered previously ) will not catch this by design. What does catch it: a single API monitor that hits GetModuleQueue and asserts the queue is empty, plus an optional 3-step API chain that simulates the full order, accept-order, and provisioning verification path. Both recipes fit the Velprove free plan.
WHMCS does not retry failed provisioning. Your customer finds out before you do.
If you have already set up the browser login monitor on your WHMCS client portal , this post covers what that monitor cannot see by design. The browser login monitor confirms clientarea.php renders and accepts credentials. It tells you nothing about whether a customer who just placed an order has a working hosting account waiting for them.
That gap is where WHMCS silent failures live. The order chain (AddOrder, then AcceptOrder, then the underlying provisioning module call against your cPanel, Plesk, or SolusVM box) runs after the login succeeds. When the upstream module fails, WHMCS does not retry. It drops the failure into the Module Queue and waits for you to look at the admin dashboard. The customer finds out before you do, usually by email, usually after they have already tried to use the service that does not exist.
The WHMCS docs are explicit about this. From the official Module Queue troubleshooting page: “WHMCS will not automatically retry a failed action. You must click Retry to attempt the failed action again.” The retry is a manual button click inside the admin UI. If no human opens that admin UI, the failed order sits in the queue. That is the silent-outage shape this post is about. The broader taxonomy of failures that look green on the dashboard lives in the silent-outage taxonomy .
The Module Queue is the silent-failure inspection point.
The Module Queue is a WHMCS internal log of every automated module action that failed. From the docs: “The Module Queue list displays your WHMCS installation's failed automated actions. This includes any action that WHMCS performs using a module, either as part of the system cron tasks or in direct response to a user or admin action.” You can access it at Utilities > Module Queue in the WHMCS admin area. The list shows the client name, the associated service or domain, the action that failed, the error details, and the time of the attempt. Two buttons sit next to each entry: Retry and Mark Resolved.
WHMCS surfaces the queue count on the admin dashboard as a blue Pending Module Actions badge. From the WHMCS feature spotlight: “These represent times that a WHMCS installation attempted to perform an action with an external system (via a module) but did not receive a successful response back.” The badge is helpful if you are already inside the admin area. It is not a monitor. It does not page you at 2 AM. It does not Slack your operations channel. It requires a human to open the dashboard and look at the badge.
The corresponding API endpoint is GetModuleQueue . It returns a JSON response with a result field, a count field, and a queue array containing one object per failed action. Each queue entry carries the serviceId, moduleName, moduleAction, lastAttempt timestamp, and the verbatim lastAttemptError message from the upstream provisioning module. That last field is the signal you actually want when you triage a red alert.
The one-monitor recipe: a single GetModuleQueue API monitor (free plan ready).
The load-bearing recipe is one API monitor against GetModuleQueue. It catches every queued failure regardless of which provisioning module produced it. It runs on the Velprove free plan. It takes about three minutes to configure.
Set up a Velprove monitor of type API (not multi-step, so your multi-step quota stays free for the optional 3-step chain in the next section). HTTP method POST. URL https://your.whmcs.example.com/includes/api.php. Set the request header Content-Type to application/x-www-form-urlencoded. The form-encoded body:
Add a single json_path assertion: path $.count, operator equals, expected value 0. That is the entire recipe. When the queue is empty, the monitor stays green. When any module action fails (anywhere in your WHMCS install, across any provisioning module), the count goes above zero and the monitor flips red.
On the Velprove free plan, set the interval to 5 minutes. On Starter ($19/month), set it to 1 minute. On Pro ($49/month), the floor drops to 30 seconds. The Velprove free plan also covers all six assertion types, so you have everything you need to express this monitor without upgrading.
When the monitor flips red, the alert tells you the queue is no longer empty. To triage, hit GetModuleQueue manually (curl, Postman, your browser) and read the queue array. Each entry tells you which client, which service, which module, which action, and the exact error message the module returned. From there you have everything you need to walk the remediation flow that WHMCS documents at the Resolving a Failed Hosting Account Creation page. The 1-step recipe is the right starting point for any WHMCS-using operator. Most teams ship this one and never need the 3-step chain.
The three-step chain: trigger a test order and assert the queue stays clean.
The more advanced recipe creates a real test order on every monitor run and then checks the queue. It catches a different class of failure: cases where the upstream module appears healthy to GetModuleQueue (because nothing real has been ordered recently) but actually fails when an order arrives. It is most useful when your order volume is low enough that the 1-step recipe could go days without exercising the provisioning path.
The chain uses three API calls. The load-bearing detail is in the WHMCS AddOrder API documentation, which is explicit: “For more flow control, this method ignores the ‘Automatically setup the product as soon as an order is placed.’ option. When you call this method, you must make a subsequent explicit call to AcceptOrder.” So AddOrder alone does not provision. You need AcceptOrder afterward to trigger the provisioning module.
The chain (Velprove monitor type: multi-step). Every step uses the header Content-Type: application/x-www-form-urlencoded and a form-encoded body:
Step 1: AddOrder. POST to /includes/api.php (no real gateway fires because paymentmethod=mailin). Body:
Assert json_path path $.result, operator equals, expected success. In the step's extract config, capture $.orderid from the response into a variable named order_id.
Step 2: AcceptOrder. POST to /includes/api.php. Body:
Assert json_path path $.result, operator equals, expected success. This call triggers the provisioning module against your cPanel, Plesk, or SolusVM box.
Step 3: GetModuleQueue. POST to /includes/api.php. Body:
Assert json_path path $.count, operator equals, expected 0. If your test order's provisioning failed, the failure entry is sitting at the top of the queue and the assertion trips.
The {{order_id}} template syntax in Step 2 is Velprove's flat variable interpolation: any name you used in a previous step's extract config can be referenced inside double braces in subsequent steps. Names are word-character only (no dots, no dashes). For the underlying variable-extraction semantics, see the multi-step API monitoring guide .
The chain fits Velprove's free plan exactly: 3 steps is the free cap. Starter raises it to 5, Pro to 10.
One auto-setup footnote. The WHMCS Order Statuses documentation notes: “If you have configured provisioning to occur while orders are in the Pending status, they will occur without you having accepted the order.” If your install runs in that mode, step 2 (AcceptOrder) is optional and a 2-step chain (AddOrder, then GetModuleQueue) is sufficient. Most resellers run in the safer default of provisioning on Accept, so the 3-step chain is the right shape for most readers.
A cleanup note: every monitor run leaves a test order in tblorders. Add a nightly cron that calls the WHMCS DeleteOrder API to garbage-collect every velprove-canary tagged order from the previous day. Without cleanup, your orders table fills up with thousands of synthetic test records inside a year.
Which recipe do you actually need?
The 1-step recipe (a single GetModuleQueue monitor) catches every queued failure that already happened in your install, across every module, regardless of who triggered it. It is cheap, read-only, and the recommended baseline for everyone including Free-plan readers. Most operators ship this and stop here.
The 3-step chain catches a different class of failure: the case where AddOrder itself errors out (validation rejection, invalid payment method, malformed custom field), the case where AcceptOrder succeeds but the underlying module never gets called, and the case where the module call fails on a code path that the 1-step recipe would not have caught between organic orders. The two recipes are additive, not alternatives. Most teams add the chain only after the 1-step monitor has caught its first incident and they want active provisioning verification on top of the passive queue check.
For the broader framework on which third-party-like systems (WHMCS-as-a-dependency is one) justify a synthetic monitor at all, see the 3-of-12 rule for which dependencies to monitor synthetically . WHMCS scores high on every axis (blast radius across all customers, revenue attribution on the order path, no useful vendor status page because the vendor is you), so it lands in the must-monitor bucket for any WHMCS-running operator.
The least-privilege service account.
Do not point these monitors at your existing admin API credentials. Create a dedicated WHMCS admin role for the monitor service account. The role needs four API permissions and nothing else: GetModuleQueue, AddOrder, AcceptOrder, and GetClientsProducts (the last one if you want to extend the chain later to verify the service row landed correctly). Disable every other API capability on the role, including any read access to client billing data or server credentials.
Create a dedicated API credential pair under that role and use it only for Velprove monitors. Rotate the credential quarterly with the same calendar reminder you use to rotate your other service credentials. If WHMCS supports IP allowlisting on the role (depends on your WHMCS version and any third-party security modules you have installed), restrict the credential to Velprove's monitor egress range so a leaked secret cannot be replayed from elsewhere.
For the test client used by the 3-step chain: create a normal client account, tag it with a unique identifier like velprove-canary, and use it as the sentinel clientid for every AddOrder call. The tag makes the DeleteOrder cleanup cron trivial to write and keeps your production client tables clean. The hosting-stack adjacency story (what to monitor on the underlying cPanel/WHM box itself) lives in how to monitor the cPanel/WHM box itself .
Alerting and incident response when the monitor flips red.
Velprove's alert channels today: email on every plan, including Free. Slack, Discord, Microsoft Teams, and webhook on Starter ($19/month) and above. PagerDuty on Pro ($49/month). Route WHMCS monitor alerts to whichever channel your on-call human actually watches at 2 AM. For most resellers, that is PagerDuty for the on-call rotation plus a Slack mirror for shared visibility.
Pick a home region from Velprove's 5 (North America, Europe, UK, Asia, Oceania) closest to your WHMCS install for the tightest baseline latency. All 5 regions are available on every plan, including Free. Each monitor runs from one region you pick, not fanned out across all five.
When GetModuleQueue reports count > 0, your runbook is the WHMCS-documented remediation flow:
Open the WHMCS admin area, navigate to Utilities > Module Queue. Read the error code on each pending action. The error field carries the verbatim message from the upstream module. Click the client name or service name on each entry to jump into the affected client's profile and the Products/Services tab. Fix the underlying cause (username collision, server quota exceeded, API token expired, IP allowlist mismatch). Click Retry inside the Module Queue UI to re-attempt the failed action. The page displays the new attempt result immediately.
The InMotion Hosting troubleshooting guide catalogues the common error shapes you will see in the queue: “Module Create Failed - Service ID: 4 - Error: Access denied” (cPanel rejected the credential), “Server Command Error - Curl Error - Couldn't connect to host (7)” (network partition or port 2087 blocked), “406 Not Acceptable” (ModSecurity rule fired), and “Allowed memory size of xxxxx bytes exhausted” (PHP memory_limit too low on the WHMCS host). Each has a known fix. The Velprove monitor surfaces the failure; the remediation stays in your hands. Velprove monitors are read-only observers and do not drive WHMCS workflow actions.
Why WHMCS is a high-value surface to monitor in the first place.
The Lagom Client Theme cascade through 2024 (HostUS in February, Hosturly mid-year, DigiRDP later in the year) taught the hosting industry that WHMCS panels sit at the center of billing, identity, and provisioning, and that vulnerabilities in any one popular theme or add-on can cascade across the entire customer base. RSStudio shipped Lagom 2.2.7 in September 2024 with the security fix. WHMCS itself shipped a security update on June 3, 2025 covering v8.13, v8.12, and v8.11 LTS . Disclosure language was vague. The cadence is the point: the flows running through your WHMCS install warrant external monitoring you control, not just admin-dashboard widgets you have to remember to check.
Patterns to avoid (honest about Velprove's primitive set).
Five patterns WHMCS-community guides commonly recommend for provisioning monitoring do not fit Velprove's primitive set. Naming them is faster than pretending they are options.
No polling primitive. Velprove's multi-step API monitor runs each step exactly once in sequence and records the result. “Wait 60 seconds after AddOrder, then keep hitting GetOrders until status flips to Active” is not expressible. The replacement is the monitor interval. If you need 30-second detection, set the interval to 30 seconds on the Pro plan.
No time-relative freshness assertion. The six assertions are status_code, body_contains, body_not_contains, json_path, response_time_ms, and header_contains. “Assert this order was created within the last 5 minutes” is not a primitive. The replacement is your endpoint computing freshness server-side and returning 200 or 503, or a json_path assertion against a static expected value like $.count = 0.
No multi-page browser navigation through the WHMCS order wizard. The browser login monitor drives one form submit (the login page). It does not click through the order placement wizard, add items to the cart, fill the billing form, and complete checkout. Order creation in this post lives in the API path (AddOrder), not the browser path. The browser monitor pattern stays where it shines: client-area login coverage on clientarea.php.
No retry-from-monitor. Velprove monitors are read-only. The Retry button inside the Module Queue UI is the operator action that re-attempts the failed module call. The monitor surfaces the failure; the operator runs the retry. Trying to make the monitor call AcceptOrder or the WHMCS RetryQueueItem API to self-heal a failed provision is an antipattern: it papers over the underlying cause (quota exceeded, credentials wrong, server full) and starts accumulating real provisioning errors at scale.
No mobile push channel. Velprove's alert channels today are email, Slack, Discord, webhook, Microsoft Teams, and PagerDuty. There is no mobile push alert on any plan. Plan your alert routing around what exists.
Frequently Asked Questions
What is the difference between monitoring my WHMCS portal login and monitoring the order and provisioning flow?
A browser login monitor on your WHMCS client portal confirms that clientarea.php renders and accepts customer credentials. It tells you the auth layer is up and the database row exists. It tells you nothing about whether the order, invoice, and provisioning chain that runs after login succeeds actually completes. The order-flow monitor in this post covers the AddOrder, AcceptOrder, and provisioning module call chain that produces a working hosting account. The two monitors catch different failure modes and are additive, not alternatives. Most operators run both: one browser login monitor for portal availability, one GetModuleQueue API monitor for silent provisioning failures.
How do I monitor WHMCS provisioning failures without triggering real charges?
Create a dedicated test client in WHMCS with a unique tag like velprove-canary so your cleanup scripts can identify it. Set up a sentinel product SKU configured with paymentmethod=mailin (bank transfer), which sits in pending without firing a real payment gateway. Run the 3-step chain (AddOrder, AcceptOrder, GetModuleQueue) against this test client and sentinel product. Schedule a nightly cron with the DeleteOrder API to garbage-collect velprove-canary tagged orders so they do not accumulate in tblorders. No customer-facing charges are ever generated, and your WHMCS database stays clean.
What does the WHMCS Module Queue actually catch that a portal login monitor misses?
Module-by-module provisioning failures that happen after the customer paid and logged in. cPanel CreateAccount failing on quota exceeded. Plesk CreateAccount failing on a subscription template mismatch. SolusVM Create failing on stockout. Domain registrar module timeouts. ResellerClub authentication failures after API key rotation. WHMCS appends every one of these to the Module Queue with the verbatim error from the upstream module (Access denied, Couldn't connect to host (7), 406 Not Acceptable from ModSecurity, Allowed memory size exhausted). All of them are silent from the portal-login perspective: the tblclients row exists, clientarea.php works, the customer logs in to find an account that does not exist.
How often should I run the GetModuleQueue monitor?
5-minute intervals on Velprove Free, 1-minute on Starter, 30-second on Pro. GetModuleQueue is a cheap, read-only API call against your WHMCS install, so the frequency tradeoff is detection lag versus WHMCS server load, and WHMCS server load is not a real constraint at this endpoint. If your order volume is high enough that a 5-minute detection lag means several failed provisions before you find out, move to Starter at $19 per month for 1-minute intervals. If your order volume is low (under 50 new orders per day), 5-minute Free-plan intervals are fine.
Can I do this on the Velprove free plan with the 3-step multi-step monitor limit?
Yes. The 3-step order chain (AddOrder, AcceptOrder, GetModuleQueue) fits the Free plan's 3-step multi-step monitor cap exactly. The simpler 1-step recipe (a single GetModuleQueue API monitor) also fits Free and is the recommended starting point for most operators. For the underlying multi-step primitive, see the multi-step API monitoring guide . Free includes 10 monitors total at 5-minute intervals, all six assertion types, and email alerts.
How do I monitor a WHMCS provisioning module if my install does not expose the API externally?
If your WHMCS API is internal-only, the order-chain recipe in this post will not work as written. The cleanest fallback is to open the API to Velprove's published monitor egress IPs (see velprove.com/ips for the live list and JSON feed), with a dedicated low-privilege API service account that only has GetModuleQueue, AddOrder, AcceptOrder, GetClientsProducts permissions. If even that is off the table, fall back to a Velprove browser login monitor on the WHMCS client portal (free plan, one browser login monitor included at a 15-minute interval). The browser monitor catches login-layer failures but cannot catch the silent provisioning failures this post is about.
