The restart button sits
next to the graph that justifies it.
Datadog App Builder, listed as Datadog Apps in Datadog's navigation, builds small internal tools on Datadog queries and the Action Catalog that Workflow Automation uses. A table of pods, a button that restarts one, a form that opens a ticket. We implement the few apps worth having, scope the connections behind the buttons, and keep them current every month.
Quick facts
Related
- Workflow Automation, the run that the app's button starts
- Software Catalog, the owner and service data an app can show
- Bits Agent Builder, when the tool should reason rather than click
A tool for the one action the dashboard keeps asking for
The dashboard shows a queue backing up. The fix is a restart that three people have permission to run. The engineer looking at the graph is not one of them, so the fix is a message, a wait and a copy-pasted command. App Builder puts the button beside the graph, with the permission behind the button rather than behind a person.
Built from what Datadog already knows. An app queries the same metrics, logs and tags the dashboard does. The table of pods is live, the service owner comes from Software Catalog, and the filters are the ones the team already uses.
Actions from the catalogue, not from scratch. The Action Catalog gives the app the same restart, scale, ticket and notify actions that Workflow Automation uses, with the same connections. An HTTP or JavaScript action covers the system nobody integrated.
Embedded where the decision is made. An app runs inside a dashboard as a widget, so the context and the control are on one screen. Datadog ships prebuilt apps on some integration dashboards, which is a reasonable place to start.
A record of who pressed what. Each action runs under a named connection and is logged, so the restart that fixed the queue, and the one that did not, are both in the history.
A button wired to an admin credential, published to everyone, on a dashboard nobody told the platform team about
How it bills. Datadog lists App Builder as billed per published app, per month. Draft apps are not published apps. A workflow started by an App Builder event is not billed as a workflow run: Datadog documents free runs for workflows triggered by App Builder events, and a chain that starts there is free however deep it goes. We publish no rates. The meter is the count of published apps, which is why we review the list every month and unpublish the ones nobody opened.
The configuration traps. The first app is built by the person with the broadest access, and its connection inherits that access. The app is then shared to the whole organisation, so a button that scales a production group is one click away from anyone who can see the dashboard. Apps are duplicated rather than edited, and five near-identical published apps each cost a line. A JavaScript action calls an internal endpoint with a token pasted into the code. Nothing in this list is a limitation of App Builder. Each is a shortcut that was reasonable on the day and is still there a year later.
Field noteThe most common gap we see is the connection reused from the first workflow. It was created with an admin key to get something working, and every app since has used it, because creating a scoped one meant finding out who owned the account.
Field noteAn app is published to the whole organisation because that is Datadog's default on publish: the author keeps Editor and everyone else in the org gets Viewer. The engineers who should use it do. So does everyone who can see the dashboard it is embedded in, and nobody has listed who that is.
Field noteThe pattern we keep finding is the app built for one incident, still published, still billed, with a hard-coded service name that was renamed two releases ago. It opens, it shows an empty table, and it is nobody's job to notice.
Field noteThe useful app is the one that replaces a runbook step that says "ask someone with access". Where that step exists, the app is used daily. Where the step was already a command the engineer could run, the app is opened once and the terminal wins.
Find the step that says "ask someone with access". Build that. Build nothing else yet.
App Builder is the last week of the Service Management Accelerator, a four-week, fixed-scope delivery that also sets up Incident Management, Event Management, Workflow Automation and Work Management. The apps come last because they sit on top of the workflows and the connections built in the earlier weeks. If apps already exist, a Datadog HealthScan lists the published set and the connections behind them before we change anything.
- Pick the actions from the runbooks. From the incident history: which actions needed a person with access the responder did not have. Those are the buttons. A dashboard that only needs a better widget does not need an app.
- Create a connection per action. Each button runs under a connection scoped to that action and that environment, shared with the matching workflow. The admin connection from the first experiment is retired.
- Build on existing queries. The tables and filters come from the dashboards and Software Catalog entities the team already trusts. The app shows the same numbers as the graph beside it.
- Put the action behind a workflow where it needs an approval. A restart runs directly. A scale-up or a data change starts a Workflow Automation run with an approval step, so the button asks a named person before it acts.
- Scope the audience and publish. Each app is shared to the team that will use it and embedded in the dashboard they already open. Nothing is published to the whole organisation by default.
- Hand over the app register. Every published app with its purpose, its connections, its audience and the runbook step it replaced. The list is reviewed and pruned rather than rediscovered.
Access is admin on the Datadog organisation plus scoped service accounts on the systems the buttons act on. Where an action reaches inside your network, the Private Action Runner from the Workflow Automation setup is reused.
An app is a published promise that the button still does what the label says
Services get renamed, connections expire, the team that used the app is reorganised. Under Managed Observability we review every published app against what it is for, and under Critical Support the button that does not fix the problem escalates to our engineer.
Every month, the app register is read. Published apps against the register: opened or not, connection still valid or not, audience still correct or not. Apps nobody opened in a quarter are unpublished, which also takes them off the meter.
Apps follow the estate. When a service, namespace or dashboard the app queries changes, the app is updated in the same change. A table that shows nothing is a bug we treat as one.
Connections are kept scoped. A quarterly check that every connection behind every button still has the narrowest role that works, and that no app has been reshared to a wider audience than the register says.
The button that did not work pages us. When the restart does not clear the alert, the workflow behind the button escalates to our on-call engineer with the run attached. The next step is ours to take.
We operate the stack. You own the product.
A low-code tool is cheap to build and expensive to leave unattended, because every published app is a credential with a user interface. We build the few that replace a real runbook step, scope what sits behind them, and review the list every month. The apps, the connections and the register stay in your Datadog, and you can take them in-house whenever you choose.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog App Builder, answered plainly
Is it called Datadog Apps or App Builder?
Both names are in use. Datadog's documentation calls the product App Builder and describes it as a low-code platform for building internal tools. Datadog's product navigation lists it as Datadog Apps, and the things it produces are apps. We use App Builder for the product and apps for what it makes, and we link it from the Datadog Apps entry on our products hub so either search lands here.
How is Datadog App Builder billed?
Datadog lists App Builder as billed per published app, per month. Draft apps are not published apps. A workflow started by an App Builder event is not billed as a workflow run. We do not publish prices. We keep the published list short and unpublish what is not used.
When should we use App Builder rather than Workflow Automation?
Workflow Automation is for a sequence of actions that should run from a trigger without a person in the loop. App Builder is for a person who needs to see context and then choose an action. The two share connections and the Action Catalog. The common pattern is an app whose button starts a workflow: the person sees the table, the workflow does the steps, and an approval sits where one is needed.
Who can see and use an app we publish?
Whoever it is shared with, and when it is embedded in a dashboard, whoever can open that dashboard. Each action runs under the connection configured behind it, not under the viewer's own Datadog permissions, so the audience of the app is the access list for the action. We scope each app to the team that uses it and record the audience in the app register.
What does Critical Cloud do with App Builder every month?
Under Managed Observability we review every published app against the register: whether it was opened, whether its connection and audience are still right, and whether the service it queries still exists under that name. Apps nobody uses are unpublished. Connections are checked for the narrowest working role. Under Critical Support, a button that does not clear the alert escalates to our on-call engineer through the workflow behind it.
- Datadog products: every product, and how we implement and run each one
- Workflow Automation: the sequence the app's button starts
- Service Management Accelerator: incidents, events, workflows, work items and apps in four weeks
One button, scoped, next to the graph.
Tell us which runbook step still says "ask someone with access". We will show you what it looks like as an app, what sits behind the button, and who should be allowed to press it.