Projects

A project is one application you monitor. Errors, logs, traces, metrics and releases are all scoped to a project, and each project has its own keys.

When to create a separate projectlink

Create one project per deployable application, not per environment. Your staging and production builds should report into the same project and separate themselves with the environment field. That way an error you see in staging is recognised as the same issue when it reaches production.

• One project per app: web frontend, API, mobile app, worker.
• Environments (production, staging) are a field on each event, not a separate project.
• Quotas, members and alert rules apply per project.

Creating onelink

Dashboard, then Org, then BugWatch, then New project. Two things matter:

• Name - use the name your team already calls the application. It appears in alerts, issue titles and deployment records, so it should be recognisable at a glance in a notification.
• Environments - list the environments this application runs in, typically production and staging. Events tag themselves with an environment, which is what lets you filter issues and hold alerts to production only.

Creating the project does not start collecting anything. You still need to install an SDK and paste in the project key. See Install an SDK for servers and web, or Mobile for Android, iOS, React Native and Flutter.

Getting data inlink

A new project stays empty until an SDK sends its first event. The guided wizard in the dashboard generates a setup recipe for your exact language and framework, including the key to paste in. The same material, in full, is on the per-platform pages under Install an SDK and Mobile.