Projects

Projects are the main way Errorgap organizes customer-facing observability data. A project usually represents one application, service, worker, or deployable unit that your team monitors and triages together.

What is a project?

A project contains the errors, logs, uptime checks, performance signals, infrastructure signals, integrations, and team access for one monitored part of your system. When an SDK or event source sends data with a project key, Errorgap routes that data into the matching project workspace.

Most day-to-day work starts from a project: reviewing new error groups, checking recent deploy context, investigating logs, opening incidents, and routing follow-up work to the right team.

What belongs in a project

A good project boundary should match how your team understands ownership and impact. If the same people deploy, monitor, and fix a service together, it probably belongs in one project.

• Use one project for one application or service with a shared owner.
• Keep unrelated services separate when their alerts should go to different teams.
• Use environments instead of separate projects for production, staging, and development.
• Keep project names stable so alerts and incidents stay easy to recognize over time.

Environments

Environments identify where an event happened. Common values include production, staging, and development. Errorgap uses environments for filtering, triage, and understanding whether a failure is customer-impacting.

Prefer a small, consistent set of environment names. If the same runtime sends both prod and production, your team may miss events while filtering.

Releases

Releases identify the application version, deploy, or commit that produced an event. When release values are present, Errorgap can help connect an error group to recent code changes and show whether a failure appeared after a deploy.

• Use a release value that your team can connect back to source control or deploy notes.
• Keep release values consistent across SDK setup, deploy tracking, and incident review.
• Update the release value whenever a new version of the application is deployed.

Ownership and access

Project access should match the team that needs to monitor and triage the application. Members with access can review errors, inspect context, collaborate on incidents, and use project-level integrations.

Use teams when multiple people share ownership of the same project. That makes it easier to keep access current as people join, leave, or move between product areas.

Integrations

Project integrations connect Errorgap activity to the tools your team uses for response and follow-up work. Common project-level integrations include Slack notifications, GitHub or GitLab issue workflows, Jira tickets, and webhooks.

Configure integrations where the work happens. A checkout service, for example, should send alerts and issue links to the team that owns checkout, not to a broad channel where the signal will be ignored.

When to split projects

Split a project when the current boundary makes triage noisy or unclear. Separate projects are useful when different services have different owners, deploy schedules, alert channels, or incident response paths.

• Split projects when two services deploy independently and fail independently.
• Split projects when errors should page or notify different teams.
• Keep one project when a frontend and backend are always triaged by the same group.
• Avoid splitting by environment unless each environment is genuinely owned separately.