Alerts and destinations

Alerts are how InfraNest tells you when something needs attention — a monitor down, a certificate expiring, a domain about to lapse. You set up destinations (where alerts go) once, and choose which alerts go where.

#Destinations

A destination is somewhere alerts are delivered: email, Slack, Microsoft Teams, Telegram, Discord, or a webhook. Manage them under Alerts → Destinations — add one, send a test, and edit or remove it. Each messaging destination has its own connect guide (see Integrations).

#Everything about your alerts on one page

The Alerts page answers who hears about a problem, in one place:

• How does your team handle problems? The first time, one question sets your alerts up: just you, a small team, or a team with someone on call. It says exactly what it will set up, naming your channels, PagerDuty and a monthly test on every destination, which it turns on. Before you choose, it also says what is still missing for that answer, such as a team channel or PagerDuty.
• Your alert setup checks that every monitor reaches someone, that your team shares a chat channel, and that every destination was tested in the last 30 days. Anything that needs attention has a button that fixes it. These checks also run every night: if one that was fine gets worse — the team channel is gone, or destinations are no longer tested — it shows up under Needs you on Home and in your "needs you" email, and goes as soon as it's fixed.
• Send a test outage sends a test to every destination and to everyone who gets their own email, then lists who got it. Nothing is really down, and every message says TEST.
• When a monitor goes down shows who it reaches: your destinations, and the people who get their own email.
• Team shows your team's defaults and lets you change them right there. See who hears what lists every member, whether they get their own email when a monitor goes down, and which defaults they chose differently. If you're the only member, there is no team to set up yet, so the page leaves Team out and speaks about you alone. Invite someone and it appears.
• Quiet right now lists everything holding alerts back, wherever it was set: maintenance, a snoozed server, a silenced monitor, a paused workspace. Each has End now.

Each destination says in one sentence what it hears, for example Hears urgent alerts only — at any hour. Choose Change to set what it hears and when, without opening its connection settings. The same panel turns the monthly test on or off, sends a test, removes the destination, and links to its connection settings. A new email destination starts on critical alerts only, so a shared inbox gets outages straight away and warnings go to the daily digest.

This is the only place it is set. A destination's own page under Integrations shows the same sentence and a Change on Alerts link that opens it here. A destination you added for yourself is the exception: you change it on its own page.

#Who also gets their own email

When a monitor goes down, your destinations get the alert, such as a Slack channel or a team inbox. You decide who also gets it in their own inbox, in your team's notification defaults:

• Owners and whoever is on call — the workspace owners, and the person on call in PagerDuty if you use it. Without PagerDuty, this is the owners only. New workspaces start here.
• Everyone — every member gets their own email as well.
• Nobody — only your destinations get it.

Everyone still sees every alert in InfraNest and on their phone. If no destination gets an alert, or none of them can deliver it, everyone is emailed. A member who wants every monitor alert by email can still choose that for themselves. The other way round works too: anyone, owners included, can choose Only email me when no team destination has it in My account → Notifications. Every copy that a destination also got ends with a link to that switch, under a line saying why that person got it. On a monitor's page, Who hears about this? shows the destinations, what each one hears (every alert, urgent only, or every alert in its hours), the people who get their own email and the team's rule behind that, with Change team defaults. While you change the defaults, With this choice, an outage reaches shows who would get the alert and how many emails and other messages each outage would send.

#Choose where alerts go

Alert routing is chosen per object — attach the destinations you want to a specific monitor, server, DNS zone or domain, so related things share consistent alerting. You can also route by severity, so only important events reach certain destinations.

#Your own address as a destination

If an email destination is the same address as someone in your workspace, that person gets one email per alert, not two. It's their own email, with Acknowledge and Silence 1 h buttons and everything the destination's email would have said: what happened, where it's down from, when it first failed and the last good response. If they've switched that kind of email off for themselves, the destination still sends it, so nobody misses an alert.

Times in an email sent to a destination are in your workspace's timezone. If none is set, it uses the timezone of your workspace's owner.

#A new monitor that has never worked

If a monitor hasn't had a single successful check since you set it up, InfraNest doesn't call it an outage. The site didn't stop working; most likely the monitor's address or expected answer isn't right. You'll see has not worked yet on Home and in your "needs you" email, and the email to your destinations starts with the same explanation and shows Never as the last good response. Check the monitor's URL and expected status. Once one check succeeds, later failures are reported as normal outages.

#If a destination stops working

When a service turns our alerts away — a webhook URL that has been regenerated, a key that has been revoked — the destination is marked Not delivering and whoever owns it gets told, by email and in the notifications bell. It stays switched on and InfraNest keeps sending to it, so it starts working again on its own the moment the problem is fixed. Meanwhile every alert it turns away is emailed to whoever owns it instead, and kept so it can be sent there once it works. See A destination says it is not delivering.

#Prove a destination works before you need it

A destination that hasn't had anything to deliver in months can stop working without anyone noticing — a Slack channel that was archived, an inbox nobody reads any more. To catch that early:

