The art of simplicity

After upgrading our SQL Server Reporting Services (SSRS) environment, we noticed some isuses: reports were slow, users were complaining, and we had no idea where to start. The good news is that SSRS has been quietly collecting detailed execution data the whole time — and a set of built-in views makes it surprisingly easy to query. This post walks through the ExecutionLog views, what they contain, and how to turn that data into actionable performance insights. What are the ExecutionLog views? SSRS logs every report execution to the ReportServer database. Three views expose this data at different levels of detail: ExecutionLog — A simple view covering the basics: report name, user, start time, and duration. Good for quick lookups. ExecutionLog2 — Adds AdditionalInfo , an XML column with richer metadata such as estimated row counts and data source connection details. ExecutionLog3 — The most complete view. Breaks execution time into three distinct phases — TimeData...

Yesterday I introduced to you statusline command. It allows you to configure a persistent, live bar at the bottom of your CLI session that shows whatever your script prints — token usage, context percentage, current model, cost estimates, session duration, and more. I promised that we would setup something like this: █████░░░░░ 50% 64.0k/128.0k | ✱ Sonnet 4.5 | ~$0.04 | ⏱️ 00:12:34 But yesterday we only got as far as showing this: Hello from PowerShell status line! If you missed the previous post, go read it first, before continuing here. Back? Let's continue... Now we have confirmed the script runs and we've the payload, we can now focus on creating a production-ready version. It extracts context usage, model name, cost (from the payload if available, estimated otherwise), and session duration. I first created my own version but while researching this post I discovered this blog post by Madis Kõosaar: Customize GitHub Copilot CLI Status Line . He created a much...

If you spend serious time in GitHub Copilot CLI, you've probably had that moment. You're deep in a session, things are moving fast, and suddenly you hit context compaction out of nowhere. The /context and /usage commands help, but they interrupt your flow. What if the information was just there , all the time, without you having to ask? That's exactly where the statusline command can help: a persistent, live bar at the bottom of your CLI session that shows whatever your script prints — token usage, context percentage, current model, cost estimates, session duration, and more. Once it's running, it looks something like this: █████░░░░░ 50% 64.0k/128.0k | ✱ Sonnet 4.5 | ~$0.04 | ⏱️ 00:12:34 This guide walks you through the full setup from scratch, including a "hello world" sanity check. In a follow-up post we’ll tweak the result to example above. Status: Custom status line support requires experimental features enabled in Copilot CLI. You can e...

If you've been using GitHub Copilot CLI for a while, you've probably had that Monday morning feeling; staring at your terminal trying to remember exactly what you were doing on Friday. Or maybe you've wondered why some of your Copilot interactions go smoothly while others turn into back-and-forth marathons. Enter /chronicle , an experimental slash command that turns your CLI session history into something genuinely useful. Session history Every time you interact with Copilot CLI, the session data is stored locally on your machine. That's not just a log file — it's a record of your real-world workflow: which branches you worked on, what you tried, when you got stuck, and how you course-corrected. The /chronicle command gives you a structured way to query that history and extract insights you couldn't easily get otherwise. Note: /chronicle is currently an experimental feature. You'll need to run /experimental on (or use the --experimental flag)...

In the previous post I set the stage on deploying to production. We covered managing the CLI process, different isolation patterns and how to scale horizontally. This post covers 2 other aspects important when putting your GitHub Copilot SDK enabled application into production; how to tackle authentication and how to get insights into what is going inside your agentic system. Authentication in production Development uses your personal GitHub credentials via gh auth login . Production backends need a different approach. Service account token (shared CLI): Set COPILOT_GITHUB_TOKEN as an environment variable on the CLI process. All sessions on that CLI use the same token. Simple, but every user is acting as the service account. export COPILOT_GITHUB_TOKEN="gho_service_account_token" copilot --headless --port 4321 Per-user tokens (GitHub OAuth): For multi-tenant applications where users authenticate with their own GitHub identities, pass each user's token wh...

In the previous post we went deep on sessions — how to create, persist, resume, and manage them in .NET. All of that assumes you have a running application talking to a Copilot CLI. In development, that's trivial: the SDK starts the CLI for you automatically. In production, the picture is more complex. This post is about what happens between "it works on my machine" and "it's serving real users." We'll look at how the CLI architecture actually works, when to run the CLI as a separate headless server, the isolation patterns that fit different application types, and how to scale horizontally without losing session state. How the SDK talks to the CLI Before making deployment decisions, it helps to understand the communication model. Every SDK in every language works the same way underneath: Your Application ↓ SDK Client ↓ JSON-RPC ↓ Copilot CLI (server mode) All SDKs communicate with the Copilot CLI server via JSON-RPC. ...