This recent global Cloudflare outage is a harsh but honest reminder:
As long as your system depends on a server being alive,
the moment that server goes down, your protection goes down with it.
This is not about blaming Cloudflare,
and it’s not about saying any particular cloud provider is “bad.”
It’s simply the reality of how the modern internet works:
Today’s infrastructure is built so that too many services share the same bloodstream.
When one major backbone fails, a whole row of services can collapse together.
How most “cloud-based safety & location services” work
Many safety apps that use location data follow a similar pattern:
- Your phone periodically sends your location to a server
- The server stores, analyzes, and plots your movement history
- When the server decides “something might be wrong,” it:
- Sends push notifications
- Emails or messages your emergency contacts
- Or calls other third-party services
On the surface, this sounds very reasonable.
You can build a beautiful “cloud dashboard” that shows:
- Who is where right now
- Which route they took
- A feeling that “the system is watching over you” in the background
But this whole flow rests on a few hidden assumptions:
- Assumption 1: The server is up and running
- Assumption 2: The path from your phone to that server is working
(DNS, CDN, backbone routes, etc.)
If any of those pieces fail,
your phone is still in your pocket, you are still there,
but the system that’s supposed to “protect you”
may have been disconnected for quite some time.
Outages are one risk. Attacks and data leaks are another.
A server going down is only one type of failure.
There’s another risk many people quietly worry about,
but rarely look at directly:
“Long-term location + server storage”
＝ a long-term, centralized record of
where you go, who you meet, and when you leave or return home.
Once that kind of data is collected and stored somewhere,
these risks never fully go away:
- Poor internal access control and sloppy permissions
- External attacks that steal whole datasets
- Data being repurposed or accessed by third parties or certain organizations
These risks are just as real as a Cloudflare-scale outage.
They just don’t explode in your face all at once.
Instead, they show up one day as a news headline:
“User location data leaked from Service XYZ.”
When a “safety system” presents itself as protection,
but at the same time concentrates your life’s movements
on a single server,
to me, that’s a built-in contradiction.
That’s why we chose to do the opposite
Given all of this, I decided to take a different path—
one that’s less flashy, but simpler and more honest:
All detection and decision-making happens locally on your phone.
In practice, that means:
- Everyday monitoring
(for example: long periods of no interaction, unusual motion,
possible crash detection, etc.)
→ is calculated on the device, not sent to a cloud service for “approval.” - At the moment the system decides
“Something is seriously wrong”:
→ your phone itself sends your location
via SMS and auto-dial,
directly to people you trust.
There is no single “must-stay-alive” server in the middle acting as judge.
We don’t need to send your situation to some distant data center in another country,
wait for processing there, and then route it back to your family or friends.
All we really need are just two conditions:
- Your phone is still on and able to run the app
- There is at least a tiny bit of signal left to send an SMS or place a call
If those are true,
your protection is still active.
“On-device safety” is not glamorous—but it’s more honest
To be very honest, building a server-centric system
would make it much easier to tell a flashy story:
- You can show a live world map with little dots moving in real time
- You can build an admin platform, recurring subscriptions, and sell APIs
- When pitching to investors, “platform” sounds more scalable and impressive
But then I had to ask myself one simple question:
“In a real emergency, if a version mismatch or a server issue
prevents the SOS from being sent at all—
can I really say this system protected anyone?”
For me, the core purpose is clear:
The primary job of this system is to actually get an SOS out,
to the right people, at the right time.
What I’m building may never become a huge, high-margin platform.
It may never make me rich.
But if, in a critical moment,
it helps protect even a handful of lives more effectively,
that is already enough reason to keep going.
As long as your phone still has enough signal
to send a text or make a call,
your protection lives in your own hands—
not in some server room you’ll never see.
If you’d like to support this kind of protection
SafeGuard is currently a one-person, self-funded project.
There’s no big company and no large team behind it—just someone
trying to build a more honest, on-device way to keep people safe.
If this philosophy resonates with you,
and you’d like to help me keep improving and maintaining this system,
you can support me here (even a “one coffee” contribution means a lot):
👉 https://ko-fi.com/safeguardsos
Your support goes directly into development time, testing, and infrastructure,
and ultimately into one more SOS that actually gets delivered
when it matters most.
Thank you for reading,
and for taking a moment to think about what real safety should look like.
#SafeGuardSOS #ondevice #noCloudDependency #CloudflareOutage #safetyApp #personalSafety #locationPrivacy #autoSOS #emergencyAlert #offlineFirst
English 
Chinese