Application Insights Workbooks: where the Azure Monitor gallery templates actually live

A gallery catalogue, not a monitoring tool

The repository name and description can mislead. This is not the Azure Monitor product, and it is not a client library you would install. The README states plainly that the repository contains the templates shown in the workbook galleries of Azure Monitor Workbooks, and that templates added here show up in the various workbook galleries for users of Azure Monitor Workbooks. So its audience is two groups. The first is Azure Monitor users who want a ready-made interactive report rather than building one from scratch, and the second is the people who write those reports and want them available to everyone else. The contribution framing is explicit about the point: by contributing templates you help others solve problems using workbooks you found helpful on your own team. The licence is MIT, the last push was on 2026-10-17, and the repository publishes no GitHub releases.

What a workbook is, in the terms the documentation uses

The README summarises the capability set that every template in the gallery can draw on, and it is worth reading because it defines what a contributed template can contain. Workbooks give Azure Monitor users a flexible canvas for customizable interactive reports and analytic narratives. Within that canvas you can create rich visual reports and analytics experiences inside the Azure portal, use metric, log and Azure Resource Graph data side by side, build interactive experiences driven by user input, and customize an analysis and persist it for later use. Curated analysis from a public gallery is a capability in its own right, which is exactly what this repository provides. And the whole thing is programmable through ARM, so workbook assets can be created and managed programmatically. The README links to per topic documentation under Documentation/, covering data sources, visualizations, parameters, groups, interactivity, programmatic management, a sample gallery, contributing and testing, previews, auto-refresh, and a page on the new gallery.

Templates are JSON, and a schema decides whether they are valid

The primary language of the repository is JSON, and the top level entries show the shape of the content. There is a Workbooks/ directory holding the templates, a gallery/ directory, a schema/ directory, a test/ directory, a Documentation/ directory, and scripts/. There is also a Cohorts/ directory, and a set of Windows helper scripts including npmInstall.cmd, npmTest.cmd, and a hotfix merge tool in both PowerShell and cmd form, with a MergeHelper.psm1 module backing it. The schema directory is the part that matters most to a contributor, because a template is not just a picture of a report, it is a document that has to satisfy a contract before it can be published. The package manifest shows the test tooling: mocha as the runner, chai for assertions, minimist for argument parsing, and jsonschema as a dependency, with a mocha-trx-reporter for the full build test so results can be published in the format Azure DevOps understands.

Two ways to run the tests, and a build test that publishes results

The package manifest defines two scripts, and the difference between them is the reporting format rather than the coverage. The plain test script runs mocha with its default reporter, and the fullbuildtest script runs the same suite with a different reporter and a path for the output file, which is what a CI pipeline consumes.

  "scripts": {
    "test": "mocha",
    "fullbuildtest": "mocha --reporter mocha-trx-reporter --reporter-options output=output/testresults.trx"
  },

On a Windows checkout the two cmd files at the repository root are the intended entry points, one to install the node dependencies and one to run the tests, which removes the guesswork from getting a consistent local environment before you open a pull request. The README also links to the contributing guidelines and, inside the documentation tree, a section on how to test your changes, a section on testing preview workbook templates, and a section on the new gallery, so the validation expectations are documented rather than tribal knowledge. A template validation workflow badge sits at the top of the README, which is the visible signal that a pull request gets checked automatically.

Curation is the real filter, not the schema

Here is the constraint that decides whether your contribution lands. The README notes that templates in this repository will show up for all users of Azure who open the specified gallery, and for that reason the templates gallery is curated by Microsoft. The stated acceptance rule is twofold: the submitted template has to be useful to the community, and it must not place undue stress on the underlying infrastructure. That second condition is the interesting one, because a template that runs an expensive query against every customer's workspace is a template that costs the platform money. In practice this means the gallery rewards reusable, bounded analyses rather than dashboards tuned to one environment. Everything else, the file layout and the JSON validation, is mechanical; the usefulness and the resource footprint are judgement calls made by the curators.

Where this repository is the wrong place to work

The scope is narrow enough that the wrong-tool cases are easy to state. If you want a workbook for your own team only, this is the wrong place, because anything merged here is public, and the README says contributions require a Contributor License Agreement declaring the right to grant Microsoft the rights to use the contribution, with details at the Microsoft CLA site. If your team works in Azure Resource Manager templates and wants infrastructure-provisioned dashboards, workbooks are only one output format and ARM programmability is a separate concern from this gallery. And if you need automated analysis on a schedule, the documentation points to an auto-refresh page, which is a feature of the Azure Monitor Workbooks product rather than a feature of this repository. The repository also carries a CODEOWNERS file, a SECURITY.md and an .npmrc, which tells you that changes to it are reviewed by specific owners rather than merged on trust. There is a Microsoft Open Source Code of Conduct, and support questions are directed to the Azure support channels rather than to the issue tracker.

Editorial conclusion

Contribute to this repository if you have a workbook worth sharing with every Azure Monitor user, because the templates merged here appear in the public galleries. Do not treat it as a way to ship private workbooks, since the gallery is curated by Microsoft and any template you add shows up for all Azure users. Verify first that your template passes the schema and the test suite locally, using npmInstall.cmd and npmTest.cmd, because the merge pipeline rejects templates that do not validate.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/Application-Insights-Workbooks on GitHub
4. README