Which channels can I send alerts to?
PageLantern delivers to Email, Slack, Microsoft Teams, Discord, Webhooks, PagerDuty, and SMS. Every channel except SMS counts against your plan's channel limit: 1 on Free, 5 on Starter, unlimited on Team. SMS is metered separately — 50 messages a month on Starter, 200 on Team, none on Free.
Add channels from Integrations. Each one takes a single credential — an incoming webhook URL for Slack, Teams and Discord, an integration key for PagerDuty, a recipient list for email, a phone number for SMS, an endpoint URL for a generic webhook — and each has a Send test notification button that performs a real delivery, not a simulated one.
How do I set up Slack, Teams or Discord?
All three take an incoming webhook URL, which you create in the chat platform rather than in PageLantern. In Slack, create an app, enable Incoming Webhooks, add one to the channel you want, and copy the hooks.slack.com URL. In Teams, add a Workflow (or the legacy Incoming Webhook connector) to the channel and copy its URL. In Discord, open Channel Settings, Integrations, Webhooks, and copy the URL.
Paste the URL into the matching integration and send a test. The webhook URL is a bearer credential — anyone holding it can post into that channel — so it is stored encrypted at rest and masked everywhere it is displayed. Rotate it in the chat platform if it is ever exposed.
How do I set up PagerDuty?
PagerDuty: create a service, add an Events API v2 integration, and copy the 32-character integration key into the PagerDuty channel. Alerts arrive as triggered events keyed on the monitor, and a recovery resolves the same event rather than creating a second one.
PageLantern does not provide on-call schedules, rotations or escalation policies of its own. If you need those, this is the path: PageLantern detects, PagerDuty decides who wakes up.
How do I stop getting alerts I do not act on?
Raise the failure threshold before you reduce the interval. The default opens an incident after 2 consecutive failures, which already filters single blips. Going to 3 on a monitor that flaps on a known-noisy network path costs you 1 extra check interval of detection time and removes most of the noise.
For monitors whose target sits behind bot protection or aggressive rate limiting, use the second-region confirmation policy instead. A failing check is re-run from a different region before an incident opens, so a rate limit applied to one egress IP does not page anybody. It is available on HTTP, HTTPS, API and content (DOM) checks — the check types a satellite in another region can reproduce as a plain HTTP exchange.
If a specific monitor is noisy for a reason you understand and cannot fix, give it its own channel rather than raising thresholds everywhere. Per-monitor routing exists precisely so one bad neighbour does not desensitise the whole team.
Can I see who was notified after an incident?
Yes. Delivery records are kept for about 180 days and are attached to the monitor and the incident, showing the channel, the outcome and the timestamp. Destinations are masked in those records — the address or URL is not stored a second time in the delivery log.
Use it in a post-incident review to answer the question that always comes up: was the alert sent and ignored, or never sent? Those have completely different fixes.