When something
breaks, we tell you.
Messaging platforms fail in ways that are invisible from the outside: the send looks queued, nothing moves, and nobody says why. Here is what we commit to instead.
Incidents reported by email to affected workspaces · support@amplifeed.tech
What we commit to during an incident
- We contact you directly. If your workspace is affected, you get an email. You should not have to discover an outage by refreshing a status page.
- We say what is actually wrong - which channel, which direction, and whether messages are delayed or lost. "Investigating" on its own is not a status.
- We tell you what happens to the queue. Whether a delayed broadcast will still go, and when, or whether you need to re-send it.
- You are not billed for what did not arrive. Sends are billed on delivery, so a failed message is not a charged message.
- We follow up afterwards with what broke and what changed, for anything that affected sending or data.
If something looks wrong right now
Email support@amplifeed.tech with your workspace name and roughly when it started. If a broadcast is sitting and not moving, say which campaign - that is the single most useful detail and the one most often left out.
The component list above is maintained by us rather than driven by an automated feed, and it reflects known incidents rather than live probes. We would rather tell you that plainly than dress a static page up as monitoring. A live feed is on the list.
Planned maintenance
Anything that could interrupt sending is scheduled outside Indian business hours and announced to affected workspaces beforehand. Routine deploys do not interrupt sending and are not announced.
Nothing here matching what you're seeing?
Then it is probably specific to your workspace, which is worth telling us about. Most of what we fix quickly gets reported by a customer before it shows up on our side.