Changelog

DebugBear automatically generates notifications if it looks like there's been a regression on your site. That means you don't need to do any work to get set up, but you might get some notifications that aren't relevant to you.

From now on you can configure when a notification is sent. It's been possible to mute specific notifications for a while, but I've now added some documentation for it.

One common issue has been notifications for performance issues that can't be reproduced later on. Maybe the server was busy, or something weird happened with DNS. To avoid this problem in the future, some performance alerts are now only sent if the performance problem occurs more than once in a row.

DebugBear now has a Validation tab which shows errors and warnings generated by the W3C HTML validator.

Most of these errors aren't very helpful. The HTML might not be valid, but as long as all browsers handle it fine that's not a problem. And sometimes the validator doesn't know about a recently added feature and will complain about it.

So DebugBear doesn't list common validation errors by default, and currently no email or Slack alerts are sent if there's a regression.

However, there are many potential problems the validator can identify:

• duplicate attributes (e.g. two style attributes on the same element)
• Stray start and end tags
• Invalid inline CSS, like style="background: [object Object]"

Until yesterday, DebugBear had a Login Steps feature that allowed you to fill out a login form before testing your page. There were a few problems with this though:

• What if your site's login flow is split over two separate pages?
• What if you have more than two form fields that need to be filled out?
• What if you want to fill out a search from rather than do a login?

User flows are the solution to these problems. Rather than shoehorning all this functionality into a login form, you can now set up flexible steps that run before the actual page analysis.

We've published a new version of the Node API. Here's an example of what you can do with it:

const { DebugBear } = require("debugbear")
const debugbear = new DebugBear(process.env.DEBUGBEAR_API_KEY)

const analysis = await debugbear.pages.analyze(pageId, {
  // Commit Hash is required to generate a build
  commitHash: "abc123",
  customHeaders: {
    "X-Enable-Experiment": "true"
  },
})
const result = await analysis.waitForResult()
console.log(result.build.status) // "success"

Check out the migration guide if you're moving from version 1 of the API.

Browsers make OCSP requests to check if a certificate is revoked. Chrome only does this for Extended Validation (EV) certificates.

These requests are now included in the request chart, so it should be easier to understand if you SSL connection takes a long time: