Folders and files
| Name | Name | Last commit date | ||
|---|---|---|---|---|
Welcome to the Datadog documentation repository. The markdown stored in this repo is published to the Datadog documentation site using hugo, a static website generation tool.
Contributions are encouraged! If you notice something on one of the pages that needs an edit, open a pull request (PR) in this repo for the Documentation team to review. The Documentation team is added as a PR reviewer automatically.
Most pages on the documentation site feature an Edit button that sends you to the source file in this repo. You can make an edit straight from the GitHub website!
For more information on contributing, see the contribution guidelines.
Note
AI and content quality
The docs team are huge fans of AI tools like Claude Code and use them to generate content all the time. That said, we will always rely on human review to ensure that the content we publish continues to meet the high standard for quality we set for ourselves. If you submit a large AI-generated PR, remember that it takes time for us to think through how people take in and use information. It helps us if you can validate your content independently before submitting it, and plan your timelines accordingly so we can give your PR the attention it deserves.
Follow these steps if you are NOT a Datadog employee:
- Fork the master branch.
- Consult our contributing guidelines.
- When you're ready to finalize your changes, commit them and make a pull request back to DataDog/master.
- A Datadog technical writer might change your PR title with a DOCS ticket number, such as "[DOCS-9000]," which means it has been added to the team's internal Jira queue to triage and review. No action is necessary from you if we change the title of your PR.
Follow these steps if you are a Datadog employee:
- Always branch off of master; never commit directly to master.
- You MUST name your branch <name>/<description>. If you do not include the forward slash (/), the GitLab pipeline won't run, you won't get a branch preview, and your pull request will not pass in CI. Getting a branch preview makes it easier for us to check for any issues with your PR, such as broken links. Using a Slack username also ensures you get build notifications in Slack.
- Consult our contributing guidelines.
- When you're ready to commit, create a new pull request to master from your branch.
- Use GitHub's draft pull request feature and appropriate labels such as "Do Not Merge" or "Work in Progress" until your PR is ready to be merged and live on production.
- If you've named your branch correctly, a GitHub bot posts a link to the docs preview website for your PR. After the preview build completes, you can use the link to preview your changes.
- Running the build locally is optional. If you followed the branch naming conventions above, your pull request should generate a preview. For information on local builds, see the Build setup guide.
This site uses Goldmark for markdown, which is compliant with CommonMark 0.29.
If you include ANY Markdown in a file, give it a .md extension.
Make sure all files are lowercase. Macs are case-insensitive when creating links to images and pages, but our build server is not, so tests may work locally, but the site will fail in production.
Merging to master triggers an automatic deployment. This process typically begins within 10 minutes and usually takes around 35 minutes to complete, though these times may vary.