Every security event to your phone.
When something touches your server — an SSH login, a fail2ban ban, a CrowdSec or auditd rule — the user, source IP, and rule land on your phone in under a second. Know who logged in before they finish typing.
From login to push
Wire any login, ban, or rule trigger to a single curl and the event reaches your phone as a push notification.
SSH login push
A login script in /etc/profile.d or an sshrc curls PocketAlert with the user and source IP on every interactive session.
fail2ban bans
fail2ban runs a curl in its actionban, so each banned IP shows up on your phone with the jail that caught it.
sudo and admin logins
A PAM hook or a sudo trigger fires when someone escalates, and a new admin login lands the same way.
IDS and audit triggers
CrowdSec, Wazuh, OSSEC, and auditd shell out to curl on a rule match.
Field mapping
GJSON field mapping pulls the user, source IP, and rule from a SIEM payload into the title and message.
Sub-second delivery
Pushes land in well under a second, fast enough to catch a session while it is still open.
Three steps to login alerts
Get an API key
Create an API key and a per-host application, then keep the key in an environment variable on the box.
Hook the event
Add a curl to your login script, fail2ban action, or IDS rule that posts the user and source IP.
Watch your boxes
Logins and bans hit your phone within a second. Put the event in the title so a root login from a new IP reads clearly apart from a routine deploy.
Alert on every login
1. Get an API key
Create an application in PocketAlert and copy your API key. Send it in the Token header. Give each host its own application so prod, bastion, and personal boxes stay on separate channels.
2. SSH login (sshrc or /etc/profile.d)
Drop a script in /etc/profile.d so every interactive login curls the messages API with the user and source IP from $SSH_CONNECTION:
# /etc/profile.d/pocketalert-login.sh
[ -n "$SSH_CONNECTION" ] && curl -s -X POST "https://api.pocketalert.app/v1/messages" \
-H "Token: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d "{\"title\":\"SSH login\",\"message\":\"$USER from ${SSH_CONNECTION%% *} on $(hostname)\"}"
3. fail2ban ban (custom action)
Add an action in /etc/fail2ban/action.d/pocketalert.conf and reference it from a jail. fail2ban substitutes <ip> and <name> on each ban:
[Definition]
actionban = curl -s -X POST "https://api.pocketalert.app/v1/messages" \
-H "Token: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"title":"fail2ban: banned <ip>","level":"critical","message":"jail <name> banned <ip>"}'
4. SIEM (webhook)
For a SIEM or IDS that emits JSON (Wazuh, CrowdSec), create a webhook with a GJSON message template that maps its payload, then point the tool at the receive URL:
curl -X POST "https://api.pocketalert.app/v1/webhooks" \
-H "Token: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"name":"Wazuh alerts","message":"%rule.description% from %data.srcip%","application_id":"qm47b9pzxzxg"}'
You get https://p4a.me/wh/1234abcd to paste into the tool's integration settings.
See the webhook settings docs for the messages API and GJSON field mapping.
Questions, answered
Drop a small script in /etc/profile.d that curls PocketAlert with $USER and the IP from $SSH_CONNECTION. Every interactive login then pushes to your phone.
fail2ban runs a curl in its actionban. Map the banned IP and jail into the message body, and you see each ban as it happens.
Put the event in the title so it reads at a glance: a root login from a new IP and a routine deploy-user login land as clearly different alerts. Give sensitive hosts their own application to keep them apart.
Yes. CrowdSec, Wazuh, OSSEC, and auditd can all shell out to curl on a trigger. GJSON field mapping pulls the user, source IP, and rule into the title and message.
Give each host its own application: prod, bastion, personal. Per-application channels keep the alerts separate so you know which box raised the flag. PocketAlert relays the event; it is not an IDS.
Yes. Add "level":"critical" to the curl and Android posts it to a dedicated notification channel that bypasses Do Not Disturb — you grant DND access once. On iPhone, high and critical arrive as time-sensitive notifications that break through Focus modes. Keep routine deploy-user logins at level silent instead: no sound or vibration, but still in the history when you want the audit trail. On the free plan critical is delivered as high — still instant, just without the DND override.
Know who logged in before they finish typing.
Hook a login script or fail2ban action to PocketAlert and watch who touches your boxes.