Phone Call Alerts
When something is too important to bury in notifications — the agent calls your real phone, tells you what's wrong, lets you respond by voice.
Communicationmedium~45m setup
- Tools
voice_callmemorymemory_search- Channels
telegram- Uses
voicecron
The pile of notifications on your phone trains you to swipe them all away. The truly urgent stuff — a server going down, a price you've been waiting for, a client emailing about a fire — needs an unswipeable channel. A phone call from your AI is exactly that. If it's ringing, you know it matters.
What it does
- Defined alert conditions trigger an outbound Twilio call to your number
- The call delivers a 30-second briefing in your language
- You can respond by voice; agent transcribes and acts
- Common alerts: server down, urgent email from priority sender, morning brief on travel days, abnormal spending
- Easy to disable: silent hours, vacation mode, manual mute
What you'll need
- Voice tools with Twilio configured (setup)
- A short list of alert conditions (max 5–10)
- Your phone number(s) for outbound calls
- Cron + monitoring tools
Setup
1. Define alerts
Send to Flowly
Remember alert conditions (tag "phone-alerts"):
1. Server down — when ANY managed server's health check fails 3 times
in a row
Severity: critical. Always call.
2. Email from <priority-sender> with "urgent" or "ASAP" in subject
Severity: high. Call if business hours; SMS otherwise.
3. Stock <ticker> hits target price <X>
Severity: medium. Call if I haven't already acknowledged today.
4. Daily morning brief on travel days only (calendar event "travel")
Severity: info. Call between 6:30 and 7:30 AM at destination time.
5. Abnormal spending — credit card charge > $500 outside whitelist
Severity: high. Call within 5 minutes.
Per-alert: severity, my-phone, do-not-disturb-hours (default 22:00-06:00),
business-hours-only flag, max-calls-per-day (default 3 per condition).
2. Wire each alert to a trigger
For each condition, configure the right monitoring source:
- Server health → cron from self-healing server
- Priority emails → Gmail watch
- Stocks → cron from earnings tracker
- Spending → bank API webhook (varies by bank/processor)
When the trigger fires, it calls a shared phone_alert(severity, message)
helper.
3. Define the call protocol
Send to Flowly
Function phone_alert(severity: str, message: str):
1. Check do-not-disturb: respect hours unless severity=="critical"
2. Check max-calls-per-day for this condition (memory tag "calls-today:<cond>")
3. If ok, call my phone with this opening:
"Heads up — flowly here. <severity> alert: <message>.
Press 1 to dismiss, or talk to me to take action."
4. If I press 1: log dismissal, end call.
5. If I respond by voice: transcribe, run as a normal agent prompt
(within the call session — voice mode).
6. After the call: log to memory tagged "phone-alert:<timestamp>".
4. Test before you trust it
Trigger a low-severity alert manually:
Send to Flowly
Run a test phone_alert with severity="medium" and message="this is a test"
If the call comes through, the wiring is correct. Trust grows over weeks of low-severity tests before you let critical conditions auto-fire.
Tips
- Calibrate severity carefully. A critical alert that turns out to be a glitch wakes you up at 3 AM. Lean conservative — most things should be high or medium, not critical.
- Always provide a way to act. The opening line should imply what the user can do ("press 1 to dismiss" or "talk to me"). Calls with no recourse feel like robocalls.
- Don't chain alerts. If 5 servers go down at once, call ONCE for the cluster, not 5 times. The agent should batch.
- Match language. Caller language = phone owner language. A critical alert in the wrong language increases anxiety, not understanding.
- Audit calls weekly. Look at every call from the past week. Was each one worth ringing your phone? If not, raise that condition's threshold.
- Have a kill switch. A slash command
/mute-allthat disables all phone alerts for N hours. Some days you can't be on call.