Is your client's GHL texting actually working?

Five checks, about ten minutes per sub-account

A workflow can run perfectly and still reach nobody. GoHighLevel accepts a text, hands back a message ID and shows it in the conversation, and only finds out a minute or so later whether the carrier delivered it. If it didn't, nothing alerts you. These are the checks we use while building on GHL, in the order we'd run them.

1Compare Sent with Delivered

GHL's weekly account summary email splits each sub-account's texts into Sent, Delivered and Failed. Delivered should be close to Sent. If Sent keeps climbing while Delivered sits near zero, the texts aren't arriving, however healthy the workflows look.

2Look for the red "Try again"

Open Conversations and scroll a few recent automated texts. A text that GHL accepted but couldn't deliver shows a red "Try again" under it. One or two is normal, from landlines and wrong numbers. A run of them on one sub-account is a setup problem.

3Check the texting registration

Business texting in the US needs an approved A2P 10DLC registration (or toll-free verification) for the number. An agency owner in one of the GHL groups described a client whose texts showed "sent" for three weeks while the carrier blocked every one, because the registration hadn't been approved. Nobody noticed until the client said GHL "didn't work." Confirm the status for every number a workflow texts from, not just the main one.

4Make sure the calendar's hours are in the right time zone

If a booking widget or an automation is offering slots at 1 or 2 AM, check the working-hours time zone under Settings > Calendars > My availability. On a Pacific sub-account with the calendar's hours set to UTC, 8 to 5 turned into 1 AM to 10 AM for anyone booking, and nothing in GHL flags it.

5If you build on the API: check delivery, and watch for times with no zone

• The send call returning a message ID only means GHL accepted the text. Read GET /conversations/messages/{id} a minute or more later for the real status and the error. One we hit on a test account: Trial mode not enabled for this agency.
• GET /contacts/{id}/appointments returns startTime and dateAdded with no time zone, in the sub-account's local time (not the calendar's, not UTC). The same appointment from /calendars/events/appointments/{id} includes the offset. Compare the zone-less one to "now" and it either throws or comes out hours off.