What we test before it touches one of your customers
Every build runs this list against your real data before anything reaches a real customer. It is published because the happy path proves almost nothing, and because you should be able to see what we consider finished before you decide whether to pay for it.
The one that proves almost nothing
We send a real job through the real system to a real handset and watch the message arrive. This is the check everybody demonstrates and it is the least informative one on the page. It tells you the thing works when nothing is wrong, which is not the condition you are buying insurance against.
Everything below is a way of breaking it deliberately.
The branch that causes damage if it is wrong
The review service asks the customer how it went before it asks for anything public. A good answer opens your actual review page. A bad answer opens a private form that reaches you and goes nowhere near the internet.
We check that second path twice, from a real phone, because getting it backwards means an unhappy customer is handed a one-tap link to publish exactly how unhappy they are. There is no undoing that, and no alert would tell us it had happened.
The same job, sent twice
We send the identical job through again. Nothing goes out the second time. A customer who gets asked for a review twice in an hour has learned something about you that a review would not have fixed.
A phone number that is not a phone number
We send a mangled number through on purpose. It is refused before anything is attempted, rather than being handed to the provider to fail on. A system that only refuses bad input after paying to try it is a system that will eventually charge you for a thousand of them.
Somebody replies STOP
We reply STOP from the test handset, then send two more jobs to that same number.
The first is expected to reach the provider and be rejected. That is correct and it is how the automation learns: nothing tells it about the STOP until a send comes back refused. It is filed as an opt-out and no alarm goes off, because nothing is broken.
The second must be refused locally, before the provider is contacted at all, with a reason naming the opt-out. Expecting the first one to refuse is the common mistake and we check for the second one specifically.
Then we send that same opted-out person a job that also has an email address on it. The email goes. The text does not. Opting out of texts is not opting out of existing.
Three in the morning
We set the quiet hours to bracket the next few hours and send a job into them. The message has to arrive after the window rather than not at all — a delayed message is a delayed message, and a message silently dropped because it was inconvenient is a lost job you never hear about.
We break your sending account on purpose
We revoke the credential the automation sends with and send another job. An alert has to reach us within a minute. Failure alerting is wired in before anything goes live — that is a condition of us shipping, not an upgrade — and an alerting path nobody has ever seen fire is not an alerting path.
The stop switch
We set the service to paused and send a job. Nothing sends. This is the control you use at four on a Friday when something is going wrong and you do not want to explain it to anybody first. It works without us and it does not delete anything.
What this list does not cover
One failure survives all of it: the automation doing exactly what it was told when the instruction was wrong. Nothing on this page catches that, no alert fires, and the run history shows a clean pass. That is what the monthly summary is for, and it is why the first month is worth actually reading.