Create your first project
Create a project for the application or service you want to monitor, then capture the project details your team will use during SDK setup and triage.
A project is the main workspace for one monitored application, service, or deployable unit. It holds the events, error groups, integrations, team access, and settings for that part of your system.
Before you start
Decide what the project should represent before you create it. Most teams get the clearest triage experience by creating one project per application or service that ships and fails independently.
- Create separate projects for separate services when different teams own them or they deploy independently.
- Use environments to separate production, staging, review apps, and other runtime targets inside the same project.
- Keep related frontend and backend services separate if their releases, owners, and error queues need different triage paths.
Create the project
- Open Errorgap and go to the project list.
- Select New project.
- Enter the project name your team will recognize in alerts and dashboards.
- Pick the stack (or stacks) the project runs on — a project can monitor several, such as a Rails API plus a browser frontend. The first pick becomes the primary stack. You can also skip this and choose during setup.
- Confirm the project details and create it.
After the project is created, Errorgap shows an empty project workspace. The project will begin showing error groups and activity after an SDK or event source sends data.
Choose a project name
A useful project name is short, specific, and stable. It should match the name people use in incidents, deploy notes, and team discussions.
- Use Checkout API instead of a generic name like Backend.
- Use Marketing Site instead of a repository name that only engineers know.
- Avoid including the environment in the project name unless each environment is truly a separate application.
Review project settings
Project settings contain the customer-visible details needed to connect your application and route work to the right people. Review these before installing an SDK.
- Project key identifies where SDK events should be sent.
- Environments let you filter production and non-production activity.
- Team access controls who can view, triage, and manage the project.
- Integrations connect project activity to tools such as Slack, GitHub, GitLab, Jira, and webhooks.
Next steps
Once the project exists, install the SDK for your application runtime and send a test error. That confirms the project key is configured correctly and gives your team a real error group to inspect before production traffic depends on the setup.
Before production rollout, review general project settings, project integrations, redaction rules,agent access, andsession replay settings.