Build a diagnostic query library for support teams

When an incident spans environments, engineers end up rewriting the same investigative queries from memory, differently each time, often with production credentials in plain sight.

The problem: ad-hoc diagnostics, and a key-person risk

Every support team has a handful of queries everyone reaches for during an incident: "who's locking this table," "what changed on this account in the last hour," "is this queue backing up again." They usually live in someone's notes, someone's memory, or a shared document that's slightly out of date. When that person is on leave, or it's 2am and someone junior is on call, the investigation starts from scratch.

The BroadSQL approach: a saved library, run by name, against any environment

BroadSQL's query library saves a query once and runs it by name from then on:

LIB RUN locked_tables.sql;
LIB RUN account_activity.sql;
LIB LIST;

The same canned diagnostic runs identically whether it's pointed at the connection for customer_eu or customer_us. The query doesn't change; only which connection is currently open does. Combined with BroadSQL's encrypted connections vault, an engineer gets safe access to production for the duration of the investigation without ever seeing the underlying password.

Honest scope

This is a shared library of queries and a consistent way to run them, not an incident-management platform, and it won't page anyone or track a timeline for you. What it solves is the "what do I run, and does it work the same for everyone" part of an investigation.

Who this is for

L2/L3 support and incident-response teams who want investigations to be consistent across shifts and across whoever happens to be on call, not dependent on one person's memory.

Onboard your team onto one shell

I build the diagnostic runbook (the canned queries mapped to your common incident types) and onboard the whole team onto BroadSQL so every shift investigates the same way. Get in touch to talk about your team's recurring incidents.