{"id":22048268,"url":"https://github.com/bauer-xcel-media/node-healthchecks-api","last_synced_at":"2026-03-08T19:36:12.287Z","repository":{"id":52512491,"uuid":"150031635","full_name":"Bauer-Xcel-Media/node-healthchecks-api","owner":"Bauer-Xcel-Media","description":"The Node.js implementation of the Health Checks API by Hootsuite","archived":false,"fork":false,"pushed_at":"2022-12-05T05:08:18.000Z","size":2637,"stargazers_count":27,"open_issues_count":29,"forks_count":12,"subscribers_count":7,"default_branch":"development","last_synced_at":"2025-04-16T07:45:26.309Z","etag":null,"topics":["healtcheck","health","health-check","health-checks","health-checks-api","healthchecks","hootsuite","microservice","microservices","node-js","nodejs"],"latest_commit_sha":null,"homepage":"","language":"JavaScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/Bauer-Xcel-Media.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2018-09-23T22:39:24.000Z","updated_at":"2024-08-21T05:18:24.000Z","dependencies_parsed_at":"2023-01-24T00:46:19.342Z","dependency_job_id":null,"html_url":"https://github.com/Bauer-Xcel-Media/node-healthchecks-api","commit_stats":null,"previous_names":[],"tags_count":7,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Bauer-Xcel-Media%2Fnode-healthchecks-api","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Bauer-Xcel-Media%2Fnode-healthchecks-api/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Bauer-Xcel-Media%2Fnode-healthchecks-api/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/Bauer-Xcel-Media%2Fnode-healthchecks-api/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/Bauer-Xcel-Media","download_url":"https://codeload.github.com/Bauer-Xcel-Media/node-healthchecks-api/tar.gz/refs/heads/development","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253160725,"owners_count":21863624,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["healtcheck","health","health-check","health-checks","health-checks-api","healthchecks","hootsuite","microservice","microservices","node-js","nodejs"],"created_at":"2024-11-30T14:09:44.507Z","updated_at":"2026-03-08T19:36:12.245Z","avatar_url":"https://github.com/Bauer-Xcel-Media.png","language":"JavaScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Health Checks for microservices\n\n[![npm version](https://badge.fury.io/js/healthchecks-api.svg)](https://badge.fury.io/js/healthchecks-api)\n[![GitHub (release)](https://img.shields.io/github/release/Bauer-Xcel-Media/node-healthchecks-api.svg)](https://github.com/Bauer-Xcel-Media/node-healthchecks-api/releases/latest)\n[![node (tag)](https://img.shields.io/badge/node-%3E=8.0.0-orange.svg)](https://github.com/Bauer-Xcel-Media/node-healthchecks-api/blob/2cadf9ad6e6efa529b4e543dc075c5679900b5f3/package.json#L35)\n[![Build Status](https://travis-ci.org/Bauer-Xcel-Media/node-healthchecks-api.png?branch=master)](https://travis-ci.org/Bauer-Xcel-Media/node-healthchecks-api)\n[![Commitizen friendly](https://img.shields.io/badge/commitizen-friendly-brightgreen.svg)](http://commitizen.github.io/cz-cli/)\n[![codecov](https://codecov.io/gh/Bauer-Xcel-Media/node-healthchecks-api/branch/master/graph/badge.svg)](https://codecov.io/gh/Bauer-Xcel-Media/node-healthchecks-api)\n[![semantic-release](https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg)](https://github.com/semantic-release/semantic-release)\n[![Waffle.io - Issues in progress](https://badge.waffle.io/Bauer-Xcel-Media/node-healthchecks-api.png?label=in%20progress\u0026title=In%20Progress)](http://waffle.io/Bauer-Xcel-Media/node-healthchecks-api)\n[![Known Vulnerabilities](https://snyk.io/test/github/Bauer-Xcel-Media/node-healthchecks-api/badge.svg)](https://snyk.io/test/github/Bauer-Xcel-Media/node-healthchecks-api)\n[![Greenkeeper badge](https://badges.greenkeeper.io/Bauer-Xcel-Media/node-healthchecks-api.svg)](https://greenkeeper.io/)\n\nA [Node.js](https://nodejs.org) implementation of the [Health Checks API](https://github.com/hootsuite/health-checks-api) provided by [Hootsuite](https://hootsuite.com/).\n\n\u003c!-- TOC --\u003e\n\n- [Health Checks for microservices](#health-checks-for-microservices)\n    - [Installation](#installation)\n    - [Functionality](#functionality)\n    - [Health status reports](#health-status-reports)\n    - [Usage](#usage)\n        - [Service details (`about` endpoint)](#service-details-about-endpoint)\n        - [Configuration](#configuration)\n        - [Initialization](#initialization)\n            - [Example - Express.js powered application](#example---expressjs-powered-application)\n    - [Check types](#check-types)\n        - [`self` check](#self-check)\n            - [Memory leak detection](#memory-leak-detection)\n        - [`http` check](#http-check)\n        - [`mongo` check](#mongo-check)\n        - [`redis` check](#redis-check)\n        - [`elasticsearch` check](#elasticsearch-check)\n        - [`mysql` check](#mysql-check)\n    - [Development](#development)\n        - [Framework adapters](#framework-adapters)\n        - [Developing new check types](#developing-new-check-types)\n            - [Create a custom check type class](#create-a-custom-check-type-class)\n            - [Add the check class to the module check type list](#add-the-check-class-to-the-module-check-type-list)\n            - [Exporting multiple check classes in a custom module](#exporting-multiple-check-classes-in-a-custom-module)\n    - [Testing](#testing)\n        - [Unit tests](#unit-tests)\n        - [Integration test](#integration-test)\n            - [The set-up](#the-set-up)\n            - [Running the test](#running-the-test)\n            - [Starting and stopping services](#starting-and-stopping-services)\n            - [Emulating high load and memory leak](#emulating-high-load-and-memory-leak)\n            - [Tearing down the set-up](#tearing-down-the-set-up)\n\n\u003c!-- /TOC --\u003e\n\n## Installation\n\n```bash\nnpm install --save healthchecks-api\n```\n\n## Functionality\n\nEnables an application/service combined Health Check view when used in the ecosystem of microservices.\nThis includes a service/application self check and following dependency checks:\n\n* `internal` (composed) - local service dependencies (eg. database, cache). Generally these are dedicated local services used only by subject service/application,\n* `external` (aggregated/associated) - usually another microservices in the ecosystem, which the subject service/application depends on.\n\nThe dependencies can be:\n\n* `critical` - the subject service/application is considered non-operational when such a dependency is non-operational,\n* `non-critical` - the subject service/application is partly operational even when such a dependency is non-operational, as it can still serve a subset of its capabilities.\n\n\u003e **NOTE**\n\u003e\n\u003e _The `critical/non-critical` dependency atribute is an additional (optional) semantic of **this module  only**._\n\u003e\n\u003e_[Health Checks API](https://github.com/hootsuite/health-checks-api) does not specify such._\n\u003e\n\u003e _Classifying a particular dependency as `non-critical` (`critical: false` attribute of a dependency configuration) results in reporting it being in a `WARN` state at the dependency owner level, when the dependency is reported being in either `WARN` or `CRIT` state at its own level._\n\u003e\n\u003e _Example configuration for `non-critical` dependency:_\n\u003e ```yaml\n\u003e checks:\n\u003e   - name: service-2\n\u003e     critical: false\n\u003e     check: http\n\u003e     url: http://service-2:3002\n\u003e ```\n\u003e _By default all dependencies are classified as `critical`._\n\nAnother dependency division is:\n\n* `traversable` - this means the dependency implements the [Health Checks API](https://github.com/hootsuite/health-checks-api) itself and therefore one can traverse to its `Health Check API endpoint` and check its own state together with its dependencies states.\n* `non-traversable` - the dependency health state is still reported by an appropriate check type, but the service does not implement the [Health Checks API](https://github.com/hootsuite/health-checks-api), therefore one cannot drill-down due to observe its internal state details.\n\n\u003e __NOTE__\n\u003e\n\u003e _The `traversable` dependency capability is resolved by this module in a runtime._\n\n## Health status reports\n\nThe health is reported in following states:\n\n* __OK__ -  _green_ - all fine ;)\n* __WARN__ - `warning` - _yellow_ - partly operational, the issue report available (description and details).\n* __CRIT__ - `critical` - _red_ - non-operational, the error report available (description and details).\n\nThe overall health state of the subject service/application is an aggregation of its own state and its dependencies state. Aggregation is done with a respect to following (the order matters!):\n\n* when there is (are) any `red` (_critical_) state (either the subject service/application state or any of its dependencies states) first found `red` state is reported as the resulting overall state (with its description and details),\n* when there is (are) any `yellow` (_warning_) state (either the subject service/application state or any of its dependencies states) first found `yellow` state is reported as the resulting overall state (with its description and details),\n* The overall subject service/application state is `green` only when its self-check and __all__ of its dependencies are `green`.\n\n## Usage\n\nThe module works as a middleware, exposing the [Health Checks API](https://hootsuite.github.io/health-checks-api/) routes via chosen `http server` framework routing system.\n\n### Service details (`about` endpoint)\n\nThe [Health Checks API `about` endpoint](https://hootsuite.github.io/health-checks-api/#status-about-get) is supposed to describe the underlying service using this module.\nThe module takes particular service description attributes either from the [Configuration](#configuration) or mapping them from the service's [package.json](https://docs.npmjs.com/files/package.json) as a fallback. When particular attribute is missing both in the service config and in `package.json` a default value is taken, when provided.\n\nHere is the table with particular fields, their mapping to config attributes and fallback mapping to `package.json` and optional defaults:\n\n| _Attribute name_ | _Config attribute name_ | _`package.json` fallback - attribute  mapping_ | _Static or dynamic fallback (defaults)_ |\n|------------------|-------------------------|------------------------------------------------|-----------------------------------------|\n| id               | name                    | name                                           | -                                       |\n| name             | name                    | name                                           | -                                       |\n| description      | description             | description                                    | -                                       |\n| version          | version                 | version                                        | 'x.x.x'                                 |\n| host             | host                    | -                                              | require('os').hostname()                |\n| protocol         | protocol                | -                                              | 'http'                                  |\n| projectHome      | projectHome             | homepage                                       | -                                       |\n| projectRepo      | projectRepo             | repository.url                                 | 'unknown'                               |\n| owners           | owners                  | author + contributors                          | -                                       |\n| logsLinks        | logsLinks               | -                                              | -                                       |\n| statsLinks       | statsLinks              | -                                              | -                                       |\n| dependencies     | checks                  | -                                              | -                                       |\n\n\u003e __NOTE__\n\u003e\n\u003e _The final value is resolved with a fallback from left to right, as presented in above table._\n\n### Configuration\n\nThe module configuration is a single `yaml` file and represents the subject service/application context.\nThe default path for the config file is `./conf/dependencies.yml`.\n\nAn example config:\n\n```yaml\nversion: \"3.1\"\n\nname: demo-app\ndescription: Nice demo application :)\n\nchecks:\n  - check: self\n    memwatch: memwatch-next\n\n  - name: mongo\n    url: mongodb://mongo/test\n    type: internal\n    interval: 3000\n    check: mongo\n\n  - name: service-1\n    url: http://service-1:3001\n    type: external\n    interval: 1000\n    check: http\n\n  - name: service-2\n    url: http://service-2:3002\n    type: external\n    critical: false\n    interval: 1000\n    check: http\n```\n\n\u003e **NOTE**\n\u003e\n\u003e _Alternatively the configuration can be passed directly to the module initialization as an `options.service.config` attribute object value:_\n\u003e\n\u003e ```javascript\n\u003e const healthCheck = require('healthchecks-api');\n\u003e const express = require('express');\n\u003e const app = express();\n\u003e await healthCheck(app,\n\u003e        {\n\u003e            adapter: 'express',\n\u003e            service: {\n\u003e                config: {\n\u003e                   name: 'demo-app',\n\u003e                   description: 'Nice demo application :)',\n\u003e                   statsLinks: [ 'https://my-stats/demo-app' ],\n\u003e                   logsLinks: [ 'https://my-logs/demo-app/info', 'https://my-logs/demo-app/debug' ],\n\u003e                   checks: [\n\u003e                       {\n\u003e                           name: 'mongo',\n\u003e                           url: 'mongodb://mongo/test',\n\u003e                           type: 'internal',\n\u003e                           interval: 3000,\n\u003e                           check: 'mongo',\n\u003e                       },\n\u003e                       {\n\u003e                           name: 'service-1',\n\u003e                           url: 'http://service-1:3001',\n\u003e                           interval: 1000,\n\u003e                           check: 'http',\n\u003e                       }\n\u003e                    ]\n\u003e                },\n\u003e            },\n\u003e        })\n\u003e```\n\n### Initialization\n\nThe library initialization depends on chosen `http server` framework, but in any case this will be about 2 lines of code.\nSee the examples below.\n\n#### Example - Express.js powered application\n\nSee: [Express.js framework](https://expressjs.com/).\n\n```javascript\nconst healthCheck = require('healthchecks-api');\n\nconst startServer = async () =\u003e {\n    const app = express();\n    // some initialization steps\n\n    await healthCheck(app);\n    // rest of initialization steps\n}\n\nstartServer();\n\n```\n\n## Check types\n\nFollowing check types are supported:\n\n### `self` check\n\nThe service/application check for its own health.\nIt checks the `CPU` and `Memory` consumption [%] and verifies them against given alarm levels:\n\nExample config:\n\n```yaml\nchecks:\n  - check: self\n    memwatch: memwatch-next\n    secondsToKeepMemoryLeakMsg: 60\n    metrics:\n      memoryUsage:\n        warn: 90\n        crit: 95\n      cpuUsage:\n        warn: 50\n        crit: 80\n```\n\n#### Memory leak detection\n\nAdditionally this check can listen and react to a `memory leak` event leveraging the [memwatch-next](https://www.npmjs.com/package/memwatch-next) library or one of its ancestors/descendants.\nDue to provide this functionality set the `memwatch` property to the name of the library in NPM, as shown in the example config above.\n\nThe linked library must provide the `leak` event as in the example below:\n\n```javascript\nconst memwatch = require('memwatch-next');\nmemwatch.on('leak', function(info) { ... });\n```\n\n### `http` check\n\nThe health check for a linked `HTTP` service, usually an `API` provider.\n\nExample config:\n\n```yaml\nchecks:\n  - check: http\n    name: service-2\n    url: http://service-2:3002\n    method: get # default\n    type: external # default\n    interval: 3000 # default [milliseconds]\n    critical: true # default\n```\n\nChecks whether the service responds at given `url`.\nDetermines whether it is `traversable` (will work only when given method is `get`) and resolves aggregated service state when so.\n\n### `mongo` check\n\nChecks the availability of the [Mongo DB](https://www.mongodb.com/) instance at given `url`.\n\nExample config:\n\n```yaml\nchecks:\n  - check: mongo\n    name: mongo\n    url: mongodb://mongo/test\n    type: internal\n    interval: 3000\n```\n\n### `redis` check\n\nChecks the availability of the [Redis](https://redis.io/) instance at given `url`.\n\nExample config:\n\n```yaml\nchecks:\n  - check: redis\n    name: redis\n    url: redis://redis\n    type: internal\n```\n\n### `elasticsearch` check\n\nChecks the availability of the [Elasticsearch](https://www.elastic.co/products/elasticsearch) instance at given `url`.\n\nExample config:\n\n```yaml\nchecks:\n  - check: elasticsearch\n    name: elasticsearch\n    url: elasticsearch:9200\n    type: internal\n```\n\n### `mysql` check\n\nChecks the availability of the [MySQL](https://www.mysql.com/) instance at given `url`.\n\nExample config:\n\n```yaml\nchecks:\n - name: mysql\n    url: mysql\n    type: internal\n    interval: 3000\n    check: mysql\n    user: root\n    password: example\n    database: mysql\n```\n\n\u003e **NOTE**\n\u003e\n\u003e _The `url` config property maps to the `host` property of the [mysql connection options](https://www.npmjs.com/package/mysql#connection-options)._\n\n## Development\n\nContribution welcome for:\n\n* check types\n* framework adapters\n\nPRs with any improvements and issue reporting welcome as well!\n\n### Framework adapters\n\nThe module is designed to operate as a middleware in various `http` based [Node.js](https://nodejs.org) frameworks.\nCurrently supported frameworks are:\n\n* [Express.js](https://expressjs.com/)\n\nA particular framework implementation is an adapter exposing a single method.\n\nHere's the example for the [Express.js](https://expressjs.com/) framework:\n\n```javascript\n/**\n * Adds a particular Health Check API route to the `http` server framework.\n * The route is one of these difined by the {@link https://hootsuite.github.io/health-checks-api/|Health Checks API} specification.\n * The implementation should call given `route.handler` due to receive a response data.\n * The route handler takes combined request parameters and the service descriptor (usually `package.json` as an object) as the parameters\n * and returns the object with the response data (`status`, `headers`, `contentType` and `body`).\n * \n * @async\n * @param {Object} service      - The service/application descriptor (usually a package.json);\n * @param {Object} server       - The Express.js application or Route.\n * @param {Object} route        - The Health Check API route descriptor object.\n * @param {string} route.path   - The Health Check API route path.\n * @param {Function} route.path - The Health Check API route handler function.\n * @returns {Promise}\n */\nconst express = async (service, server, route) =\u003e {\n    // 1. Expose given route in the `http` server application, here an example for the `Express.js`:\n    return server.get(path.join('/status', route.path), async (req, res, next) =\u003e {\n        try {\n            // 2. Combine the `Express.js` route parameters:\n            const params = Object.assign({}, req.params, req.query, req.headers);\n            // 3. Call given `route.handler` passing combined parameters and given service descriptor:\n            const result = await route.handler(params, service);\n            // 4. Decorate the `Express.js` response:\n            res.status(result.status);\n            res.set('Content-Type', result.contentType);\n            res.set(result.headers);\n            // 5. Return the response body according to given `contentType`:\n            switch (result.contentType) {\n                case constants.MIME_APPLICATION_JSON:\n                    res.json(result.body);\n                    break;\n                default:\n                    res.send(result.body);\n            }\n        } catch (err) {\n            // 6. Deal with the Error according to `Express.js` framework rules.\n            next(err);\n        }\n    });\n};\nmodule.exports = express;\n```\n\nAn adapter can be declared as follows:\n\n```javascript\nconst healthChecks = require('healthchecks-api');\n\n(async () =\u003e {\n    // The default is 'express' adapter, when not declared:\n    await healthChecks(myServer);\n\n    // An internally supported adapter:\n    await healthChecks(myServer, {\n        adapter: 'express',\n    });\n\n    // A module from an npm registry - must export a proper function.\n    await healthChecks(myServer, {\n        adapter: 'my-adapter-module',\n    });\n\n    // An adapter function declared directly:\n    await healthChecks(myServer, {\n        adapter: async (service, server, route) =\u003e {\n            // your adapter implementation details\n        }\n    });\n})();\n```\n\n### Developing new check types\n\n#### Create a custom check type class\n\nA custom check class must extend the `Check` class and implement the asynchronous `start()` method. The method is supposed to perform the actual check. When the check is performed in intervals (pull model) then the class should use derived `this.interval` [ms] property, which can be set in the `yaml` configuration (default is `3000 ms`).\n\n```javascript\nconst healthChecks = require('healthchecks-api');\nconst Check = healthChecks.Check;\n\nclass MyCheck extends Check {\n    constructor(config) {\n        super(config);\n        // this.config contains the properties from the `yaml` check config part.\n        if (this.config.myProperty) {\n            // ...\n        }\n        // class initialization code\n    }\n\n    async start() {\n        // actual check code to be executed in `this.interval` [ms] intervals.\n        // ...\n        // set up the resulting state:\n        this.ok(); // | this.warn(description, details); | this.crit(description, details);\n    }\n}\n// This is optional - by default the new check type will be the class name in lowercase.\n// One can change that by following line.\nMyCheck.type = 'mycheck'; // the default\n```\n\n**NOTE:** The check `name` to be used in `yaml` configs is by default the class name in lowercase.\n\n_See the particular checks implementations for reference - `./lib/checks/*`._\n\n#### Add the check class to the module check type list\n\nAdditional check types (classes) are to be declared in runtime, before starting creating the health checks routes. Here's the example:\n\n```javascript\nconst healthCheck = require('healthchecks-api');\nconst myCheck = require('./lib/my-check.js');\n\nconst startServer = async () =\u003e {\n    const app = express();\n    // some initialization steps\n\n    await healthCheck.addChecks(myCheck);\n\n    await healthCheck(app);\n    // rest of initialization stepa\n}\n\nstartServer();\n```\n\nUse the new check type in your `yaml` configurations:\n\n```yaml\nversion: \"3.1\"\n\nname: demo-app\ndescription: Nice demo application :)\n\nchecks:\n  - check: mycheck\n    # properties are accessible in the class instance property `config` - eg. `this.config.myProperty`.\n    myProperty: value\n```\n\n#### Exporting multiple check classes in a custom module\n\nCheck classes can be bundled into a module and optionally published in private or public `NPM` registry for reusability.\nThe module must export allowable value for the this module's `addCkecks` method.\nThe `addChecks` method can take a value of following parameter types as an argument:\n\n* single `Check` class extension,\n* array of `Check` class extension classes,\n* object instance - a map with a key representings a check name (type) and value being a `Check` class extension class.\n* module name to link from `NPM` registry. The module must export one of above.\n\n## Testing\n\n### Unit tests\n\n[![codecov](https://codecov.io/gh/Bauer-Xcel-Media/node-healthchecks-api/branch/master/graph/badge.svg)](https://codecov.io/gh/Bauer-Xcel-Media/node-healthchecks-api)\n\nRun unit tests locally:\n\n```shell\nnpm test\n```\n\n### Integration test\n\nThe integration test is a [Docker Compose](https://docs.docker.com/compose/) based setup.\nThe setup shows the `health-check-api` functionality reported by [Microservice Graph Explorer](https://github.com/hootsuite/microservice-graph-explorer) - the dashboard-like application which presents service dependencies and their health status and allows to traverse dependencies which expose [Health Checks API](https://hootsuite.github.io/health-checks-api/).\n\nOne can observe changing `health status` of the `demo-app` application by:\n\n* stopping and starting particular services,\n* emulating high load to a particular `http` service,\n* emulating memory leak in particular `http` service.\n\n#### The set-up\n\n* `explorer` - [Microservice Graph Explorer](https://github.com/hootsuite/microservice-graph-explorer) instance,\n* `demo-app`, `service-1`, `service-2` and `service-3` - instances of [Express.js](https://expressjs.com/) based applications exposing the [Health Checks API](https://hootsuite.github.io/health-checks-api/) endpoints by the usage of this module,\n* `service-4` - an `http` service which does not expose the `Health Checks API`,\n* `mongo` - [Mongo DB](https://www.mongodb.com/) instance,\n* `elasticsearch` - [Elasticsearch](https://www.elastic.co/products/elasticsearch) instance,\n* `redis` - [Redis](https://redis.io/) instance.\n\n\u003e **NOTE**\n\u003e\n\u003e _The `service-2` is classified as `non-critical` for the `demo-app` so it will be reported as `WARN` at the `demo-app` dashboard even if it gets the `CRIT` state._\n\n#### Running the test\n\n```bash\ncd ./test/integration\nmake up\n```\n\nThis will build and start the `docker-compose` services and open the [Microservice Graph Explorer](https://github.com/hootsuite/microservice-graph-explorer) in the default browser at [http://localhost:9000/#/status/http/demo-app:3000](http://localhost:9000/#/status/http/demo-app:3000).\n\n#### Starting and stopping services\n\n```bash\nmake stop SERVICE=service-2\nmake stop SERVICE=mongo\n\nmake start SERVICE=service-2\nmake start SERVICE=mongo\n```\n\n#### Emulating high load and memory leak\n\nFollowing example commands use the `localhost:$PORT` urls.\nPort mapping to services:\n\n* 3000 - `demo-app`\n* 3001 - `service-1`\n* 3002 - `service-2`\n* 3003 - `service-3`\n* 3004 - `service-4`\n\nOne can use the [Apache Benchmark](http://httpd.apache.org/docs/2.4/programs/ab.html) tool for emulating a high load to an `http` service, eg:\n\n```bash\nab -n 10000 -c 20 http://localhost:3001/heavy\n```\n\nTo emulate the memory leak execute following:\n\n```bash\ncurl http://localhost:3000/make-leak\n```\n\n#### Tearing down the set-up\n\n```bash\nmake down\n```\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbauer-xcel-media%2Fnode-healthchecks-api","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fbauer-xcel-media%2Fnode-healthchecks-api","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbauer-xcel-media%2Fnode-healthchecks-api/lists"}