Help center
Product guidance, setup steps, and the support channels for BinaryCanary accounts. Start here for anything specific to how the product behaves.
Resources and support
Get help, and get monitoring right.
Two things live here: where to go when you need help with BinaryCanary, and the handful of decisions that make monitoring worth having — whichever tool you end up using.
Get help
Support lives where the product does.
Setup questions, product documentation, and account changes are handled in the Help center and in your dashboard. There is no sales gate in front of any of it.
Log in to the dashboard
Monitors, notification settings, SMS credits, and billing are all managed in your account rather than through a conversation with us.
Plans and pricing
Four plans from $2 to $20 a month, every uptime-monitoring feature on every paid plan, and a 14-day free trial to try it on your own systems.
Where to start
Three decisions worth making deliberately.
What should you monitor first?
Start from consequence, not from inventory. List the handful of things whose failure a customer or a colleague would notice within minutes, and watch those properly before adding anything else.
A monitor should earn its place
Every check you add is a small ongoing tax on attention. If nobody would change what they're doing because of a particular signal, it isn't a monitor — it's a statistic.
Decide ownership before it's urgent
The worst time to work out who responds is while something is down. Give every monitored system a name next to it, and check that the name is still correct after people change roles.
Field notes
Down is easy. Degraded is where teams get hurt.
A total outage is unambiguous and, usually, quickly handled — the signal is loud and nobody argues about whether it's real. The expensive failures are the partial ones: the site that loads but takes eleven seconds, the server that's up but has stopped doing the one job it exists for.
These are expensive precisely because they don't trip the obvious alarm. They get noticed slowly, by whoever happens to be looking, and they're often reported by a customer first. The practical response isn't more instrumentation — it's being honest about which of your systems can fail quietly, and making sure at least one thing is watching those from the outside.
Alert fatigue is a design failure, not a discipline problem
When a team starts ignoring alerts, the instinct is to ask people to be more attentive. That almost never works, because the behaviour is rational: if most of what arrives is noise, ignoring it is the correct strategy.
The fix is upstream. Reduce what you're alerted about until every remaining signal is something you'd genuinely want to be woken for, then keep it that way. A short list you trust beats a long list you skim, and it's far easier to add a check back than to rebuild confidence in a channel everyone has learned to mute.
Write the next action down while it's boring
The gap between "something is wrong" and "someone is fixing it" is where incidents get long. A single line per monitored system — what it is, who owns it, what to check first — closes most of that gap, and it costs nothing to write on a quiet afternoon.
It also makes your monitoring reviewable. If you can't write that line for a check you have, that's a useful signal in itself about whether the check should exist.
A short review
Five questions worth asking once a quarter.
- What broke last quarter, and would we have found out sooner with a check we don't have?
- Which alerts fired, and did any of them change what somebody did?
- Is every monitored system still owned by someone here?
- What are we watching that we'd no longer bother setting up today?
- If our monitoring itself failed quietly, how long would it take us to notice?
Next step
Try these questions against your own estate.
14 days free, then from $2 a month. Already have an account? Log in.