Pushover and CodeWords: notifications that reach a person
When a push notification is the right channel, priority levels and the one that demands acknowledgement, quiet hours, and how to avoid training yourself to ignore your own alerts.
Aymeric Zhuo11 min read
On this page
Most automation notifications go to a chat channel, and for most purposes that is right: visible, discussable, and easy to ignore when you are not working. Occasionally ignorable is exactly wrong. The backup has not run for three days, the payment processor is rejecting everything, the freezer temperature is climbing.
Pushover exists for that narrow category. It sends a push notification to your own devices, it has a priority level that will keep sounding until acknowledged, and it costs a one-off fee rather than a subscription. The skill in using it is entirely about restraint.
What we'll cover
When push is the right channel
The question is what you want the recipient to do, and how soon.
A chat channel suits anything a team should see and discuss, and anything that can wait until working hours. Most automation output belongs here.
Email suits anything that is a record rather than a prompt: reports, summaries, confirmations.
A push notification suits something one person must act on, soon, and would otherwise miss. That is a much narrower category than it first appears.
A phone call or a pager suits genuine production incidents with an on-call rotation, which is a different product category with escalation policies and schedules.
Pushover sits between chat and paging: personal, immediate, with an acknowledgement mechanism, and without the rotation management. That makes it well suited to solo operators, small teams, and home or physical systems, and poorly suited to anything needing an on-call schedule.
What the Pushover API offers
Messages with a title, body, and optional URL, sent to a user or a group by key.
Priority levels from lowest to emergency, which change how the notification behaves on the device, including whether it bypasses quiet hours.
Emergency priority with retry and expiry, which repeats until acknowledged, and reports the acknowledgement back. This is the capability that distinguishes the product.
Receipts for emergency messages, so an automation can check whether anybody acknowledged and escalate elsewhere if not.
Sounds per message, so different alert types are distinguishable without looking.
Delivery targeting to specific devices, which matters if you want something on a phone but not a desktop.
Attachments, for sending an image with the alert, which is useful for anything visual such as a camera or a chart.
Connecting it to CodeWords
CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.
- Open CodeWords and start a new automation.
- Describe what should happen in plain language to Cody, the automation builder: what condition warrants a notification, at what priority, and to whom.
- Authorize the connection with your Pushover application token and user or group key.
- Describe the escalation: what happens if an emergency alert is not acknowledged within the window.
- Test each priority level once, deliberately, so you know what each feels like before something real uses it.
You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
Priority, used properly
The levels exist to be used differently, and using them all the same way is how the product stops working for you.
Lowest and low generate no sound or vibration. Suitable for things you want recorded on the device and do not want interrupting anything. Most automation output that reaches Pushover at all should be here.
Normal behaves like an ordinary notification, respecting quiet hours. This is the sensible default for anything worth a glance.
High bypasses quiet hours and is visually prominent. Reserve it for things genuinely worth waking up for, and be honest about how short that list is.
Emergency repeats at an interval you choose until somebody acknowledges, and it continues until the expiry you set. This should be rare enough that receiving one is itself information.
The discipline that matters: decide the level by the consequence of nobody noticing for eight hours. If the answer is "nothing much", it is low. If the answer involves money, safety, or data loss, it is high or emergency. Everything else is normal, and most things should not be here at all.
Six things worth alerting on
Backups that did not complete. Absence rather than failure, which is the version nobody alerts on and the version that matters.
Certificate and domain expiry approaching. Entirely predictable, entirely preventable, and still a regular cause of outages.
Payment and billing failures. A payment processor rejecting transactions is revenue stopping, and it is worth interrupting someone for.
Physical monitoring. Temperature, water, power, door sensors. This is a substantial part of what Pushover is actually used for and the case where an emergency priority genuinely earns its place.
A scheduled job that has not run. The heartbeat that is missing, detected by something other than the job itself.
Security events. A login from somewhere unexpected, a permission change, a new administrator. Rare enough to warrant interruption and consequential enough to justify it.
Notice what is not on this list: deployments, ordinary errors, daily summaries, and anything that is merely interesting. Those belong in a channel.
Avoiding alert fatigue on yourself
The failure mode here is personal rather than organizational, which makes it easier to ignore and harder to fix.
Every alert must have an action. If receiving it does not change what you do, it should not be a push notification. This single rule removes most of what people initially configure.
Deduplicate. A flapping condition should produce one alert, not forty. Suppress repeats within a window, and say how many occurrences were suppressed when you next report.
Use distinct sounds per category. Being able to tell from the sound whether this needs you now or at breakfast is worth the five minutes of configuration.
Respect quiet hours except for genuine emergencies. If everything bypasses quiet hours, you will turn the notifications off entirely, and then nothing works.
Review monthly. Any alert you have received repeatedly and not acted on should be downgraded or deleted. This takes ten minutes and is the difference between a system you trust and one you mute.
Send a weekly heartbeat. One low-priority message confirming the monitoring itself is alive. Without it, silence means either nothing is wrong or the monitoring is broken, and those are very different.
Building it so it survives
Do not let the alerting depend on the thing it monitors. An automation running on the same machine it watches cannot tell you that machine is down. Run the check from somewhere else.
Handle the acknowledgement path. For emergency alerts, check the receipt and escalate elsewhere if nobody acknowledges. An emergency alert nobody sees is the same as no alert.
Include what is needed to act. The message should say what, where, and since when, with a link. An alert requiring investigation before you know whether to get up is a poor alert.
Make it safe to run twice. Retries should not produce duplicate notifications, which is what deduplication keys are for.
Log everything sent. When you are deciding what to prune, the record of what fired and how often is what you prune against.
Limits worth knowing about
There is a monthly message allowance per application on the standard licence, which is generous for genuine alerting and easily exceeded by anything chatty. That constraint is a useful discipline rather than a problem.
Emergency retries count toward that allowance, so a long-unacknowledged emergency consumes several messages.
Delivery is best-effort, as with any push notification, and depends on the device being reachable. For anything where delivery must be guaranteed, pair it with a second channel.
Attachment size is limited, which matters for camera images.
It is a one-off purchase per platform rather than a subscription, which is unusual and worth knowing when comparing against alerting products with per-seat pricing.
What to build first
A heartbeat check on whichever scheduled job you would least like to discover had silently stopped — usually backups. Run the check from somewhere other than the machine doing the work, alert at high priority on absence, and send yourself a weekly low-priority confirmation that the checker itself is alive.
Two habits make the difference. Test each priority level deliberately before something real uses it, so you know what each feels like at three in the morning. And review what fired every month, downgrading anything you did not act on, because the value of this entire setup is that an alert means something.
Frequently asked questions
When should I use Pushover rather than a chat channel?
When one specific person must act soon and would otherwise miss it. Chat is right for anything a team should see and discuss, and for anything that can wait. If you cannot name the person and the action, it belongs in a channel.
What is emergency priority for?
Conditions where nobody noticing for hours has real consequences: data loss, safety, or significant money. It repeats until acknowledged and reports the acknowledgement back, which is the feature that distinguishes it. Used for anything less, it stops working, because you will start dismissing it reflexively.
How do I stop alerts waking me for nothing?
Set the priority by the consequence of nobody noticing for eight hours, respect quiet hours for everything except genuine emergencies, and delete any alert you have ignored twice. The temptation is to make everything high priority, which reliably ends with the notifications turned off.
Can it replace an on-call system?
For a solo operator or a small team, largely yes. It has no rotation management, no escalation policies, and no schedule, so a team needing those should use a product built for it. The acknowledgement receipt does let you build a simple escalation yourself.
What happens if nobody acknowledges an emergency alert?
It repeats until the expiry you set, and the receipt tells your automation nobody acknowledged. That is the hook for escalating elsewhere — a second person, a different channel, a phone call — and building that path is what makes emergency priority genuinely reliable.
Should I send deployment or daily summary notifications?
No. Those are the classic mistake. They arrive frequently, they require no action, and they teach you to dismiss notifications without reading them, which is precisely the habit that makes the important one useless.
How do I know the monitoring itself is working?
Send yourself a weekly low-priority heartbeat. Without one, silence is ambiguous between everything being fine and the monitoring having quietly died, and the second is depressingly common.
Can several people receive the same alert?
Yes, through a delivery group, and think about whether you want that. An alert reaching five people is an alert five people assume somebody else is handling. For anything needing action, a named recipient with an escalation path beats a group.
How do I test an emergency alert safely?
Send one deliberately, at a time you choose, and let it repeat until you acknowledge. Knowing exactly what it sounds like and how it behaves before something real uses it is the difference between acting immediately and spending thirty seconds working out what is happening.
What should the weekly heartbeat say?
That the checks ran, how many fired, and how many you acknowledged. Three numbers. It confirms the monitoring is alive and it gives you the monthly pruning data without any extra work.
Can it be used for team alerting rather than personal?
It can, through delivery groups, and it lacks the rotation and escalation management a team on-call really needs. For a small team where everyone is effectively always on call it works well; beyond that, a product built for scheduling is the honest answer.