Slash Commands

slash commands let your team encode frequently used investigations, checks, and reports into fast, repeatable actions when defined in team knowledge, they help resolve (and your team) move from question → answer quickly instead of re explaining how to check a dashboard or re running the same mental playbook, slash commands turn tribal knowledge into one line, reliable workflows why use slash commands? slash commands are especially useful when a task is performed frequently the investigation steps are well defined the output format should be consistent the action depends on team specific tooling or dashboards key benefits speed trigger complex checks with a single command consistency everyone gets the same data, formatted the same way knowledge capture encode tribal workflows directly into team knowledge lower cognitive load no need to remember where or how to look things up better investigations resolve can apply these commands automatically when relevant common patterns for slash commands slash commands typically fall into a few categories health checks (load tests, deploys, service status) standard reports (weekly/monthly metrics, kpis) focused lookups (one service, one dashboard, one view) opinionated summaries (what matters, not everything) the examples below show how to write commands that are specific, actionable, and unambiguous the following examples can be added to your resolve md, under a slash commands header slash command structure describe slash commands within resolve md, in a slash commands section \# slash commands \## /command1 command1 description \## /command2 command1 description examples add the following examples to resolve md, within a slash commands section (see above) modify the examples to your use case /peek get a fast, opinionated snapshot of a service’s current health \## `/peek` \### behavior look up the service specified by the first argument and print only the following statistics from datadog as a bulleted list \ average requests per second (past 24 hours) \ average latency \ p95 latency \ p99 latency \### important \ output only the bulleted list \ do not include explanations or extra context \### example /peek my service name /load test quickly determine whether a load test is currently running and understand its potential impact \## `/load test` \### behavior \ identify any active or recently started load test workflows \ for each active load test, report \ workflow name \ target service(s) \ start time and current status \ expected traffic profile (if available) \ clearly indicate if no load tests are running \### output guidelines \ summarize results in a short, human readable list \ highlight active load tests prominently \ avoid raw dashboard dumps or screenshots \### example /load test \### example output \ checkout loadtest prod \ status running \ started 12 minutes ago \ target checkout service \ notes gradual ramp to 3x baseline rps /wow report generate a clean, standardized performance report for leadership or reviews \## `/wow report` \### behavior \ query `\<dashboard>` and `\<panel>` for \ wow / mom \ format the results into a clear, readable table \ include only the relevant metrics (no raw charts) \### example /wow report \### when to use \ weekly or monthly business reviews \ post incident summaries \ performance check ins best practices for writing slash commands be explicit about data sources (dashboards, panels, tools) specify exact output format prefer small, focused commands over large, do everything ones assume the reader is on call and time constrained when slash commands are used slash commands defined in docs can be triggered directly by users in chat reused across alerts, investigations, and reports summary slash commands turn your team’s best investigative instincts into fast, repeatable actions if your team regularly says “we always check this when that happens…” that’s probably a slash command waiting to exist