An uptime figure with no method is decoration
GreetKeeper publishes no uptime number. Not because ours would be bad, but because a figure nobody can verify, defined by the party quoting it, is not information.
The short version
- Three questions dismantle most uptime claims: measured how, downtime defined as what, and what happens if it is missed?
- For a phone product, partial failure matters more than total failure and no uptime figure captures it.
- We make no uptime or SLA commitment. That is a limitation, stated rather than papered over with a number.
- The useful question is not the percentage. It is what happens to a call when something goes wrong.
What a percentage does not tell you
Measured how, and by whom? A vendor pinging its own health-check endpoint from its own network will produce a very different figure from one measuring whether real calls connected and completed. Both can be described with the same word.
Downtime defined as what? If the system answers but the transcription fails, is that downtime? If calls connect but bookings do not write to the calendar, is that downtime? For a product like this the interesting failures are partial, and a single availability percentage is blind to all of them.
And what happens if the number is missed? An uptime figure with no service credit and no contractual consequence is a statement of intent. That is not worthless, but it is not a commitment either, and the two get presented identically.
Why we publish nothing here
We have no measurement worth publishing. The product is built and not yet carrying real customer traffic, so any figure we printed would describe a test environment. That is exactly the kind of number this post is arguing against, and printing ours would make the argument dishonest.
We also make no SLA commitment. For some buyers that is disqualifying and it should be, especially anyone for whom a phone outage is a business-stopping event. We would rather say it plainly here than have it discovered in a procurement questionnaire.
The inherited claims from before this product was renamed included a 99.9 percent uptime figure. It had no measurement behind it. It is gone, along with several other numbers that could not be supported, and this post exists partly to explain why.
The question to ask instead
What happens to a call when your system is down? For a phone product there is a genuinely good answer available: the call falls through to a number the business specifies, so an outage degrades to a ringing phone rather than to silence. Ask every vendor whether that failover exists and how it is configured.
Ask also what happens when a component fails rather than the whole system. If the calendar write fails, does the caller get told, does the business get told, or does the booking simply not exist? A silent failure is worse than an outage because nobody goes looking.
Those two answers tell you more about engineering culture than any percentage will, and unlike a percentage you can test them.
Hear it handle one of your own calls
Your scenario, your greeting, a couple of minutes.