uptime and transparency: how to read our status page.

A public status page is not a marketing gesture: it's a form of accountability. If something breaks, we'd rather you see it there than find out because one of your customers complained the bot wasn't answering. Transparency about the state of the service is part of how you build trust in a system that handles real conversations for your business — not an optional technical detail.

The status page covers the components that, if they fail, directly affect your operation: the dashboard where your team works, the conversational agent that generates replies, each messaging channel (WhatsApp Business, Instagram DM, Facebook Messenger, Gmail), the public API and the webhooks that receive events from external platforms, and the background processes (workers) that process and dispatch every message. If any of these components has a problem, it shows up there, with the detail of what's affected.

It's worth being clear about something that sometimes gets misunderstood: WhatsApp, Instagram and Messenger are Meta platforms, not heysteff's. If Meta has a service disruption on their side — something that has happened to messaging platforms across the industry in general — no external provider, heysteff included, can keep messages flowing while that specific outage lasts.

What we do control is what happens to messages on heysteff's side when that occurs: they are not lost. Inbound and outbound messages that couldn't be processed at the time are queued in a background job system and retried automatically until the channel comes back. Nobody has to resend anything manually, and the customer doesn't have to write again.

When an external channel like WhatsApp notifies heysteff that a new message arrived, it does so through a "webhook" — an automatic notification. If that notification fails because of a network issue or a brief outage, the external channel usually retries it later. The obvious risk is that the same message ends up notified twice and the system processes it in duplicate, sending the customer a repeated reply.

To prevent that, every webhook heysteff receives is processed idempotently: the system recognizes when a message has already been processed and silently discards the duplicates, without generating a second reply or a second record. In simple terms: a retry never duplicates a conversation or an action, no matter how many times the external channel insisted with the same notification.

If you notice something that doesn't match what the status page shows — a channel that seems slow, a message that didn't arrive when you expected — write to us directly at [email protected]. We'd rather you flag it, even if it turns out to be a false positive, than silently assume everything is fine.

We deliberately don't publish historical uptime figures on this page: we prefer that you check the current state and recent history directly at /status, instead of quoting a percentage that can go stale the moment it changes. That same page updates in real time, so it always reflects what's happening right now with every component of the service.

• Real-time service status
• How heysteff protects your customers' data
• Human "echo" detection: how a bot knows when to stay quiet
• Frequently asked questions