Workers, Pages, zones, R2, KV, D1, Queues and Durable Objects — every resource your token reaches, watched from one connection.
- How you connect
- Sign in with Cloudflare and approve read-only access — no token to create. Beaam imports every resource it can reach; an API token still works if your organisation blocks third-party apps.
- What raises an incident
- Worker error rate · Pages deployment failures · Durable Object error rate · Zone 5xx ratio · Queue delivery failures
- What connecting needs
- Sign in with Cloudflare: Beaam requests read scopes only —
account-settings.read, workers-scripts.read, page.read, workers-r2.read, workers-kv-storage.read, d1.read, queues.read, zone.read, analytics.read, account-analytics.read — plus offline_access so the connection can renew itself. - API token instead: start from Cloudflare's Read all resources template, or grant Account Analytics Read plus a read permission for each product you want discovered.
- A product the credential cannot read is skipped and named on the integration page, not treated as a failed connection.
- Analytics dataset availability and retention vary by Cloudflare plan. A dataset your plan does not include is reported as unavailable.
- What Beaam will not tell you
- Pages Functions errors cannot be attributed to a project through Cloudflare's analytics, so Pages alerts on failed production deployments only.
- R2 and KV report a daily cumulative count with no error signal: charted, with no default alert. D1 has no default alert either, because the right threshold depends on a plan Beaam is not told.
- Error-rate alerts wait for at least 20 requests in the window (3 for a near-total failure), so a quiet Worker cannot page you at 3am over two bad requests.
- Metrics are always about a minute behind, the time Cloudflare takes to publish them.
- Queue backlog age, CPU and traffic volume are collected but off by default.
Connect DigitalOcean and Beaam watches cloud resource state, Droplet pressure and backups within a bounded account API budget.
- How you connect
- Sign in with DigitalOcean — read-only, no token to create. Beaam imports every Droplet it can see.
- What raises an incident
- Droplet not running · Provisioning stuck · Filesystem pressure · Backup freshness · High CPU · Managed resource health
- What connecting needs
- Sign in with DigitalOcean:
api:read, the global read-only scope. - Personal access token instead, with read scope; a fine-grained token also needs the
account read scope. - CPU needs DigitalOcean Monitoring's metrics agent on the Droplet. Database metrics exist for MySQL only.
- What Beaam will not tell you
- DigitalOcean's API reports a Droplet's lifecycle, not whether your app answers. Pair it with an HTTP check.
- Droplet-off, CPU, memory and load alerts are off by default.
- Deeper signals are read in rotation, so a disk crossing 90% alerts within about 20 minutes rather than one.
- DigitalOcean's own Uptime checks are not imported.
- Change correlation does not yet cover databases, Kubernetes, load balancers or certificates.
Watch Hostinger VPS lifecycle, pressure, recovery, security, Docker, websites, mail and subscriptions.
- How you connect
- Paste a Hostinger API token from hPanel. Beaam imports the operational resources it can read; no changes are made.
- What raises an incident
- VPS destroyed or suspended · VPS pressure and operations · Hosted service unavailable
- What connecting needs
- An hPanel API token. Hostinger has no read-only scope, so the token carries your own hPanel permissions; Beaam only sends read requests.
- There is no sign-in option: Hostinger's OAuth only accepts redirects to the user's own machine.
- Docker, malware scanning, snapshots, backups and the firewall may not exist on a given VPS. Beaam reads that as unavailable, not as a revoked token.
- What Beaam will not tell you
- Hostinger's API describes a VPS, not whether your site answers. Pair hosted sites with an HTTP check; website availability belongs to that check.
- Memory and disk percentage alerts are off: Hostinger reports bytes, not percentages.
- An intentional stop, a missing firewall or scanner, traffic and reboots are collected but off by default.
- If Beaam cannot read your VPS's telemetry, that is shown as Beaam's problem — degraded only after 10 failures in a row — never as your VPS being down.
Paste any URL and Beaam pings it every minute. You only hear about it if it goes down and stays down.
- How you connect
- Paste a public HTTP or HTTPS URL. Beaam starts watching immediately.
- What raises an incident
- Endpoint healthy · Response time
- What connecting needs
- A public
http or https URL — no credentials. Private, local and internal addresses are refused, as are ports other than 80, 443, 8080 and 8443. Up to 3 redirects are followed. - Up means a 200–399 response by default; set your own range per service. Optionally require text in the first 1 MB of the body. Requests time out after 10 seconds.
- What Beaam will not tell you
- Beaam sees only what the URL returns: a broken app that still answers 200 looks up. Use the expected-text check, or point it at a health route that tests what matters.
- Broken means 2 of 3 checks failed; slow (3 seconds or more) is degraded, not down.
- A bare URL has no change history, so there is nothing to correlate an incident against.
Point Beaam at any remote MCP server and it validates the current MCP discovery + tools/list exchange every minute, with legacy fallback. You hear about it only if it actually breaks.
- How you connect
- Add a Streamable HTTP or SSE endpoint and its supported authentication.
- What raises an incident
- Server reachable · Response time
- What connecting needs
- An
https endpoint speaking Streamable HTTP or SSE, with no authentication, a bearer token, basic auth or a custom header. Private and local addresses are refused. Requests time out after 15 seconds.
- What Beaam will not tell you
- Beaam checks the server answers the MCP handshake and lists its tools — not that each tool works. A 200 that does not speak MCP counts as down.
- The tool count is charted, not alerted on.
- An MCP server has no change history to correlate against.
Connect a read-only Atlas service account; Beaam watches cluster health — disk, connections, replication, CPU and more — and tells you only when something needs your attention.
- How you connect
- Create an Atlas service account with organization read access and paste its client ID and secret. The secret is shown once by Atlas and stored encrypted here.
- What raises an incident
- Cluster missing · Disk used % · Connections % of limit · Replication lag · CPU % · Native availability alerts · Native backup alerts
- What connecting needs
- An Atlas service account (client ID and secret) with the Project Read Only role — or Organization Read Only to discover every project. Not a legacy API key.
- If your organization restricts API access by IP, allow Beaam's egress addresses.
- Shared tiers (M0, M2, M5 and Flex) expose fewer measurements: disk, memory and oplog generally need M10 or above, and shared tiers report no disk at all.
- What Beaam will not tell you
- Sharded and geo-sharded clusters cannot be monitored.
- A paused cluster stays quiet by default.
- Measurements more than 20 minutes old are discarded rather than shown as current.
- Memory, query targeting, queue, IOPS, oplog and disk-free alerts are off by default.
Connect a Neon API key and Beaam watches project, default-branch, compute, quota, and operation health without paging for normal scale-to-zero.
- How you connect
- Paste a personal, organization, or project-scoped Neon API key. Beaam imports its complete authorized project scope.
- What raises an incident
- Database availability · Control-plane operations · Quota
- What connecting needs
- A Neon API key: personal, organization or project-scoped. A project-scoped key is the least privilege. Beaam only calls read endpoints. There is no sign-in option.
- Neon allows 700 API requests a minute per account; Beaam stays under 600 and reports projects beyond that budget as a collection error rather than as empty.
- What Beaam will not tell you
- Idle computes and scale-to-zero never alert, and an archived default branch is not an outage — Neon unarchives on access.
- Neon's control plane does not expose SQL availability, CPU, memory, connections, cache, deadlocks, database size or replication lag, so Beaam does not see them.
Connect Netlify and Beaam watches site state, production deploy outcomes, stuck builds, and custom-domain TLS.
- How you connect
- Sign in with Netlify — no token to create. Beaam imports every site it can see, and only ever reads.
- What raises an incident
- Production deploy · Site and TLS
- What connecting needs
- Sign in with Netlify, or a personal access token (
nfp_). Netlify has no scopes: either grant covers the whole account, read and write. Beaam only reads with it.
- What Beaam will not tell you
- Netlify's API cannot prove a visitor gets the right response. Pair the site with an HTTP check.
- No function or runtime errors, edge traffic or log drains — those are an Enterprise stream.
- Preview and branch deploys never affect health.
- A failed deploy is degraded, not broken. Account credit exhaustion is not predicted.
Watch Polar revenue operations, failed payments, disputes, refunds, subscriptions and webhook delivery.
- How you connect
- Sign in with Polar and approve read-only access to one organization — no token to create.
- What raises an incident
- Organization and payouts · Revenue operations · Webhook delivery · Subscription payment health
- What connecting needs
- Sign in with Polar, or an Organization Access Token (
polar_oat_). Either way: organizations:read, subscriptions:read, events:read, payments:read, checkouts:read, orders:read, refunds:read, disputes:read, webhooks:read, metrics:read. - One organization per connection: a credential that reaches more than one is refused.
- Sandbox organizations need a token — sign-in is production only.
- What Beaam will not tell you
- Revenue, MRR, conversion and churn are charted, never alerted on.
- The subscription-health alert waits for at least 10 subscriptions.
- If more than 100 events land in a window, the check reports that it could not count them all rather than a short total.
Connect a Resend API key and Beaam watches each sending domain's bounce and complaint rates — and tells you the moment a domain stops being able to send.
- How you connect
- Sign in with Resend — no key to create. Beaam watches every sending domain's bounce and complaint rates.
- What raises an incident
- Domain can send · Bounce rate · Complaint rate · Failed email
- What connecting needs
- Resend offers two kinds of access, full and sending-only, and reading domains needs full access. So sign-in requests
full_access, and an API key must be Full access — a grant that could send mail as your domain. Beaam never sends mail. - One Resend account per organization.
- Where Resend's metrics endpoint is not available on your account, Beaam falls back to the sent-mail list, capped at 2,000 messages.
- What Beaam will not tell you
- No rates on days with no mail. A bounce-rate alert waits for 25 sends, a complaint-rate alert for 1,250 deliveries.
- Opens and clicks are not alerted on.
- Resend's webhook events never stand in for liveness: a quiet webhook is not read as healthy.
- Resend publishes no change events, so there is nothing to correlate an incident against.
- The one thing it creates in your account
- Connecting creates one webhook in your Resend account, pointed at Beaam, so bounces and complaints arrive as they happen. A failed connect removes it again. Disconnecting does not remove it yet — delete it from Resend's Webhooks page.
Connect with an auth token and Beaam watches each selected Sentry project and environment for sustained error volume and ingestion loss.
- How you connect
- Sign in with Sentry and approve read-only access — no token to create. Then choose the projects worth watching; a read-scoped auth token still works instead.
- What raises an incident
- Error volume · Rate-limited events · Invalid events · Incident signals · Trace failures
- What connecting needs
- Sign in with Sentry:
org:read, project:read and event:read. - Auth token instead:
project:read and org:read; add event:read to get new and regressed issue alerts. - Self-hosted Sentry: token only, and the instance must be reachable from the public internet.
- What Beaam will not tell you
- Thresholds are fixed rules, not spike detection, and count the error event category only.
- Crash-free rate alerts need at least 50 sessions in the hour; span-failure alerts need at least 10 spans.
- Sentry's ingestion outcomes cannot be filtered by environment, so dropped-event counts cover the whole project.
- A project with no environment cannot be monitored.
Connect a restricted key and Beaam watches payments, payouts, billing, fraud, account capability, and webhook delivery.
- How you connect
- Connect an rk_live_ restricted key with Account, Events, and Webhook Endpoints read access.
- What raises an incident
- Payment availability · Money movement and billing · Webhook delivery · Risk
- What connecting needs
- A restricted key (
rk_live_ or rk_test_) with read access to Account, Events and Webhook Endpoints. Unrestricted sk_ secret keys are refused. - There is no sign-in option for Stripe.
- What Beaam will not tell you
- Stripe Connect child accounts are not covered — only the account the key belongs to.
- The payment-failure-rate alert waits for at least 10 attempts in the window.
- Payment silence and disabled-webhook-endpoint alerts are off by default.
- Payouts, refunds and disputes are business signals, not proof that Stripe is down.
- Some Standard accounts omit their requirements list, and then past-due requirements cannot be reported.
Connect once and Beaam watches every selected Supabase project for core-service health, disk and connection pressure, backups, API errors, and replication.
- How you connect
- Sign in with Supabase and approve read-only access — no token to create. Beaam discovers your projects; an account access token still works instead.
- What raises an incident
- Core services · Capacity · Recovery · API reliability
- What connecting needs
- Sign in with Supabase: the permissions are fixed on Beaam's registered app rather than chosen at sign-in, and are read permissions.
- Access token instead: a personal access token (
sbp_). It is account-wide and carries your own permissions. - Disk utilisation is token-only: Supabase rejects that endpoint for sign-in grants.
- Free projects have no scheduled backups, so Beaam does not alert on backups there. Logs and some other endpoints are limited by plan.
- What Beaam will not tell you
- The 5xx-rate alert waits for at least 20 requests in the window.
- Supabase's Metrics API is in beta at Supabase.
- There is no history of restarts, resizes or restores to correlate against.
- Memory, latency and coverage alerts are off by default.
Connect Vercel and Beaam watches production deployment, project, domain, and runtime health without paging for preview-build noise.
- How you connect
- Sign in with Vercel and approve access — no token to create. Beaam finds every team it reaches and adds one runtime Log Drain; an access token still works instead.
- What raises an incident
- Production deployment · Project availability · Production domains · Runtime errors
- What connecting needs
- Sign in with Vercel: read access to user, teams, projects, deployments and domains, plus permission to create one runtime Log Drain.
- Access token instead, scoped to the personal account or team you want watched. The token path never creates a Log Drain.
- Runtime Log Drains depend on your Vercel plan. If yours does not support one, Beaam connects without it and says so.
- What Beaam will not tell you
- Preview deployment failures are charted but never alert.
- A deployment's state does not prove visitors get a response. Pair it with an HTTP check.
- The project-not-live alert is off by default, and the 5xx-rate alert waits for at least 20 requests.
- Vercel Cron jobs have no health signal of their own.
- A quiet Log Drain is not proof of health — it is never read as one.
- The one thing it creates in your account
- Signing in with Vercel creates one runtime Log Drain in your account, pointed at Beaam, so runtime errors arrive as they happen. A failed connect removes it again. Disconnecting does not remove it yet — delete it from your Vercel team's Log Drains settings.