Docs > Platform Observability > Getting Started with Ingest Keys
Getting Started with Ingest Keys
Overview
This guide introduces AppStatus Ingest Keys and covers:
- One key per signal: APM, errors, logs, RUM, serverless, cost, pipelines
- Separate keys per environment
- Shown once at creation — store it in your secret manager
- Rotate without downtime, revoke instantly
- Per-key rate limits and plan quota
What are Ingest Keys in AppStatus?
An ingest key authorises one workspace to send one kind of telemetry. Keys are deliberately narrow: a key that leaks from a browser bundle cannot be used to write logs, and no ingest key can read anything back out.
That scoping is what makes the RUM key safe to ship in your page source. It is public by design, and the only thing it can do is send browser telemetry to your workspace.
Key capabilities:
- Scope per signal so one leak does not become full access
- Separate keys per environment for safe revocation
- Rotation flow: create, deploy, then revoke the old key
- Immediate revocation — a revoked key stops accepting data at once
- Per-key rate limits with plan quota enforcement
What you will see
What the key list looks like
Scroll the table sideways to see every column.
The key value is shown once, at creation. After that only its name, scope and usage are visible.
Troubleshooting
Ingest stopped suddenly
Check the key rate limit and your plan quota before debugging the SDK. A key over its limit is rejected at the edge, which looks identical to a broken integration from the application side.
Data is accepted but never appears
The key scope probably does not match the signal being sent — logs sent with an APM-scoped key, for example. Create a key with the correct scope and redeploy.
A key was committed to a repository
Revoke it immediately, then create a replacement. Revocation takes effect at once. Rotate by creating the new key and deploying before revoking, so ingest never gaps.
Operational Guidance
- The RUM key ships in your page source and is public by design — that is why scopes exist.
- Revoke immediately on suspicion; a revoked key stops accepting data at once.
- If ingest suddenly stops, check the key rate limit and plan quota before debugging the SDK.
Step-by-Step Setup
Keys are quick to create and worth a minute of thought about scope. One key per signal per environment is the pattern that keeps a leak small and a revocation safe.
Before you start
- Permission to manage keys in your workspace
- A secret manager to store them in
- 1
Create one key per signal
Create a separate key for each signal you send — APM, errors, logs, RUM, serverless, cost, pipelines — and a separate set per environment.
WhereIngest Keys → Create keyTipReusing one key across signals turns a single leak into full ingest access. The scoping only helps if you use it.
- 2
Copy the value at creation
The key value is shown once and never again. Copy it straight into your secret manager — not into a config file, a ticket, or a chat message.
WhereIngest Keys → Create key → Copy - 3
Reference it from configuration
Point your application at the secret rather than embedding the value. The RUM key is the deliberate exception: it ships in your page source, because its scope lets it do nothing else.
WhereYour application configuration - 4
Set a rotation reminder
Decide the rotation schedule before you ship, not after. Rotation is create new, deploy, then revoke old — done in that order, ingest never gaps.
WhereIngest Keys → key detail
Configuration Options
Every option you can set, what each choice means, and what to pick. Use this as a reference while you fill in the form.
Key settings
| Field | Options | What it does | Recommended |
|---|---|---|---|
| Scope | apm, errors, logs, rum, serverless, cost, pipelines | Which signal the key may send. | One scope per key. Never reuse across signals. |
| Environment | production, staging, custom | Separates keys so revocation is safe. | Always separate production from everything else. |
| Rate limit | Per key | Ceiling on ingest for this key. | Plan default unless you expect a burst. |
| Revocation | Immediate | Stops the key accepting data. | Revoke on suspicion. It takes effect at once. |
Feature Reference
Every feature, where to find it in the app, and what it does. Use this when you know what you want to do but not where it lives.
| Feature | Where in app | Description |
|---|---|---|
| Scoped keys | Ingest Keys | One signal per key, so a leak stays small. |
| Usage visibility | Ingest Keys | Last-used time per key, useful for finding stale ones. |
| Rate limits | Key detail | Per-key ceiling with plan quota enforcement. |
| Immediate revocation | Key detail → Revoke | Stops accepting data at once, no propagation delay. |
Next Steps
Continue building your monitoring stack:
