Why we built Sevloom
A simple alert. A pager that rings.
We wanted one API that sends an important alert straight to a mobile pager — without the bells and whistles that make simple paging feel complicated.
A practical beginning
We wanted a simple pager.
While building and operating Simply Send , we needed a straightforward way to alert a person when something important happened. The requirement was intentionally small: call one API, send the alert, and let the mobile pager ring.
We did not need a long list of bells and whistles. We needed a focused page with the right urgency and message, delivered to the right person, so they could act.
The moment that changed it
A quiet failure became a customer-impacting problem.
One day, a domain re-verification failure caused a serious problem for Simply Send. The domain became unverified because of an error that was easy to miss, and the system began rejecting customer emails. Customers could not send messages, but the failure did not create a meaningful alert for our team.
There was no dependable internal page, and there was no immediate support channel for customers to tell us that something critical had happened. Customers had to wait until Pacific Time support hours to reach out while the underlying problem continued. The failure was not dramatic in the logs, but its impact was real.
That experience made the gap obvious: important systems need a way to reach a person when an ordinary notification is too easy to overlook.
The first implementation
We built it inside Simply Send first.
After the domain failure, we needed a working solution quickly, so the first version was built in-house and tightly coupled to Simply Send. It was close to the systems that needed it, which made it useful immediately for critical internal errors and customer-support escalation.
That first version taught us what the core really needed: a reliable endpoint, a clear payload, a mobile device, and a sound that made the alert hard to miss. We kept the implementation focused because the goal was not to create another large operations platform. It was to make sure an important signal reached a person.
What we needed it to handle
The alert had to be useful when it mattered.
The hard part was making the alert useful at the exact moment someone needed it. A customer-facing workflow can fail after a successful request. A delivery worker can slow down without the main application appearing unhealthy. A background job can stop running while the rest of the system looks normal. Each situation needs a different level of urgency, but all of them need a reliable path to a person.
We also needed to avoid creating a second source of confusion. A page should not require a responder to learn a new operational language before they can understand it. The sender provides the severity, title, message, source, environment, and a stable deduplication key. The phone makes that context easy to see, uses a sound appropriate to the urgency, and records what the responder did next.
That led us to a deliberately narrow boundary. Monitoring and application systems remain responsible for detecting conditions. Sevloom is responsible for carrying the page to the people who can respond.
A change in direction
Then we separated it from Simply Send.
As the idea became more useful, we decided it should not remain a Simply Send-only feature. We extracted the paging capability into Sevloom so it could be deployed independently, evolve on its own, and serve teams with systems that have nothing to do with email.
That separation gave us a clear product boundary. Existing software detects the condition; Sevloom carries the page to the right circle. The API became the natural way to connect the two, with a protected service key and a structured payload that any backend, workflow, or automation can send.
We still use the same path inside Simply Send for critical internal errors and customer-support escalation, but the implementation is no longer limited to our own product.
When the idea became personal
We started thinking about people close to us.
After Sevloom became independent and API-driven, we heard about a break-in in a nearby neighborhood. It made us think about a different kind of urgent signal: what if the same simple mobile pager could help families or friends alert one another when something serious happened?
That question expanded Sevloom without changing its core. People should be able to create a small circle, connect the people they trust, and send a clear alert without first creating a business workspace or learning a complicated system.
That is where the two circle types came from. Managed circles are for teams, services, and software integrations: an owner manages the circle, API keys, members, and paired devices. Personal circles are for a smaller group that wants to connect directly from the mobile app. Both use the same focused idea — a page reaches the people who need to know.
A simple beginning
We built Sevloom because we needed it ourselves.
It started with a missed signal in Simply Send . We wanted a straightforward way to reach a person when something important happened, so we built one and began using it. The rest followed from that need.
Download Sevloom