Projects
A project is one stream of events with its own ingest keys, its own destinations and its own rules. One service, one project, is the shape that fits most teams. A monolith with three noisy subsystems is a fine reason to use three.
How an event lands in one
Section titled “How an event lands in one”The project an event belongs to is decided by the key it was posted with, not by the name in the payload. ProducerOptions.ProjectName is a label: it groups the batch inside a message, it is stored on the event, and it is what a rule can filter on. An event that arrives with no project name gets the project’s own name.
That separation is deliberate. A key belongs to one project, so a leaked or misconfigured sender cannot write into another project by changing a string.
What a project carries
Section titled “What a project carries”| Setting | What it does |
|---|---|
| Name | Shown in the console and used as the default project name on events that arrive without one |
| Time zone | The IANA zone capture times are rendered in, for this project’s alerts |
| Keep debug events | Off drops Debug events at ingest. On stores them like any other |
| Retention | Fixed by the plan, not per project. See Limits |
Debug events count against the monthly event allowance when the project keeps them. Turning the switch off is how a service can leave Debug calls in the code and its cloud project.
Archiving
Section titled “Archiving”Archiving a project stops ingest on its keys and leaves the events readable until retention removes them. It is the reversible half of deleting, which removes the events on the spot.
How many
Section titled “How many”The plan sets the number of projects an account may have: two on Free, more above it. The table is on Limits and on the pricing page.
Next: ingest keys.