{"id":15118515,"url":"https://github.com/icoretech/airbroke","last_synced_at":"2026-04-05T01:06:03.195Z","repository":{"id":166591019,"uuid":"636736365","full_name":"icoretech/airbroke","owner":"icoretech","description":"🔥 Lightweight, Airbrake/Sentry-compatible, PostgreSQL-based Open Source Error Catcher","archived":false,"fork":false,"pushed_at":"2026-04-01T14:57:55.000Z","size":609175,"stargazers_count":214,"open_issues_count":4,"forks_count":11,"subscribers_count":4,"default_branch":"main","last_synced_at":"2026-04-02T02:39:35.123Z","etag":null,"topics":["airbrake","crash-reporting","crash-reporting-tool","crash-reports","devops","error-handling","error-logging","error-monitoring","mcp-server","monitor","monitoring","nextjs","postgresql","sentry"],"latest_commit_sha":null,"homepage":"https://airbroke.icorete.ch","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/icoretech.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":"FUNDING.yml","license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":"AGENTS.md","dco":null,"cla":null},"funding":{"custom":["https://paypal.me/cpoli","http://revolut.me/kain"]}},"created_at":"2023-05-05T14:20:57.000Z","updated_at":"2026-04-01T14:57:50.000Z","dependencies_parsed_at":"2026-03-31T03:07:53.252Z","dependency_job_id":null,"html_url":"https://github.com/icoretech/airbroke","commit_stats":null,"previous_names":["icoretech/airbroke"],"tags_count":109,"template":false,"template_full_name":null,"purl":"pkg:github/icoretech/airbroke","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/icoretech%2Fairbroke","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/icoretech%2Fairbroke/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/icoretech%2Fairbroke/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/icoretech%2Fairbroke/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/icoretech","download_url":"https://codeload.github.com/icoretech/airbroke/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/icoretech%2Fairbroke/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":31420789,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-05T00:25:07.052Z","status":"ssl_error","status_checked_at":"2026-04-05T00:25:05.923Z","response_time":60,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.6:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["airbrake","crash-reporting","crash-reporting-tool","crash-reports","devops","error-handling","error-logging","error-monitoring","mcp-server","monitor","monitoring","nextjs","postgresql","sentry"],"created_at":"2024-09-26T01:46:18.696Z","updated_at":"2026-04-05T01:06:03.172Z","avatar_url":"https://github.com/icoretech.png","language":"TypeScript","readme":"\u003cp align=\"center\"\u003e\n  \u003cimg src=\"public/logo-full.png\" height=\"400\"\u003e\n  \u003ch1 align=\"center\"\u003eOpen Source Error Catcher\u003c/h1\u003e\n\u003c/p\u003e\n\n\u003cp align=\"center\"\u003e\n  \u003ca aria-label=\"Build Status\" href=\"https://github.com/icoretech/airbroke/actions/workflows/build.yml\"\u003e\n    \u003cimg alt=\"\" src=\"https://img.shields.io/github/actions/workflow/status/icoretech/airbroke/build.yml?style=for-the-badge\"\u003e\n  \u003c/a\u003e\n  \u003ca href=\"https://github.com/icoretech/airbroke/blob/main/LICENSE\"\u003e\n    \u003cimg alt=\"License\" src=\"https://img.shields.io/github/license/icoretech/airbroke?style=for-the-badge\" /\u003e\n  \u003c/a\u003e\n  \u003ca href=\"https://github.com/icoretech/airbroke/blob/main/package.json\"\u003e\n    \u003cimg alt=\"Version\" src=\"https://img.shields.io/github/package-json/v/icoretech/airbroke?style=for-the-badge\" /\u003e\n  \u003c/a\u003e\n\u003c/p\u003e\n\n\u003cdiv align=\"center\"\u003e\n  \u003cimg src=\"public/aidemo.gif\" alt=\"Demo\" width=\"600\" /\u003e\n\u003c/div\u003e\n\n## Features\n\n\u003e Airbroke is currently in active development! Using it in production environments is at your own discretion. We appreciate your feedback and support as we work towards a stable release.\n\n- :floppy_disk: Based on PostgreSQL\n- :globe_with_meridians: Airbrake(tm)/Sentry(tm)-compatible HTTP collector endpoints\n- :computer: Modern, React-based frontend for error management\n- :rocket: Designed with simplicity at its core\n- :wrench: Maintains small database footprint even under heavy data ingestion\n- :robot: Ask AI about issues\n- :clipboard: Provide cURL command to reproduce HTTP exceptions\n- :arrow_forward: Replay HTTP exceptions\n- :key: Supports multiple OAuth providers for secure user authentication\n- :bar_chart: Occurrence charts\n- :bookmark: Save and manage bookmarks for important occurrences\n- :electric_plug: MCP API for LLM/agent integrations\n\n## System Requirements\n\n- Node.js 22/24+ compatible environment\n- Minimum of 300MB RAM\n- At least 1000 millicores, equivalent to 1 CPU core\n- PostgreSQL 15+ database\n- 8+ free database connections slots per instance\n\n## Deployment Options\n\nAirbroke provides flexibility in deployment options. You can either deploy it from the built source code or use a multiarch Docker image. For Kubernetes deployments, a Helm chart is provided. As Airbroke is a Next.js 16 application, it can be deployed wherever a Node.js server is supported. This includes managed environments such as Vercel, Netlify, and Heroku.\n\n### Build from source\n\nFor a production build, you can run:\n\n```sh\ncp .env.dist .env\n```\n\nThen edit the `.env` file to set your own values.\n\n```sh\nyarn install\nyarn build\n```\n\nThis will generate a `.next` build output. Because this repo uses `output: \"standalone\"`, the runnable server output is in `.next/standalone` (see the `Dockerfile` for a working copy strategy / asset layout).\n\nYou can also run `yarn start` to test the production build locally on port `3000`.\n\n### Docker\n\nWe publish images for both `amd64` and `arm64` architectures on [ghcr.io](https://github.com/icoretech/airbroke/pkgs/container/airbroke) but in case you want to build your own image you can do so.\n\nYou can build the Docker image with:\n\n```sh\ndocker build --no-cache -t icoretech/airbroke:latest .\n```\n\nYou can then run the image locally with:\n\n```sh\ndocker run -p 3000:3000 icoretech/airbroke:latest\n```\n\n### Vercel\n\n[![Deploy with Vercel](https://vercel.com/button)](https://vercel.com/new/clone?repository-url=https%3A%2F%2Fgithub.com%2Ficoretech%2Fairbroke\u0026project-name=airbroke\u0026repository-name=airbroke\u0026env=DATABASE_URL%2CDIRECT_URL%2CBETTER_AUTH_SECRET%2CAIRBROKE_CORS_ORIGINS\u0026envDescription=Required+env+vars+for+Airbroke+%28Prisma+%2B+Better+Auth%29.+Generate+a+random+BETTER_AUTH_SECRET.+Set+AIRBROKE_CORS_ORIGINS+to+your+app+origin%28s%29.\u0026envLink=https%3A%2F%2Fgithub.com%2Ficoretech%2Fairbroke%2Fblob%2Fmain%2F.env.dist\u0026envDefaults=%7B%22AIRBROKE_CORS_ORIGINS%22%3A%22*%22%7D\u0026build-command=if+%5B+%22%24VERCEL_ENV%22+%3D+%22production%22+%5D%3B+then+corepack+yarn+db%3Amigrate%3B+fi+%26%26+corepack+yarn+build)\n\nWhile [testing on Vercel](https://nextjs.org/docs/app/getting-started/deploying) has not been conducted, Airbroke should be fully compatible.\n\nIt's important to keep the following points in mind:\n\n- For optimal performance, ensure your database is located in the same region.\n- The endpoints under `/api/*` will be converted into serverless functions, which may introduce potential cold boot time.\n- If you connect directly to Postgres, use a pooler (or Prisma Accelerate / Data Proxy) to avoid exhausting DB connections.\n- Migrations must be executed as part of deployment. The Deploy Button above sets a `build-command` that runs DB migrations only for `VERCEL_ENV=production` before building (adjust this in your Vercel project settings if you need a different workflow).\n- The Deploy Button defaults `AIRBROKE_CORS_ORIGINS` to `*` for quick starts. After your first deploy, set it to your deployed origin (for example `https://\u003cproject\u003e.vercel.app`) and any custom domains.\n\nDetailed instructions for this process can also be found in the [Prisma deployment guide for Vercel](https://www.prisma.io/docs/orm/prisma-client/deployment/serverless/deploy-to-vercel).\n\n### Render.com\n\n[![Deploy with Render](https://render.com/images/deploy-to-render-button.svg)](https://render.com/deploy?repo=https://github.com/icoretech/airbroke)\n\nThe Render Deploy Button uses `render.yaml` (Render Blueprint). On the free tier, the template runs `yarn db:migrate` at boot (safe no-op if already applied). Airbroke allows all origins if `AIRBROKE_CORS_ORIGINS` is unset — once Render assigns your public URL, lock it down in the Render dashboard for production (this controls CORS for `/api/v3/notices` and `/api/sentry/*/envelope`).\n\n### Railway\n\nRailway supports one-click deployments via **Templates**. Because templates are created and published from within Railway, you’ll need to create a template once and then wire up the button URL.\n\n[![Deploy on Railway](https://railway.com/button.svg)](https://railway.com/new/template/REPLACE_ME?utm_medium=integration\u0026utm_source=button\u0026utm_campaign=airbroke)\n\nSteps:\n\n- Create a Railway project from this repo (GitHub deploy).\n- Add a PostgreSQL database in Railway.\n- Set required environment variables (Railway can suggest vars from `.env.dist`).\n- Publish the project as a Template and replace `REPLACE_ME` above with the template ID.\n\n### Netlify\n\n[![Deploy to Netlify](https://www.netlify.com/img/deploy/button.svg)](https://app.netlify.com/start/deploy?repository=https://github.com/icoretech/airbroke)\n\nThe Deploy to Netlify button is configured via `netlify.toml`. The build command runs DB migrations only for production deploys.\n\nBecause you don't know your final `*.netlify.app` URL before the first deploy, you can start with `AIRBROKE_CORS_ORIGINS=*` and then tighten it to your deployed origin (for example `https://\u003csite\u003e.netlify.app`) and any custom domains.\n\n### Heroku\n\n[![Deploy to Heroku](https://www.herokucdn.com/deploy/button.svg)](https://www.heroku.com/deploy?template=https://github.com/icoretech/airbroke)\n\nThe Deploy to Heroku button uses `app.json` to provision add-ons and prompt for required environment variables.\n\nBecause you don't know your final `*.herokuapp.com` URL before the app is created, you can start with `AIRBROKE_CORS_ORIGINS=*` and then tighten it to your deployed origin (for example `https://\u003capp\u003e.herokuapp.com`) and any custom domains.\n\n### Helm\n\nYou can deploy Airbroke to Kubernetes using the dedicated Helm chart.\n\nThe Helm chart includes a `values.yaml` file with some default values that you can override with your own. It also includes a pgBouncer chart as optional dependency.\n\nWhen using Helm we recommend using a GitOps approach to deploy your application(s), such as [Flux](https://fluxcd.io/).\n\nPlease find more information about the Helm chart in the dedicated repository: [icoretech/charts](https://github.com/icoretech/helm/tree/main/charts/airbroke)\n\n### Docker Compose\n\nFor users who prefer Docker Compose for managing multi-container Docker applications, a `docker-compose.yml` file is provided at the root of the repository.\n\nTo get started, make sure you have Docker and Docker Compose installed on your system. Then, you can start the application using the following command in the terminal:\n\n```sh\nmake build\nmake run\n```\n\nYou can override the default values in the `docker-compose.yml` file by creating a `docker-compose.override.yml` file in the same directory. This file is ignored by Git and will not be committed to the repository.\n\n## Setup\n\nPlease view all the available configuration variables in the [`.env.dist`](https://github.com/icoretech/airbroke/blob/main/.env.dist) file.\n\nAirbroke requires `DATABASE_URL` at runtime. `DIRECT_URL` is required when you need a *direct* database connection for migrations (for example, when `DATABASE_URL` goes through PgBouncer or a data proxy). Some examples:\n\n```sh\n# Example Connection to Prisma Data Proxy\nDATABASE_URL=\"prisma://__HOST__/?api_key=__KEY__\"\n# Example Connection to PostgreSQL\nDATABASE_URL=\"postgresql://__USER__:__PASSWORD__@__HOST__:__PORT__/__DATABASE__?connection_limit=20\u0026pool_timeout=10\u0026application_name=airbroke\"\n# Direct connection to the database, used for migrations\nDIRECT_URL=\"postgresql://__USER__:__PASSWORD__@__HOST__:__PORT__/__DATABASE__\"\n```\n\nThe optimal connection pool size without pgBouncer (`connection_limit`) can be calculated using the following formula:\n\n```ruby\nconnection_limit = (num_physical_cpus * 2 + 1) ÷ number_of_application_instances\n```\n\nFor a system with 8 CPU cores and 3 application instances, the calculation would proceed as follows:\n\n```ruby\nconnection_limit = (8 * 2 + 1) ÷ 3\nconnection_limit = (16 + 1) ÷ 3\nconnection_limit = 17 ÷ 3\nconnection_limit ≈ 5.67\n```\n\nSince `connection_limit` must be an integer, it should be rounded down to the nearest whole number. In this scenario, each of the 3 application instances should have a `connection_limit` of `5`.\n\nThis limit can be set in your connection strings.\n\nAfter deployment, you should be able to access your ingress (preferably secured with HTTPS) and start adding projects.\nThis process will generate an API key that you can use with your Airbrake-compatible clients.\nThis key, along with other essential information, will be provided to you.\n\n### About PgBouncer\n\nTo optimize your experience with Airbroke, as well as with Postgres overall, we advise integrating PgBouncer 1.24.0+ into your tech stack in transaction mode. For more comprehensive information, we recommend reviewing [Prisma's Connection Management documentation](https://www.prisma.io/docs/guides/performance-and-optimization/connection-management#external-connection-poolers), which provides insights on external connection poolers.\nWe recommend not setting `pgbouncer=true` in the database connection string if you're using **PgBouncer 1.21.0 or later** ([source](https://www.prisma.io/docs/orm/prisma-client/setup-and-configuration/databases-connections/pgbouncer)).\n\n### About DIRECT_URL\n\nThe `DIRECT_URL` environment variable should be configured to establish a direct connection to the database. This is particularly crucial when using PgBouncer, as it enables migrations that cannot be executed through a data proxy. You can find more detailed information about this subject in the [Prisma's guide on configuring pgBouncer](https://www.prisma.io/docs/orm/prisma-client/setup-and-configuration/databases-connections/pgbouncer).\n\n## Architecture\n\n### Frontend\n\nThe Airbroke frontend provides a user-friendly interface for managing and analyzing error reports. It utilizes a modern tech stack, including React, Tailwind CSS, and Next.js, to deliver a seamless user experience. The frontend leverages server-rendering capabilities to optimize initial page load times and ensure fast and responsive navigation.\n\nTo optimize performance, the frontend may implement caching strategies to reduce the number of database queries and enhance overall responsiveness. This ensures that you can efficiently navigate through error reports and analyze critical information without experiencing unnecessary delays.\n\n### Data Collection API\n\nThe Data Collection API is a core component of Airbroke responsible for handling the ingestion of error reports. It serves as the endpoint where clients can send error reports, enabling efficient data collection for error management.\n\nTo ensure simplicity and performance, the Data Collection API sidesteps the use of queue systems and performs parsing and transactions in-band. This means that parsing and processing of error reports happen synchronously within the API request cycle. Despite this approach, the Data Collection API demonstrates robust request-per-minute (RPM) performance even under high traffic volumes.\n\n### MCP API (LLM/Agent Integrations)\n\nAirbroke exposes an MCP-compatible JSON-RPC API for read-only error triage workflows:\n\n- `POST /api/mcp`\n\nAuthentication is static-header based (no OAuth in v1). Set `AIRBROKE_MCP_API_KEY` and send either:\n\n- `Authorization: Bearer \u003cAIRBROKE_MCP_API_KEY\u003e`\n- `X-Airbroke-Mcp-Key: \u003cAIRBROKE_MCP_API_KEY\u003e`\n\nOrigin policy for browser clients:\n\n- Optional `AIRBROKE_MCP_ALLOWED_ORIGINS` (comma-separated) explicitly allows specific `Origin` values.\n- If `AIRBROKE_MCP_ALLOWED_ORIGINS` is unset, Airbroke allows same-origin browser requests by default.\n- Non-browser clients that do not send an `Origin` header are unaffected by this check.\n\nAvailable tools:\n\n- `airbroke_list_projects`\n- `airbroke_get_project`\n- `airbroke_list_notices`\n- `airbroke_list_occurrences`\n- `airbroke_get_notice`\n- `airbroke_search`\n- `airbroke_get_occurrence`\n\nNotes on richer MCP outputs:\n\n- `airbroke_list_projects`, `airbroke_list_notices`, and `airbroke_list_occurrences`\n  support `offset` + `limit` for page-like iteration.\n- `airbroke_list_notices` supports `include_project=true` to embed minimal project data.\n- `airbroke_list_occurrences` is summary-first by default, and supports:\n  - `include_details=true` (+ optional `backtrace_frames`) for backtrace preview and key context fields.\n  - `include_notice=true` / `include_project=true` to embed parent notice/project context inline.\n- `airbroke_get_notice` returns:\n  - the notice payload\n  - `latest_occurrences` (by `updated_at desc`)\n  - `top_occurrences` (by `seen_count desc`, then `updated_at desc`)\n  - optional occurrence detail snippets for faster LLM triage.\n- `airbroke_search` supports cross-project query by occurrence message + notice/project metadata\n  with optional filters: `organization`, `project_id`, `env`, `include_resolved`,\n  and rich snippets via `include_details` + `backtrace_frames`.\n\nExample Codex MCP server config:\n\n```toml\n[mcp_servers.airbroke]\nurl = \"https://myairbroke.xyz/api/mcp\"\n\n[mcp_servers.airbroke.http_headers]\nX-Airbroke-Mcp-Key = \"replace-me\"\n```\n\n## Authentication Layer\n\nAirbroke includes an authentication layer that allows you to secure access to the application by enabling user authentication. It supports various authentication providers, including:\n\n- GitHub\n- Atlassian\n- Auth0\n- Google\n- Apple\n- Authentik\n- Bitbucket\n- BoxyHQ SAML\n- Cognito\n- FusionAuth\n- GitLab\n- Keycloak\n- Microsoft Entra ID\n- Salesforce\n- Slack\n- Okta\n\nTo configure the authentication layer, you need to set the necessary environment variables corresponding to the authentication providers you want to use. These environment variables typically include client IDs, client secrets, and other provider-specific configuration details. Make sure to keep these environment variables secure, as they contain sensitive information.\n\nTo complete the configuration, you also need to set the callback path in your OAuth applications for each provider. The callback path should be set to `https://\u003cmyhostname\u003e/api/auth/callback/\u003cprovider\u003e`. This path is where the authentication provider will redirect the user after successful authentication.\n\nYou can find a list of available authentication providers and their documentation on the [Better Auth documentation](https://www.better-auth.com/docs/concepts/oauth). Each provider has its own specific configuration requirements and authentication flow, so refer to their documentation for more details.\n\nTo configure the authentication providers, you'll need to set specific environment variables. You can find the list of required environment variables and their descriptions in the [`.env.dist`](https://github.com/icoretech/airbroke/blob/main/.env.dist) file in the Airbroke repository.\n\nTo enable authentication in Airbroke and allow users to authenticate using third-party providers, follow these steps:\n\n1. Configure the necessary environment variables for the desired authentication providers. You can refer to the [`.env.dist`](https://github.com/icoretech/airbroke/blob/main/.env.dist) file in the Airbroke repository for a list of required environment variables and their descriptions. Copy this file as `.env` and fill in the necessary values for your authentication providers.\n\n2. Create OAuth applications with the respective authentication providers. Each provider will have its own developer console or settings page where you can create an OAuth application. During the application setup, configure the callback url to match the Airbroke authentication callback path: `https://myairbroke.xyz/api/auth/callback/\u003cprovider\u003e`. Save the settings.\n\n3. Start the Airbroke application, ensuring that the environment variables are properly configured.\n\n4. Users can now authenticate with Airbroke by clicking on the login button and selecting their desired authentication provider. They will be redirected to the provider's authentication page to enter their credentials. Upon successful authentication, users will be logged in to Airbroke.\n\nNote: The callback path in step 2 is essential for the authentication flow to work correctly. It ensures that the authentication provider can redirect the user back to the Airbroke application after authentication is complete.\n\nPlease refer to the documentation of the respective authentication providers to obtain the necessary configuration details and understand their authentication flows.\n\n## Best Practices for Efficient Error Collection and Storage\n\nAirbroke provides error grouping mechanisms that analyze the incoming error data and automatically group similar errors based on their attributes.\n\nHowever when working with exceptions that include dynamic information as part of the exception itself (e.g., `raise(NotFound, 'no record 1234')`), it is important to consider efficient error collection and storage strategies. By following these practices, you can ensure that Airbroke maintains an efficient database and effectively groups and displays related errors without much overhead.\n\n### Strategy 1: Use Generic Error Messages and Provide Detailed Reporting in `params`\n\nIf the exceptions are generated within your own code, consider using more generic error messages and providing detailed reporting using the `params` field. Here's an example:\n\n```ruby\nbegin\n  data = { book_id: 22 }\n  raise 'ugh' # no dynamic data\nrescue =\u003e e\n  Airbrake.notify(e, data) # ugh happened on book_id 22\nend\n```\n\n### Strategy 2: Collect and Wrap Exceptions Produced by Libraries\n\nIf the exceptions are produced by libraries, consider collecting the necessary information, wrapping the exceptions, and re-raising them with cleaned-up messages. This approach allows you to provide more meaningful and informative error messages to Airbroke. Here's an example:\n\n```ruby\nbegin\n  # Your code that interacts with a library\nrescue SomeLibraryError =\u003e e\n  # Collect necessary information\n  error_data = { library_error_message: e.message, library_error_code: e.code }\n\n  # Wrap and re-raise the exception with a cleaned-up message\n  wrapped_exception = RuntimeError.new(\"An error occurred in the library.\")\n  Airbrake.notify(wrapped_exception, error_data)\n  raise wrapped_exception\nend\n```\n\nBy wrapping the library exception with a customized error message and including the relevant information in the `params` field, you can ensure that Airbroke receives clean and consistent error messages while retaining the necessary context.\n\nBy adopting these best practices, you can enhance the efficiency and effectiveness of error collection and storage in Airbroke. These strategies allow for better grouping and analysis of related errors, providing you with the insights needed to identify and address issues more effectively.\n\n### Limitations\n\nWhen working with error collection in Airbroke, you may come across situations where you find an error occurrence with a high count, but upon opening it, you discover that it only has one document to consult. This happens because Airbroke groups errors based on their \"kind\" and \"message\". If any of these attributes differ, Airbroke will create a new error group.\n\nAs a result, you may encounter repeated errors that don't expose the specific parameter or stack trace after the first occurrence, or they may have originated from a different part of the application. This tradeoff is made to ensure a compact database size and high performance. The underlying idea is to encourage you to address and resolve errors, so maintaining a clean and organized error slate will yield better insights and improvements over time.\n\nBy understanding these limitations and keeping your error collection streamlined, you can effectively utilize Airbroke's features to identify and resolve issues in your application.\n","funding_links":["https://paypal.me/cpoli","http://revolut.me/kain"],"categories":["TypeScript"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ficoretech%2Fairbroke","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ficoretech%2Fairbroke","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ficoretech%2Fairbroke/lists"}