Teach webQsee what your kind of broken looks like.

Classify any event, any way.

Each rule is a matcher plus a classification, written against one of the five event kinds webQsee captures: HTTP, console, Server-Sent Events, WebSocket connections and WebSocket messages. Every kind exposes its own set of fields to match on.

Match an event and the rule gives it a status (OK, warning, error or pending), a label, a description and a custom type, and the row is highlighted in the analyzer grid so it is impossible to miss. Only one rule applies per event: if several match, the first one wins, which is what the priority field is for.

• HTTP, response status and status text, response body text, content type, request URL as a whole or split into hostname, path and query string
• Console, message level, raw and formatted text, any stringifiable argument, the originating script URL
• WebSocket, handshake status, incoming and outgoing message text, opcodes, error text
• Server-Sent Events, event name and event data
• Plus the inspected page's own URL, on every event kind
• Compose conditions with AND / OR, or drop into a scripted rule and write JavaScript

Senior writes once. Junior gets it instantly.

On Small Team and Team editions, rules can be published to the whole team. A senior engineer codifies the patterns that took five years of incident response to learn, and from that moment, every junior on the team gets the same warnings, the same fix instructions, the same escalation paths.

That's the kind of organisational leverage that's hard to manufacture any other way. webQsee makes it a checkbox.

Two editors, one engine: a graphical one for the usual conditions, and a scripted one where a rule is a small sandboxed JavaScript function receiving the event. Reach for the second one when "status 500 and the body mentions this" is not expressive enough.