Raw detail for 30 days,your history for as long as you stay.
What Beaam keeps, how long it keeps it, and exactly what disconnecting an integration or deleting your account removes.
The short version
| Data | Kept for | How it goes |
|---|---|---|
| Raw metric samples Beaam collects from your integrations | 30 days | A scheduled sweep deletes anything older, every minute |
| Raw OpenTelemetry metrics you send to Beaam | 30 days | Expire automatically in the telemetry store |
| Change events read from your providers — deploys, scaling, config changes | 30 days | The same sweep |
| Events a provider pushes to Beaam — Resend's webhook, Vercel's log drain | 30 days | The same sweep |
| Hourly health summary for each watched service | While your account is open | Removed with the service, the integration or the account |
| Incidents, alerts and delivery records | While your account is open | Removed with the integration or the account |
| Encrypted integration credentials | Until you disconnect | Deleted immediately on disconnect |
The privacy policy is the binding version of these commitments. This page explains them in more detail and does not extend them.
Raw samples expire after 30 days
Every individual measurement — an error rate at 14:02, a response time, a queue depth — is a raw sample, and Beaam keeps raw samples for 30 days. That holds whichever way a metric arrives. Metrics Beaam collects from a connected integration are stored in Beaam's database and removed by a sweep that runs every minute and deletes anything older than the window. Metrics you send over OTLP are stored in a separate telemetry store, which expires each sample 30 days after its own timestamp.
The two stores are held to the same number on purpose, and a test fails if they ever disagree. A promise that only held for one way of sending data would not be much of a promise.
The same 30 days covers the supporting evidence Beaam keeps beside your metrics: the change events it reads from your providers to explain an incident ("a deploy landed two minutes before errors rose"), and the delivery and runtime events Resend and Vercel push to Beaam. The Vercel events are stored with the message, path, host, IP address and headers already stripped out.
Expiry never empties a view you can still open: nothing in Beaam reads raw samples from further back than 30 days.
There is no archive behind the window. Beaam does not move old samples to cheaper cold storage, so after 30 days the raw detail is gone, not relocated.
What outlives the window
Two things, both kept for as long as your account is open, because they are what you come back to after something goes wrong.
Incidents and alert history. Every incident, every alert Beaam sent about it, and whether each one was delivered. None of this is on a timer — it is the record of what happened to your stack, and it would be odd to lose it the month after an outage.
An hourly health summary for each watched service. It records how many checks ran in that hour and the worst state seen — "30 checks, all quiet". It holds none of the underlying measurements, no request or response contents, and nothing read from your providers. It exists so that a service's history does not stop a month ago: the detail behind any hour is gone after 30 days, but the shape of that hour remains.
Credentials
API keys and tokens for the services you connect are encrypted with AES-256-GCM before they are stored. The key is held as a secret in Beaam's server environment and is never exposed to browser code. Credentials are never logged or transmitted in plaintext.
They live on the connection itself, so they go when the connection goes. There is no separate copy to clean up.
Disconnecting an integration
Disconnecting is permanent and removes the connection and everything attached to it, straight away:
- the encrypted credentials, including any OAuth tokens;
- every service discovered under that connection, watched or not;
- their raw samples, hourly summaries, incidents and alerts.
Some connections create something in your provider account so events can reach Beaam — a webhook in Resend, a log drain in Vercel. Before the connection is removed, Beaam deletes those too. If the provider refuses, the disconnect still goes ahead — a provider's API is not a reason to keep you connected — and Beaam tells you exactly what was left behind, so you can delete it by hand.
Disconnecting removes Beaam's copy of your credentials. It does not revoke them at the provider. If you created an API token for Beaam, delete it in that provider's settings; if you connected with OAuth, you can revoke Beaam's access in the provider's list of authorized applications.
Settings also has Remove all integrations and monitoring data, which deletes every integration you connected and everything they produced, and leaves your account and notification channels in place. It runs the same provider-side cleanup first, and tells you anything it could not remove.
Deleting your account
You can delete your account from Settings, under the danger zone. It asks for your current password and for you to typeDELETE MY ACCOUNT. It is deliberately not available to anassistant over MCP.
If you are on Solo, your subscription is cancelled first. If Beaam cannot cancel it, nothing is deleted and you are told why, so an account can never be left billing with nothing behind it. Then, immediately:
- your sign-in identity and profile are deleted, and existing sessions stop working;
- organizations where you are the only member are deleted with everything in them;
- integrations you connected, their credentials, services, incidents, alerts and hourly summaries are deleted;
- your notification channels are deleted.
A shared organization stays for its other members. If you are its only owner, deletion is refused until you transfer ownership, so a team is never left with an organization nobody can manage. Integrations are tied to the person who connected them, so the ones you connected inside a shared organization are deleted with your account — if your team still needs them, have someone else reconnect them first. Deleting an account runs the same provider-side cleanup as a disconnect, and anything a provider would not let Beaam remove is listed in the confirmation email, since by then you are signed out.
A few things do not disappear on the spot:
- OpenTelemetry metrics you sent stay in the telemetry store until they expire, within 30 days. That store has no per-account delete, so the expiry is the deletion.
- If a phone number of yours replied STOP (or START) to one of Beaam's texts, Beaam keeps that number and the reply, and uses them only to make sure a number that opted out is never texted again, including from a new account.
- Database backups can contain deleted rows until those backups expire, currently on a seven-day window. Backups are not used to restore an individual deleted account.
- Beaam's email, SMS and billing processors keep delivery and financial records under their own retention schedules, and Polar, as merchant of record, keeps what tax law requires. The subprocessors page lists each one.
You can also ask for your data to be accessed, corrected or deleted by emailing support@beaam.app.
Beaam's own logs
Beaam runs on Cloudflare, which keeps request and diagnostic logs under Beaam's plan. They are for operating the service, not a store of your history, and they age out on Cloudflare's schedule. Credentials are never written to them.
Questions
Can I keep raw samples for longer than 30 days?
No. The window is the same on every plan and is not configurable. Beaam is built to tell you when something is wrong, not to be a long-term metrics archive, and every view in the product that reads raw samples looks back 30 days or less. The hourly health summary is what carries a service's history past that point.
Will I lose my incident history after 30 days?
No. Incidents and the alerts sent about them are not on any timer. They stay while your account is open, and are removed only when you delete the integration they belong to, remove all monitoring data, or delete your account.
Does disconnecting an integration delete its history?
Yes. Disconnecting removes the connection and everything that hangs off it: its watched services, their raw samples, hourly summaries, incidents and alerts, and the stored credentials. If you want the history, look at it before you disconnect — there is no undo.
Does Beaam store OpenTelemetry traces or logs?
No. The OTLP endpoint stores metrics only. Requests to the traces and logs endpoints are refused with an explicit error rather than accepted and dropped, so nothing from them is kept.
If I downgrade from Solo, is anything deleted?
No. Organizations, integrations and watched services you already have keep working, and their history stays. The plan limits apply to creating more. Raw samples expire after 30 days on both plans either way.