Skip to content user documentation
Branch: develop
Clone or download
Type Name Latest commit message Commit time
Failed to load latest commit information.
.github GitHub templates update (#195) May 21, 2019
_source add quick intro to the jenkins page (#194) May 21, 2019
scripts JS to node (#190) May 20, 2019
shipping-config-samples Log shipping (#45) Apr 24, 2019
.gitignore JS to node (#190) May 20, 2019 fix typo in code of conduct Jan 27, 2019
Gemfile Docs testing (#138) Mar 5, 2019
Gemfile.lock Docs testing (#138) Mar 5, 2019 Log shipping (#45) Apr 24, 2019
_config.yml Zipkin shipping (#178) May 20, 2019 Conditionalize robots.txt (#150) Mar 18, 2019
gulpfile.js JS to node (#190) May 20, 2019
netlify.toml Conditionalize robots.txt (#150) Mar 18, 2019
package-lock.json JS to node (#190) May 20, 2019
package.json Docs testing (#138) Mar 5, 2019 Docs

Welcome to the source repo for Docs!

Our site is built on Jekyll. We merge the develop branch as needed. Docs are released to from master.



Please follow the Setup instructions so you can start.

Make all pull requests to the develop branch.

If you just want to submit a quick edit suggestion, you can open an issue.

Please preview your changes locally before submitting pull requests.

What pull requests we can't merge

We need to reject any pull requests that include these changes:

  • Changes to our OpenAPI file
  • Changes to our config file
  • Changes to another contributor's information

If you want to suggest a change or report an error in any of these files, please open an issue.

Please note we reserve the right to decline or change a pull request for any reason.

Community guidelines

Please review the Community Code of Conduct


If you haven't contributed to logz-docs before, follow these steps to get started.

Join GitHub if you don't already have an account.

Install dependencies:

  1. Git

  2. macOS: Xcode

  3. macOS: Xcode command line tools: xcode-select --install.

  4. RVM with Ruby: curl -sSL | bash -s stable --ruby

  5. macOS: Homebrew: /usr/bin/ruby -e "$(curl -fsSL"

  6. Bundler: sudo gem install bundler

  7. Fork the logz-docs repository

  8. Clone your fork, checkout the develop branch, and add logzio/logz-docs as your upstream repo:

    git clone<your_github>/logz-docs.git
    cd logz-docs
    git checkout develop
    git remote add upstream
    git fetch upstream
  9. Jekyll: sudo gem install bundler jekyll

  10. Install logz-docs Ruby gems: sudo bundle install

Changes and pull requests

We use develop as the main branch. Our site is automatically deployed when we merge develop to master.

For you, this means that you should create new branches from develop and make your changes there. You should also regularly sync your fork with the upstream repo (logzio/logz-docs) so that we can merge your changes without any problems.

So the ideal process looks a little like this:

Sync ➜ New branch ➜ Changes ➜ Preview ➜ Push ➜ Pull request

Syncing your fork

Keeping your fork up to date allows us to easily merge your changes. This is a pretty simple process.

To sync your fork:

  1. Open a terminal window and cd into your logz-docs folder.

  2. Checkout your local develop branch, pull the logzio/logz-docs develop branch, and push the updates to your fork:

    git checkout develop
    git pull upstream develop
    git push

Previewing locally

Before submitting pull requests, preview your changes locally. This does a few things to help you catch mistakes:

  • Seeing the formatted text, outside of a text editor and without all the markup, gives you a fresh look at your content.
  • You can be sure that your Markdown is formatted correctly and converts to HTML just as you meant it to.

We ask that you check your work for errors and readability.

To preview locally:

  1. Run ./preview.

  2. Point your browser to http://localhost:4000/. (Don't worry about the ducks. They're just there to tell you this is a local preview and not on the web.)

Making your first pull request

We like to give contributors credit for their work, so go ahead and add yourself as a contributor in your first pull request.

To add yourself as a contributor:

  1. Find the contributors folder on your machine at logz-docs/_source/logzio_collections/_contributors. Add a new Markdown file, named <your-github-username>.md.
    So if your GitHub username is agrant, your file is named This is your identifier when you contribute to docs.

  2. Copy this YAML content to the file, and add your information. If something doesn't apply to you, delete the line that doesn't apply:

    title: <your name>
    website: <your website url>
    linkedin: <your linkedin username>
    twitter: <your twitter handle>
    github: <your github username>

    Don't add any other content to the file.

  3. Save and commit.

  4. Include this file in your first pull request. If you're authoring a file, add your identifier (GitHub username) to the contributors list.
    So if your username is chaostheory, you'll add - chaostheory to the file's contributors list.

Working in Markdown docs use kramdown-flavored Markdown. Where possible, avoid HTML tags.

Some notes:

  • Leave a blank line between text blocks.
  • Indents are two spaces (not tabs). To nest blocks in a list, indent twice (four spaces). This keeps nested items from breaking a list.
  • You can put Markdown formatting in an HTML container, but please preview your code locally to make sure nothing unexpected is happening with the HTML conversion.


  • Use ## through ##### (h2 through h5) for normal headings.
  • Use ###### (h6) to introduce procedures and how-tos.
  • Our template reserves # (h1) for page titles. Don't use.


  • We don't have a strict style for procedures, except to make them as simple as possible.
  • Avoid long procedures. If your procedure has more than 10 steps, shorten it, or break it apart into multiple procedures.
  • You can use ordered and unordered lists in procedures. Lists can be nested two levels deep.
  • Nest other blocks in the second level by indenting the block another level. This keeps nested blocks from breaking lists.

Info boxes

Info boxes need a <div class="info-box"> container.

Info boxes come in three CSS classes: note, tip, important, warning. CSS handles the styling and adds a header.

Indent content on its own lines between the <div> tags.


<div class="info-box note">
  Notes are generally non-actionable. They’re more important
  than the surrounding text but less important than
  warnings. Could something bad happen if the user ignores
  this? If no, then it’s a note. Otherwise, it’s an important note.


<div class="info-box tip">
  Pro tips convey best practices and good actions to ensure
  success. Think of these as more proactive than important notes.

Important notes

<div class="info-box important">
  Important notes help the user work through common trip-up points.
  If the user could cause damage by ignoring the important note,
  consider a warning instead.


<div class="info-box warning">
  Use warnings when the user could cause damage that’s
  difficult or impossible to recover from. If you need
  something less severe than a warning, consider an important note
  or a note.

Code highlighting

Surround inline code samples with a single backtick: `code sample`

Jekyll supports syntax highlighting for code blocks if you say what the code actually is.

For example, for HTML:

<i class="fas fa-dove"></i>

<div class="info-box note">
  This is a note.

Credits and contributors

We invite contributions to docs, and we maintain a list of contributors at the Docs site.

Open source software used in Docs

You can’t perform that action at this time.