Eddie Blomkvist
Yes, monday.com can be connected to GitHub. With the integration, a bug reported in monday.com becomes an issue in the right repo, the status on the item follows the pull request from opened to merged, and project managers and account managers can see where a delivery stands without opening GitHub. monday.com has its own GitHub integration in the Integrations Center, and it covers the most common flows. If you need more, for example releases that update the customer's item or conditions that depend on other systems, the rest is built in Make. This article covers what the integration does, how it is built and what to consider before you get started.
- A ticket is marked as a bug on the support board
- An issue is created in the right repo with the ticket description
- The developer picks up the issue in GitHub
- The ticket status follows the issue
Support reports in monday.com, the developers work in GitHub, and support sees when the bug is fixed.
- The developer creates a pull request with the item ID in the title
- The status in monday.com becomes In review
- Router · Merged?YesStatus becomes Done and the item is tagged with the versionNoIt stays until the review is finished
- The project manager sees the status without opening GitHub
The status changes when something actually happens in the code, not when someone remembers to update the board.
- A release is published in GitHub
- Linked items get the release version
- The account manager gets the list of what is included
The account manager can tell the customer what has been delivered, based on what is actually in the release.
- A customer requests a feature through the CRM board
- The product owner approves
- An issue is created and linked to the item
- The customer is notified when the issue is closed
Requests move from sales through product to development, and back to the customer, without getting lost.
The flows above are only examples. Every integration is built around your process: which steps to include, what should happen in each situation and who is responsible for what.
Short answer
monday.com has its own GitHub integration in the Integrations Center. With it, you can create issues from items, change status when an issue is created, labeled or changes status, when a pull request is created or merged and when a branch is created, and link items to pull requests and issues using the item ID. In monday dev, the GitHub app shows pull requests, issues, branches and commits directly on the item. For flows that go beyond the recipes, for example releases that update the customer's item or conditions that depend on other systems, the integration is built in Make, which has modules for both monday.com and GitHub. That combination is what we build most often.
What the integration can do
Here are four common examples. Your integration can do more, less or something entirely different.
A bug or request in monday.com becomes an issue in the right repo, with description, labels and a link back to the item. Support or the product owner does not need access to GitHub.
When an issue changes status or a pull request is created or merged, the status in monday.com changes. The board shows what is actually happening in the code.
In monday dev, linked pull requests, issues, branches and commits show directly on the item, so anyone wondering why something is stuck can see it without asking.
When a release is published, linked items can be tagged with the version, and account managers can see what is included in what was delivered.
Why connect monday.com and GitHub?
- Developers stop reporting twice. The work happens in GitHub, and the board is updated by what happens in the code.
- The rest of the company sees the status. Support, sales and leadership follow delivery in monday.com without needing a GitHub account or knowing their way around it.
- Nothing falls between the systems. Bugs and requests reported in monday.com reach development, and the answer comes back.
- Better data. Lead times, open bug counts and what goes into a release are based on real events, not manual updates.
How the integration is built
There are three ways to build it, and which one fits depends on how advanced the flow is.
| Option | Best when | Keep in mind |
|---|---|---|
| monday.com's GitHub integration | The common flows: issue from an item, status that follows issues and pull requests, linking through the item ID | Quick to get started with no third party, but the recipes are fixed and require the GitHub app to be installed on your repos with the right permissions |
| Make | Flows beyond the recipes, for example releases that update the customer's item, issues created with conditions from the CRM, or several repos with different rules | Flexible, but requires a well-designed flow: how items and issues are matched, how exceptions are handled and how errors are caught |
| Custom code against the GitHub API | Large volumes, custom build pipelines or requirements the platforms cannot handle | The most flexible, but requires someone to own and maintain the code |
For most companies, monday.com's own integration covers the basics, with Make for whatever goes beyond. But the tool is just the tool. What determines whether the integration holds up is how it is built: how items and issues are linked so the right item is updated, how statuses in monday.com map to what happens in GitHub, what happens to items with several pull requests, and how errors are caught. An integration that works on one repo but silently misses the other costs more than it saves. That is why we build with logging and alerts from the start, and manage the integration as the way you work changes. Integrations in monday.com require a plan that includes integrations, and the GitHub app needs read and write permissions on the repos being connected.
What to decide before you build
An integration is never better than the process it automates. These questions determine whether it works in practice:
- What should become an issue? All bugs, only approved ones, or only those the product owner passes on? Decide which status in monday.com creates the issue and who is allowed to set it.
- How are items and code linked? The item ID in the pull request title or description is what monday.com supports. Agree that developers always use it, otherwise changes end up on the wrong item or none at all.
- Which statuses should follow the code? Map open, in review, merged and released to your statuses, and decide what happens when an item has several pull requests.
- Which repos are included? Different products can have different rules. Decide per repo what should be connected and to which board.
- What happens when something goes wrong? A good flow logs every run and flags when an issue could not be created or an item could not be found.
monday dev and GitHub share the work
monday dev is monday.com's product for development teams, with sprints, roadmaps and bug tracking, and that is where the GitHub integration adds the most value. Developers work in GitHub, sprint planning and prioritization happen in monday dev, and the item shows pull requests, branches and commits from GitHub. We describe how we set up monday dev on monday dev. The integration gets even stronger when support and sales are involved: tickets from monday service become issues, and what gets delivered shows on the CRM board. Leadership follows delivery in dashboards based on real events in the code, which we describe in Dashboards leadership actually uses. Many teams add Slack for notifications when something is merged. All the integrations we build are listed under all integrations.
Straviont builds the integration
We are an official monday.com partner and certified CRM specialists with monday.com, and we set up monday dev and the integration with GitHub, using Make where the recipes fall short. We start with the process: what should become an issue, how items and code are linked and which statuses should follow the code. Only then is the flow built, with logging and error handling, and we manage it as the way you work changes.
Frequently asked questions
Can monday.com be connected to GitHub?
Yes. monday.com has its own GitHub integration in the Integrations Center that creates issues, follows issues and pull requests and links items to code through the item ID. For flows beyond the recipes, the integration is built in Make or with custom code against the GitHub API.
Can a bug in monday.com become an issue in GitHub automatically?
Yes. When an item gets a certain status, an issue can be created in the repo you chose, with the item's description. The issue is linked to the item, so the status in monday.com follows the issue.
Can the status in monday.com follow a pull request?
Yes. When a pull request is created or merged, the status on the linked item can change. The link is made through the item ID in the pull request title or description.
Do pull requests and commits show in monday.com?
Yes, in monday dev. The GitHub app shows pull requests, issues, branches and commits linked to the item, with status, author and reviewers.
Does everyone need a GitHub account?
No. Support, sales and leadership work in monday.com, and whatever is relevant from GitHub shows there. Only the developers need GitHub.
What do we need to connect the systems?
A monday.com account on a plan with integrations, the GitHub app installed with read and write permissions on the repos being connected, and a Make account if you need flows beyond the recipes.
Next steps
Start by describing the flow from reported bug to delivered release: who reports, who prioritizes and which statuses should follow the code. From there, building it goes quickly. If you want help, you can book a free mapping session and we will go through it together.