1. Go to Alerts → Destinations.
2. On the destination's card, switch on Monthly test.

InfraNest then sends a test alert there once a month (the first within a day). The card shows how the last test went:

• Last test delivered — the service confirmed it posted the message (Slack, Discord, Telegram, PagerDuty), or someone confirmed they saw it.
• Last test sent, not confirmed yet — email and Microsoft Teams accept a message without saying whether anyone saw it. Every test message has an I got it link: open it and select I got it, and the card changes to delivered.
• Last test failed — the service turned it away. See A destination says it is not delivering.

The I got it link works for 14 days and can be used once. Opening it only shows a page; nothing is confirmed until you select the button, so a link preview in Slack or Teams can't confirm it for you.

If a destination hasn't delivered anything in 10 weeks, the Watch better list on the monitoring overview offers to Send a test to it.

#What changed just before it went down

When a monitor goes down and exactly one thing changed in the 30 minutes before — a deploy, a DNS or firewall change, an edit to the monitor, or the provider's own outage — the alert email says so in a Likely cause row, with when it happened, who did it and a See it link. If the change came through one of your API tokens, the row names the token too — for example by Sam · via token deploy-bot — so you know which script or integration to look at. For a change someone made in InfraNest, the link opens the audit log on just that change; click Show the whole log to see everything else. It's the same answer Home shows.

If several things changed, or nothing did, the email says nothing about it: a wrong guess at 2am costs more than no guess. Open Home to see the full list.

#What the down email already checked for you

Under the details, a monitor's down email lists What we already checked — the things you would otherwise look up first:

• The other monitors on the same server — whether they are down too (then the server itself is the likelier place to look) or still up (then it is more likely this one service).
• The last deploy in the hour before it went down, with who shipped it and a link to it — when you have linked a GitHub repository to the monitor. If nothing went out, it says that too.
• The previous outage of this monitor: when it was and how long it lasted, and how many outages there have been this month.
• The certificate and, for DNS monitors, the DNS answer — as the monitor's own last check read them.

Everything in this list comes from what InfraNest already recorded; nothing is looked up again while the email is sent. A line we have no information for is simply left out.

If the monitor is on one of your status pages, the email also has a Post an update link. It opens the incident with the update form ready, so visitors to your status page know you are on it.

#What the back-up email tells you

The email saying a monitor is back up tells you how long it was down for, how soon the first alert went out, and the monitor's uptime this month. Below that is a short Timeline of the outage: when it went down, when the first alert was sent and where, who acknowledged it, any status updates that were posted, and when it came back.

If something is still open after the recovery, the email says so — for example a status page that still shows another monitor's incident, or an announcement you posted during the outage that is still showing. Each comes with a link to the status page, so you can tidy it up.

#Down and back up arrive as one conversation

The same goes for server alerts (a disk filling up, a service failing, the agent going quiet), an integration that stopped syncing, and an alert destination that stopped delivering: the problem, any "still happening" follow-ups and the all-clear share one subject, such as web-1: disk space, since Oct 18, 2026, 2:02 PM.

Expiry reminders work the same way: every reminder about one domain's or certificate's expiry — 60, 30, 14, 7 and 1 days before — is one conversation named after the date, such as acme.com — expires Nov 17, 2026. Once it's renewed, the next expiry starts a new one. A domain transfer's start and, if it happens, its failure are one conversation too.

When a monitor goes down, the alert and the email saying it's back up share one subject — for example Shop — incident #142 — so your mail app stacks them into one conversation instead of two separate emails. Whether it's down or back up is the first thing in the preview line and at the top of the email. The next outage starts a new conversation.

Next to View incident, the email offers Investigate with Claude · ChatGPT, and a Slack or Telegram alert has an Ask Claude button while the incident is open: each opens a conversation with the question already written. Your assistant needs InfraNest connected first — see Connect Claude or ChatGPT to InfraNest.

If your plan doesn't include incident management, the subject names when the outage began instead, such as Shop — outage since Jul 15, 2026, 10:43 PM CEST. The emails also have no View incident link or investigate links; View monitor takes you to everything there is.

This works in Gmail, Outlook and Apple Mail, as long as conversation view is switched on in your mail app (in Gmail: the gear icon → Email threading → Conversation view).

#Filter or route alert emails

Because the subject is now the same for both halves, don't filter on words like "DOWN" in the subject. Every alert email carries a List-Id that says exactly which kind of alert it is:

• Gmail: search or create a filter with list:alert-monitoring-down.alerts.infranest.io.
• Outlook: create a rule with the condition Message header includes and the text alert-monitoring-down.
• Apple Mail: in Settings → Rules, add a condition, choose Edit Header List…, add List-Id, then use List-Id contains alert-monitoring-down.

#Let alerts through Focus, or mark them VIP

Alerts and summaries come from two different addresses, so you can let one through and keep the other quiet:

If your workspace has its own sender name set, that name is shown instead, but the addresses stay the same.

Add alerts@notify.infranest.io to your contacts first, then:

