# error reporting Published articles for error reporting. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Behind the scenes: debugging a pool join failure DevFeed: [Behind the scenes: debugging a pool join failure]() Original publisher: [Read original article]() Author: Marc Pezin Published: 2026-07-20T09:48:38Z Content type: article Language: en Sources: [XCP-ng Blog]() Topics: [debugging](), [TLS (Transport Layer Security)](), [DevOps](), [Server]() Tags: [analysis](), [contribution](), [debugging](), [devblog](), [error-reporting](), [ntp](), [root-cause-analysis](), [tls]() ### AI overview This article follows the investigation of an XCP-ng pool join failure after an upgrade from version 8.2 to 8.3. The debugging process reproduced the issue, ruled out common TLS causes, identified the root cause, and resulted in an upstream contribution that improved error reporting. ### Source excerpt A user reported a pool join failure after upgrading to XCP-ng 8.3. What started as a forum discussion led to a root-cause analysis, an upstream contribution, and a better error message for everyone. ## Next.js error handling: a practical guide DevFeed: [Next.js error handling: a practical guide]() Original publisher: [Read original article]() Author: Farhan Hasin Chowdhury Published: 2026-06-18T07:00:00Z Content type: tutorial Language: en Sources: [Honeybadger]() Topics: [Next.js](), [API](), [bug](), [React]() Tags: [api](), [authentication](), [error-handling](), [error-reporting](), [guide](), [javascript](), [javascript-articles](), [next-js](), [nextjs]() ### AI overview A practical guide to handling expected and unexpected errors in Next.js applications using the App Router. It covers return-value-based handling for expected errors, Server Actions, Server Components, 404 responses, error boundaries, and Honeybadger-based production error reporting. ### Source excerpt Next.js gives developers a structured way to handle errors at every level of an application -- from form validation to root-level crashes. Learn how to manage expected errors with return values, catch uncaught exceptions with error boundaries, and set up automatic error reporting in production. ## Command -- Response Framework in ESP RainMaker DevFeed: [Command -- Response Framework in ESP RainMaker]() Original publisher: [Read original article]() Author: John Lee Published: 2024-07-31T00:00:00Z Content type: release Language: en Sources: [Blog on Developer Portal]() Topics: [Esp Rainmaker](), [Access Control](), [Cloud](), [payload]() Tags: [access-control](), [blog](), [cloud](), [commands](), [error-reporting](), [esp-rainmaker](), [esp32](), [espressif](), [iot](), [offline](), [payload](), [rainmaker]() ### AI overview ESP RainMaker introduces a command-response framework that lets admins and end users communicate with nodes through the cloud. Requests receive IDs for status tracking, can be delivered when nodes come online, and provide explicit firmware error reporting. ### Source excerpt [If you have been following the Espressif blogs and announcements, you must already be aware of ESP RainMaker and its various features. If not, please check out the info here so that you get an idea about what ESP RainMaker is before you proceed further.] Admin users in ESP RainMaker can look at some basic node data like type, model, firmware version, etc. and push OTA firmware upgrades. They can view additional diagnostics data if linked with ESP Insights. ## Doctave Studio 2024 Refresh DevFeed: [Doctave Studio 2024 Refresh]() Original publisher: [Read original article]() Author: Niklas Begley Published: 2024-04-08T07:00:00Z Content type: release Language: en Sources: [Doctave - Build beautiful developer portals with docs-as-code]() Topics: [Documentation](), [App](), [screen](), [CSS](), [HTML](), [Chrome](), [debugging]() Tags: [announce](), [app](), [blog](), [chrome](), [css](), [debug](), [desktop](), [documentation](), [error-reporting](), [html](), [improvements](), [layout]() ### AI overview Doctave announces a 2024 refresh of Doctave Studio, its desktop app for previewing documentation locally. The update introduces a narrower vertical layout, a browser-viewing option for inspecting HTML and CSS with Chrome DevTools, and an improved Issues Tab for reviewing documentation problems. ### Source excerpt We're excited to announce our biggest update to Doctave Studio yet! This refresh brings a whole new look and feel, and adds some of our most requested improvements, making the editing experience more seamless than ever before. Let's dive in! The new and improved Doctave Studio! What is Doctave Studio? Doctave Studio is our desktop app customers use to preview their apps locally. It bundles the whole development environment and gives a perfect reconstruction of what your documentation will look like once published. Most authors will have their favorite editor and Doctave Studio open side-by-side as they are editing documentation. When they save changes in their editor, Doctave studio detects the change and re-renders the documentation with the latest changes. Improved layout One of the most common requests we had was "make Doctave Studio narrower". In the previous release, information about broken links and other metadata was held in a sidebar on the left side of the documentation preview. This took up a lot of valuable screen space. We even found ourselves overlaying our editor slightly on top of Doctave Studio in order to make the windows fit nicely. With this update, we've introduced a whole new vertical layout. Now, your docs are front and center, with issues and metadata shown above and below the content itself. You can hide issues when you don't want to worry about them, and view them only when you want to focus on them. View in browser ↗ Inspect your docs in your browser with one click This was another often requested feature. Doctave Studio itself does not let you inspect your page's HTML or debug custom CSS. CSS especially is notoriously hard to get right the first time, and debugging issues through trial and error is frustrating. We did not want to re-implement something browsers already allow you to do well, so we've added an "View in browser" button! You can now open up the project you're viewing in the browser, and use the full power of Chrome Devtools t ## A Pre-Deployment Checklist for Risky Data Migrations DevFeed: [A Pre-Deployment Checklist for Risky Data Migrations]() Original publisher: [Read original article]() Published: 2023-09-13T00:00:00Z Content type: tutorial Language: en Sources: [Artsy]() Topics: [Command-line interface](), [Docker](), [Kubernetes](), [Sidekiq](), [Latency]() Tags: [command-line](), [data-migrations](), [deploy-process](), [docker](), [error-reporting](), [kubernetes](), [latency](), [logs](), [migrations](), [retry](), [ruby-on-rails](), [sidekiq]() ### AI overview This article presents a pre-deployment checklist for risky data migrations and other changes that could affect production services. It recommends planning rollback steps and monitoring error rates, reported errors, latency, logs, functionality, and failing Sidekiq retries after deployment. ### Source excerpt Lately, I've been getting involved with some sketchy stuff. You know what I'm talking about-data migrations. I've been rolling out changes that have a significant risk of breaking our production environment for mission-critical services. It's been exciting work (keep your eyes out for more posts on the exact project, coming soon™), but I've definitely caused a couple incidents along the way. After accidentally taking down a key service for a couple hours, I decided I needed to have a better pre-deploy process for these changes. I did some thinking and came up with a short checklist to run through before I press the shiny green button. Here's the checklist I came up with: What is your plan if something goes wrong? Run through ramifications of rolling back. If there's a reason you're worried about rolling back, then you're not ready to deploy the change yet! Figure out exactly what command(s) you will need to run to roll back. At Artsy, this is usually a one-liner using Hokusai, our command-line Docker/Kubernetes CLI How will you tell if something is going wrong after you deploy? Error rate (DataDog) Specific error reporting (Sentry) Latency (DataDog) Logs (Papertrail) Functionality (does it still work? Are people using it successfully? Important for things where errors may not be bubbled up correctly or reported immediately) Sidekiq (are there lots of jobs queued to retry that are failing?) With this checklist in hand, I'm deploying more confidently and causing fewer incidents along the way. Do you have something similar? Are there things you think this checklist should include? Let me know in the comments! ## Diagnosing and fixing an ERR\_CONNECTION\_RESET error in WordPress DevFeed: [Diagnosing and fixing an ERR\_CONNECTION\_RESET error in WordPress]() Original publisher: [Read original article]() Author: Schakko Published: 2020-12-14T19:37:31Z Content type: tutorial Language: en Sources: [Schakko]() Topics: [WordPress](), [PHP](), [bug](), [Chrome](), [networking]() Tags: [browser](), [bug](), [chrome](), [error-reporting](), [how-to](), [issue](), [logs](), [networking](), [server](), [uncategorized](), [wordpress]() ### AI overview This tutorial diagnoses intermittent ERR_CONNECTION_RESET errors in the WordPress theme editor. By examining Apache and PHP-FPM logs, the author attributes the failures to excessive PHP notices causing the process to terminate, and resolves the issue by changing WordPress error_reporting to E_ALL & ~E_NOTICE. ### Source excerpt If you receive the error ERR_CONNECTION_RESET on one website only, it is highly likely that something went wrong on the server side. Receiving random ERR_CONNECTION_RESETs A few weeks ago one of my colleagues complained to me: Sometimes, when he was using the WordPress theme editor, he either received an empty [...] The post Diagnosing and fixing an ERR_CONNECTION_RESET error in WordPress appeared first on schakko.de. ## Ловим баги на клиенте: как мы написали свою систему для сбора клиентских ошибок DevFeed: [Ловим баги на клиенте: как мы написали свою систему для сбора клиентских ошибок]() Original publisher: [Read original article]() Author: Unclead (Badoo) Published: 2020-10-08T13:23:03Z Content type: tutorial Language: ru Sources: [Badoo EN](), [Badoo RU]() Topics: [error tracking](), [App](), [Android](), [iOS]() Tags: [android](), [app](), [badoo](), [error-reporting](), [error-tracking](), [ios](), [sentry](), [tag-9e6194bca65c](), [tag-d96e238f1419]() ### AI overview This article explains how Badoo developed Gelato, an in-house system for collecting client-side errors across web, Android, and iOS applications. It discusses why the company built its own error-tracking system, how error data supports production monitoring and release analysis, and considerations for designing such a system. ### Source excerpt У нас в Badoo довольно много клиентских приложений. Помимо основных продуктов Badoo и Bumble, у которых есть как веб-версии (десктопная и мобильная), так и клиенты под нативные платформы (Android и iOS), ещё есть с десяток внутренних инструментов со своими UI. Для сбора клиентских ошибок мы используем собственную разработку под кодовым названием Gelatо. Последние два года я работал над её серверной частью и за это время открыл для себя много нового из мира разработки Error Tracking систем. Поэтому, если вам интересно узнать, что из себя представляет разработка системы сбора клиентских ошибок и о чём стоит подумать, если вы решите разрабатывать собственную, добро пожаловать под кат. Читать далее ## Improving Error Reporting in a Simple Interpreter DevFeed: [Improving Error Reporting in a Simple Interpreter]() Original publisher: [Read original article]() Author: Ruslan Spivak Published: 2019-06-21T09:45:00Z Content type: tutorial Language: en Sources: [Ruslan Spivak]() Topics: [error reporting](), [Python](), [Exception](), [Parsing]() Tags: [blog](), [custom-exceptions](), [error-reporting](), [parsing](), [python]() ### AI overview This tutorial improves error reporting in a simple interpreter's lexer, parser, and semantic analyzer. It adds error codes, custom exceptions, token position tracking, a scope command-line option, and Python 3.7+ support. ### Source excerpt "I am a slow walker, but I never walk back." -- Abraham Lincoln And we're back to our regularly scheduled programming! :) Before moving on to topics of recognizing and interpreting procedure calls, let's make some changes to improve our error reporting a bit. Up until now, if there was ... ## Debugging Netlify Function Errors with Sentry DevFeed: [Debugging Netlify Function Errors with Sentry]() Original publisher: [Read original article]() Author: HTTP Toolkit; Tim Perry Published: 2019-01-31T19:30:00Z Content type: tutorial Language: en Sources: [HTTP Toolkit]() Topics: [Netlify](), [debugging](), [Serverless](), [Logging](), [AWS Lambda](), [Code]() Tags: [aws-lambda](), [debugging](), [error-reporting](), [errors](), [javascript](), [logging](), [netlify](), [sentry](), [serverless]() ### AI overview A tutorial on adding Sentry error reporting to Netlify Functions. It explains why serverless function errors can be difficult to detect and debug, then covers setup, DSN configuration, initialization, and handling errors that Netlify or AWS Lambda may otherwise swallow, delay, or lose. ### Source excerpt Netlify functions are a quick, easy & powerful tool, but like most serverless platforms, they can be even more difficult to debug & monitor than traditional server applications. It's a hard environment to precisely recreate locally, there's no machine you can SSH into in a pinch, and no built-in error notifications. Your code is going to break eventually, and you need the tools to fix it. HTTP Toolkit uses Netlify functions under the hood to manage user account information and Paddle checkout callbacks. If we hit errors here, people's payments will fail, or they'll stop being given access to paid features, so this can be pretty bad! I need to be able to catch errors immediately, debug and work out why they're happening, and confirm that my fixes work. Debugging & fixing issues here is a big topic, but one of the first steps is knowing exactly when & how errors happen. There's a few tools for this, but personally I've had a lot of success on projects recently with Sentry. They've got a generous free plan (5k errors a month), built-in integrations for almost everything, and some good & detailed error reporting tools too. If you can get Sentry set up, you'll get emails every time there's an error in your function, and you can explore the errors themselves in detail to work out exactly what failed. Perfect, but the setup for Netlify functions has a few extra steps. Start reporting errors to Sentry I'm going to be using JS here, and I'm assuming you've already got a working Netlify function set up. To add Sentry reporting from there, you need to: Create a Sentry account Create a Sentry project in that account for your functions Take the DSN for your Sentry project and set it as a SENTRY_DSN variable in your Netlify build npm install --save @sentry/node (the examples here require ^4.6.0) Initialize your error logging logic: const Sentry = require('@sentry/node'); const { SENTRY_DSN } = process.env; let sentryInitialized = false; export function initSentry() { if (SENTRY_D ## Apollo Server 2.0: Performance and error reporting built in DevFeed: [Apollo Server 2.0: Performance and error reporting built in]() Original publisher: [Read original article]() Author: Sashko Stubailo Published: 2018-06-26T17:54:00Z Content type: release Language: en Sources: [Apollo Blog]() Topics: [GraphQL](), [API](), [JavaScript](), [Open Source](), [Development]() Tags: [api](), [apollo](), [backend](), [development](), [error-reporting](), [error-tracking](), [graphql](), [javascript](), [open-source](), [performance](), [production](), [release](), [server]() ### AI overview This article introduces Apollo Server 2.0, describing its goal of providing a single open-source tool for taking GraphQL APIs from prototype to production. It explains that Engine Proxy features, including performance tracing, error tracking, CDN integration, and caching, are built into Apollo Server in open-source JavaScript, and outlines setup using an API key. ### Source excerpt Over the last few weeks, you might have heard a lot about Apollo Server 2.0, which is currently in the RC stage with the final release coming soon. It's the biggest open source release we've worked on since Apollo Client 2.0 last year. Here's our focus for this major new version: Apollo Server 2 will come with everything you need to take your GraphQL API from prototype to production. No more pulling in several libraries, wiring them together, and figuring out best practices on your own. ## Introducing Apollo Engine: insights, error reporting and caching for GraphQL DevFeed: [Introducing Apollo Engine: insights, error reporting and caching for GraphQL]() Original publisher: [Read original article]() Author: Rohit Bakhshi Published: 2017-10-24T23:38:00Z Content type: release Language: en Sources: [Apollo Blog]() Topics: [GraphQL](), [apollo-server](), [Caching](), [error tracking](), [tracing](), [API](), [Architecture & Design]() Tags: [announcement](), [api](), [apollo](), [architecture](), [backends](), [cache](), [caching](), [error-reporting](), [error-tracking](), [graphql](), [tracing]() ### AI overview Apollo introduces Apollo Engine, a managed hybrid infrastructure layer for GraphQL services. It adds query caching, error tracking, execution tracing, schema analysis, and API usage trends for spec-compliant GraphQL servers. ### Source excerpt Today we're excited to introduce Apollo Engine, our new turnkey infrastructure that helps you take GraphQL services into production with confidence. The successor to Apollo Optics, Engine delivers essential capabilities like query caching, error tracking, and execution tracing on top of any spec-compliant GraphQL server including Apollo Server, GraphQL-Ruby, Sangria, and Absinthe. Adding Engine to your server is as easy as an command. Click here to get started! ## Apollo Seeks Early-Access Feedback on New Optics Features DevFeed: [Apollo Seeks Early-Access Feedback on New Optics Features]() Original publisher: [Read original article]() Author: Rohit Bakhshi Published: 2017-08-23T17:57:00Z Content type: release Language: en Sources: [Apollo Blog]() Topics: [GraphQL](), [monitor](), [tracing](), [API](), [Elixir](), [Java](), [Scala]() Tags: [api](), [developers](), [elixir](), [error-reporting](), [features](), [graphos](), [graphql](), [java](), [metrics](), [notifications](), [performance](), [scala](), [tracing](), [update]() ### AI overview Apollo is seeking early-access feedback on planned Optics features for GraphQL developers, including Apollo Tracing support for Java, Scala, and Elixir GraphQL servers, field- and query-level error metrics, and threshold-based notifications for performance and error metrics. ### Source excerpt The team at Apollo has been really happy with the response we've gotten after announcing the 1 million query free tier update to Optics! It's awesome to see thousands of developers using Optics to visualize the execution of their GraphQL queries, monitor performance trends, and track how clients are consuming their API. ## Curious Customer DevFeed: [Curious Customer]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2016-06-28T15:24:00Z Content type: opinion Language: en Sources: [Jay Fields]() Topics: [bug](), [Software](), [unit tests](), [test](), [error reporting](), [coding]() Tags: [bugs](), [context](), [customers](), [developer](), [error-reporting](), [software](), [testing](), [tests](), [unit-tests]() ### AI overview A developer reflects on how bugs triggered by nonsensical user behavior created noise, context switching, and distrust in application data despite appearing minor. The article proposes having another developer use new features in staging as a "Curious Customer" to uncover issues that conventional tests may miss. ### Source excerpt I currently work on a pretty small team, 4 devs (including myself). We have no one dedicated strictly to QA. A few years ago we ran into a few unexpected issues with our software. I hesitate to call them bugs, because they only appeared when you did things that made little sense. We write internal-only software, thus we expect a minimum level of competency from our users. In addition, it's tempting justify ignoring problematic nonsensical behavior in the name of not having to write and maintain additional software. But, when I wasn't in denial, I was willing to admit that these were in fact bugs and they were costing us time. The problems caused by these bugs were small, e.g. a burst of worthless emails, a blip in data flowing to the application. The emails could be quickly deleted, and the application was eventually consistent. Thus I pretended as though these issues were of low importance, and that the pain was low for both myself and our customers. I imagine that sounds foolish; in retrospect, it was foolish. The cost of developer context switching is often very high, higher if it's done as an interrupt. Introducing noise into your error reporting devalues your error reporting. Users can't as easily differentiate between good data, a blip of bad data due to something they did, and actual bad data, thus they begin to distrust all of the data. The cost of these bugs created by nonsensical behavior is high, much higher than the cost of writing and maintaining the software that eliminated these bugs. Once we eliminated these bugs, I spent notably more time happily focused on writing software. For me, delivering features is satisfying; conversely, tracking down issues stemming from nonsensical behavior always feels like a painfully inefficient task. I became very intent on avoiding that inefficiency in the future. The team brainstormed on how to address this behavior, and honestly we came up with very little. We already write unit tests, load tests, and integration te ## Best Practices in Error Handling DevFeed: [Best Practices in Error Handling]() Original publisher: [Read original article]() Published: 2011-09-13T00:00:00Z Content type: opinion Language: en Sources: [Radek Pazdera]() Topics: [Error Handling](), [error reporting](), [Programming](), [Code](), [Terminal](), [Security]() Tags: [best-practices](), [error-handling](), [error-reporting](), [programming](), [security](), [terminal]() ### AI overview The article argues that software projects need a consistent error-handling strategy. It recommends user-facing error messages that explain what happened and why, while avoiding excessive technical detail such as stack traces or memory dumps that may create security risks. It also contrasts centralized and decentralized error handling. ### Source excerpt My idea of how errors should be handled in programs.