Why your numbers and the provider numbers disagree
The first time somebody compares the message volume shown in their workspace against the figure in a Twilio or Meta dashboard, the two do not match, and the natural conclusion is that one of them is broken. Usually neither is. They are counting different events, at different moments, into different calendar boundaries.
The counting rule on our side is simple enough to state in a sentence, and every discrepancy you will run into follows from some part of it. One row exists per site, per channel, per month, holding an inbound count and an outbound count, and each row is incremented by one at the moment a message is successfully handled.
Everything interesting is in the phrase at the moment a message is successfully handled. That is not the moment the customer pressed send, and it is not guaranteed to happen at all.
The month is when the message landed, not when it was sent
The bucket a message falls into is the current year and month in UTC, taken at the moment the message is processed. It is not read from the message's own timestamp.
This is a deliberate choice and it has a visible consequence. Providers retry. A webhook that could not be delivered because your site was briefly unreachable may arrive hours or, in bad cases, days later. When it finally arrives it is counted in the month it landed, not the month it was written. A conversation that happened on the thirty-first is capable of appearing in the following month's total.
The boundary is also UTC, not your local time or your business calendar. If your team works in Los Angeles, the last several hours of every month, local time, are already counted in the next month. Neither of these matters at all for a rough monthly trend, and both matter quite a lot if you are trying to reconcile a specific figure to the message.
The rule to carry away: this is a count of messages your workspace processed in a period, which is a slightly different thing from messages your customers sent in that period.
What increments the inbound count
Inbound is incremented once per message arriving from a customer, and it happens after the message has been stored, not before.
Two paths do it. A message arriving over a connected messaging channel is stored as a customer comment on a ticket, opening a new ticket if the thread is not already attached to an open one, and then the counter is bumped for that channel. An email arriving into your support address is stored the same way and bumps the counter for the email channel specifically.
The ordering is worth noting because it tells you what a discrepancy means. The count is bumped last, deliberately, so that a metering problem can never cause a customer's message to be rejected. If the count is lower than the provider's, the messages still arrived and are still in your tickets. The reverse would be a real problem, and the ordering makes it impossible.
Note also that every inbound message counts, including the second and tenth message in an ongoing conversation. This is a message count, not a conversation count, so a chatty thread inflates it relative to how many customers you actually spoke to.
What increments the outbound count
Outbound is incremented when somebody on your side adds a public comment to a ticket that has a channel address attached, at the same moment the reply is dispatched to the provider.
Comments authored by the requester are excluded from this path. That exclusion is what stops the double count: the customer's inbound message is already stored as a requester-authored comment, and if that comment also triggered an outbound bump, every inbound message would be counted twice, once in each column.
The practical consequence is that your outbound count is a count of replies sent over the channel, and it will not track your inbound count. A single customer question answered thoroughly in one reply gives you one inbound and one outbound. A customer who sends six short messages before you answer once gives you six and one. If you want to know how hard your team is working, this is not the metric; if you want to know how much traffic a channel is generating, it is.
A count that never happens is by design
Every increment is wrapped so that a failure is swallowed rather than raised. If the counter table is not deployed, or the database has a transient hiccup, or the write times out, the increment returns a failure quietly and the message goes on being delivered.
This is the correct trade and it is worth understanding why. Channel webhooks are delivered by third parties who interpret an error response as a signal to retry. A counter update that threw an exception would fail the webhook, the provider would resend the same message, and you would get a duplicate ticket comment for the sake of a statistic. Losing a count is cheap. Losing or duplicating a customer's message is not.
So treat these figures as an adoption and volume signal rather than an accounting record. They are good for answering whether a channel is being used, whether usage is growing, and whether a launch changed anything. They are not the right source for a number you intend to invoice against or present as exact, and a small gap against a provider dashboard is expected rather than alarming.
One more edge worth knowing: a channel name longer than twenty characters is rejected outright rather than truncated, so a custom integration that invents a long channel identifier will record nothing at all. Keep channel names short and lowercase.
Reading a zero correctly
Asking for a month with no row returns zeros rather than nothing, so that a screen can render an empty state without special handling. That is convenient for the interface and slightly treacherous for you.
A zero means one of three things: no messages on that channel in that month, the channel schema is not deployed, or the counter has been failing silently for reasons above. The three look identical from the outside.
The way to tell them apart is to check whether the tickets exist. If your channel is producing tickets and comments but the count is zero, the tickets are the truth and the counter is not being written. If there are no tickets either, the channel genuinely is not in use, and the place to start is whether the connection was finished at all.
How MyLiveChat fits
These counts sit alongside the rest of your channel setup, and the sensible way to use them is comparative rather than absolute. Track the shape of the month over month curve per channel, and use it to decide where to put staffing, not to reconcile a bill.
If you are still wiring channels up, connecting WhatsApp, SMS and Messenger to your tickets covers what each provider needs and why a correct credential can still fail a signature check, and turning your support inbox into tickets covers the email path that feeds the email channel counter. When a count moves sharply in the wrong direction, why your live chat volume suddenly dropped is the checklist for telling a real drop from a measurement one.
A message that is nothing but a photo counts the same as one carrying text, which matters more once you know that the photo itself is never stored on your side.