Complete onboarding guide for new customers

Welcome to Beacon. This guide walks a brand-new workspace all the way to a monitored service with sane alerting, a public status page, and a team that knows what to do at 3am. Set aside about 45 minutes; every section stands alone, so you can stop and resume anytime.

If you only have ten minutes right now, run through the quick-start first and return here when you're ready to go deeper.

Before you begin

Gather three things:

• The URL or hostname of the service you want to watch
• The Slack channel and/or phone numbers that should receive alerts
• A rough idea of who is on call — even if that's just you this week

1. Create your first monitors

A monitor is one thing checked on a schedule. Start with the endpoints your customers actually touch.

1. Go to Monitors → New
2. Add an HTTP monitor for your main app URL. The default is a 60-second interval from three regions, failing on timeout (10s) or a non-2xx status
3. Add a second monitor for your API health endpoint (for example /healthz)
4. If you run background jobs, add a heartbeat monitor — your job pings Beacon on a schedule and we alert when it goes quiet

Tune the sensitivity. For critical paths set the failure threshold to 1; for flaky third parties set it to 3 or more. Full detail lives in the Alerting rules reference — the region-quorum setting in particular saves you from paging on transient network blips.

2. Understand how alerts get grouped

Before you wire up paging, know what will and won't reach a human. Beacon collapses related failures into a single incident instead of paging once per failed check — the full logic is in How does alert deduplication work?. The short version: consecutive failures of the same monitor extend one incident, and recovery needs three clean checks in a row, so flapping monitors won't re-page you every minute.

3. Build an escalation policy

Alerts are only useful if they reach the right person in the right order. Under Alerting → Escalation policies, create a policy like:

1. Notify the on-call engineer (push + SMS)
2. After 5 minutes unacknowledged → notify the whole engineering channel
3. After 15 minutes → phone call to a fallback contact

Map your monitors to this policy. The most specific match wins: a monitor-level rule beats a tag-level rule beats the workspace default.

4. Connect your channels

Beacon ships Slack, phone/SMS, email, and generic webhook integrations. Most teams start with Slack + SMS.

Channel	Best for	Setup time
Slack	Team awareness	2 min (OAuth)
SMS / phone	Waking someone up	2 min (verify number)
Email	Low-urgency digests	instant
Webhook	Piping events into your own systems	5 min

If you plan to script against Beacon or pipe events elsewhere, create an API token now — see REST API authentication for scopes and examples. Tokens are shown once, so store them in your secrets manager.

5. Publish a status page

A status page turns "is it down for everyone?" tickets into self-service answers. Follow Add your first status page for the full walkthrough. The one rule worth repeating: publish it before your next incident. A status page that appears mid-outage reads as damage control; one with months of green history builds trust.

Group monitors into components your customers recognize — "API", "Dashboard", "Webhooks" — not internal service names. Turn on subscriber notifications so customers get proactive updates.

6. Invite your team

Under Settings → Members, invite everyone who might respond to an incident. Viewer seats are free on every plan, so there's no reason to leave people out. Make sure at least two people are reachable by SMS — a single point of contact is a single point of failure.

7. Run a deliberate test incident

Do not wait for a real outage to discover a typo in a phone number.

1. Point a throwaway monitor at a URL you control and make it return a 500
2. Watch the incident open and the escalation policy fire
3. Confirm who actually got paged, on which channel, and how fast
4. Acknowledge the incident, fix the endpoint, and confirm recovery after three clean checks
5. Delete the throwaway monitor

If anything didn't reach the right person, fix it now while it's cheap.

What good looks like after week one

• Every customer-facing endpoint has a monitor with an appropriate threshold
• One escalation policy per urgency tier, tested end to end
• A published status page with subscriber notifications on
• At least two people reachable out-of-hours
• One real (or simulated) incident handled start to finish

That's it — your next incident will be handled better than your last one. When you're ready to automate, the REST API authentication doc is the door into everything the dashboard can do.