• iPhone and iPad: in Mail, open an alert, tap the sender and choose Add to VIP. To let alerts through a Focus, go to Settings → Focus → your Focus → People and add the contact.
• Gmail: create a filter for From alerts@notify.infranest.io and tick Never send it to Spam and Always mark it as important.
• Outlook: with Focused Inbox on, right-click an alert and choose Always move to Focused.

Don't do the same for digest@notify.infranest.io unless you want the summaries to break through too. Keeping them apart is what lets the alerts stand out.

#When something recovers

When a problem is over, the all-clear is linked to the alert it closes, as far as each app allows:

• Telegram — the original alert is updated to say Resolved after 19 min, and the all-clear arrives as a reply to it.
• Discord — the original alert is updated the same way, and the all-clear says which alert it closes.
• Slack and Microsoft Teams — these can't update a message InfraNest sent, so the all-clear says which alert it closes, for example Alert from today, 03:12 · resolved after 19 min.

#Several alerts of one kind at once

When several alerts of the same kind arrive together, for example five certificates reaching their 14-day reminder on the same morning, a destination gets the first one straight away. The rest come a few minutes later in one message, such as 4 more alerts: Certificate expiring, with a line for each. Nothing is left out, and every alert is still listed on its own on the Alerts page. PagerDuty works differently: it still gets each alert separately, so each problem has its own incident.

#A daily list in your team channel

A Slack or Teams destination can also receive the "needs you" list — everything that is waiting on a person — daily or weekly. Open the destination and choose it under “Needs you” list. Alerts keep arriving as they happen; the list is the calm summary beside them.

#Send a noisy source to the daily digest

Some alerts are real but never urgent: a backup server that runs hot every night, a test site that blips. Instead of making them fire less, you can keep them and stop being alerted in the moment.

• A monitor: on its page, under Alerts, choose Send to the daily digest.
• A server alert rule: on the server's Alerts & rules tab, choose Send to the daily digest on the rule.

InfraNest asks you to confirm first, because from then on its alerts reach none of your destinations when they happen, not even when it goes down. Instead, each destination that would have been alerted gets one message a day, at 09:00 in your workspace's timezone, listing each monitor or rule once with how often it fired, for example Backups — down 3 times, the last at 03:12. PagerDuty is never sent the list.

Its incidents still open in InfraNest the moment they happen, so it still shows on Home, on the Incidents page and on its own page. A monitor or rule that goes to the digest says Goes to the daily digest where it is shown. Choose Alert at once again to switch it back; that needs no confirmation. Each change is in the audit log as Alert delivery changed, with what it was before.

When an alert keeps firing and nobody acts on it, InfraNest may suggest this for it, if its own setting can't quiet it any further or was already raised once. It only ever suggests: nothing changes until you confirm.

#Activity

The Activity tab shows a timeline of alerts that have been sent — what fired, when, and where it went — so you can confirm delivery and review recent history.

#"Urgent only" still tells you when it's over

A destination set to urgent alerts only, or one with quiet hours, skips the routine noise — but it always receives the all-clear for an outage it was told about. You never end up believing something is still down after it has recovered.

#Stop getting one kind of alert by email

Every alert email now has a link at the bottom. What it offers depends on where the email was sent.

If it came to your own personal destination, the link says Disable this notification. Clicking it stops that one kind of alert going to that destination — a certificate warning, say, while everything else keeps arriving. Your mail app's own Unsubscribe button does the same thing.

It is not hidden away afterwards. Go to your account settings → Notifications, and any personal destination you have switched something off for says so, with a Turn back on button next to it.

If it came to a shared address like ops@yourcompany.com, there is no unsubscribe link, on purpose. That address belongs to the team, not to whoever happens to open it — one person clicking "unsubscribe" would quietly stop the alerts for everybody, and the first anyone would know is the outage nobody was told about. Instead the email links to Manage this alert destination, which takes you to the destination itself so somebody can change it deliberately.

#Silence a noisy server straight from the email

When a server alert arrives — a metric over its threshold, or a server that has stopped reporting — the email also offers to silence that server for 60 minutes. It is there for the 2am case: you already know, you are already looking at the message, and you do not want four more of them while you fix it.

Clicking it opens a short confirmation page. Nothing is silenced until you press the button there — that is deliberate, because company mail filters and security scanners open links in messages automatically, and one of them quietly muting your monitoring would be a bad morning.

While it is silenced:

• the server is still being watched — nothing stops collecting;
• if it is still in trouble an hour later, you will hear about it again;
• everything else keeps alerting as normal.

It shows up in Monitoring → Maintenance as a window named after the server, so anyone on your team can see it is quiet and end it early. The link in the email works for a week and then stops — an old alert should not be able to silence a machine months later.

#Good to know

• Destinations can be personal (just yours) or shared with your workspace.
• Alerts also appear in the in-app notifications bell.
• Want to change which emails you personally receive? That's separate — see your notification preferences under your account settings.
• Security, billing and account emails never carry an unsubscribe link. Those are not alerts; they are things you need to be told about, like a failed payment or a sign-in from a new device.