Why Does GitLab Service Desk Say It "Can't Find the Project" When a Customer Emails In?
It happens because GitLab's mailroom found an address that looked like a Service Desk address but couldn't match the key inside it to any project it currently tracks, so it sent back its stock reply: "We couldn't find the project. Please check if there's any typo." That message reads like a typo problem, and support teams usually go check the address for one. Most of the time there isn't one. The address is spelled correctly and still doesn't resolve, because the thing GitLab actually looks up isn't the address a person reads, it's a key folded into it, and that key stopped pointing at a project.
The bigger issue is what happens next: nothing. The email isn't queued, isn't retried, and doesn't land as a draft anywhere inside GitLab. The customer gets a bounce that sounds like their own mistake, the report exists only in their sent folder, and unless someone happens to be watching that inbox for exactly this failure, it's gone.
A support inbox in the dark
Loop Metrics runs a small analytics product, and Callum Reyes handles support out of a GitLab project called platform-support, with a custom Service Desk suffix so the intake address reads contact+loop-platform-support@loopmetrics.io. It had worked fine for a year. Then Loop Metrics reorganized its GitLab groups, and platform-support moved from the top-level loop namespace into a new loop/infra group to sit next to the on-call tooling.
A customer emailed the same address two days later about a broken CSV export:
Customer: The weekly export button just spins now, nothing downloads. Started yesterday.
The customer got an automated reply almost immediately: "We couldn't find the project. Please check if there's any typo." Confused, since they'd emailed this same address for months, they forwarded it to their usual contact instead, assuming it was a Loop Metrics problem to sort out on a phone call. Callum never saw the original email. He found out about the export bug four days later, from a Slack message a sales rep forwarded after the customer complained on a call.
The key had already gone stale two days earlier, when the group moved. The customer's email just happened to be the first thing sent against it.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionWhat the address is actually built from
On GitLab.com, the default Service Desk address for every project is a variant of contact-project+%{key}@incoming.gitlab.com, where %{key} is what tells GitLab's mailroom which project to file the issue in, per GitLab's incoming email documentation. A custom Service Desk address works the same way but makes the key visible: GitLab's Service Desk configuration docs spell out the format as <project_full_path>-<custom_suffix>, so a project at loop/platform-support with the suffix support produces a key literally built from loop-platform-support-support. That path is generated once, when the custom address is set up. GitLab's docs don't say what happens to it after the project moves, but the format answers the question on its own: the key is a snapshot of the group and project path at that moment, not a live pointer that follows the project around.
A few other things have to be true before that key resolves to anything at all, and each one is a place this can quietly break:
- The project's issue tracker has to be enabled. GitLab's own Service Desk docs list this as a prerequisite for turning the feature on in the first place, not something monitored afterward. Disable Issues later, for a migration or a cleanup, and there's nothing left for Service Desk to file into.
- Someone with Maintainer or Owner access turned it on, and that's also the access level that can turn it back off, deliberately or by accident, during a permissions cleanup.
- Self-managed instances need incoming email configured instance-wide, either through sub-addressing or a catch-all mailbox. Without one of those set up, GitLab's docs note the Service Desk section doesn't even appear in project settings, which is a different symptom from a bounce but traces back to the same root cause. The mailroom has nowhere to route the email either way.
None of this shows up as a GitLab outage or a support-tool bug. Every piece is working exactly as documented. The project the key used to point at just isn't the project it points at anymore.
The other way this shows up
The rename-and-move case is the quiet one, because the address keeps working for weeks or months before anyone touches the project. There's a noisier version documented on GitLab's own forum: one admin ran two self-managed GitLab instances pointed at the same incoming mailbox. One instance recognized the project and filed the issue correctly. The other, with no matching project, fired back the exact "we couldn't find the project" bounce, on the same email, seconds apart. The fix there had nothing to do with the Service Desk address at all; it was giving each instance its own mailbox so only one of them ever saw the mail.
Both cases share a shape worth remembering: the failure looks like it's about the email address, and the actual cause is somewhere else, in a group structure, an instance's mail configuration, or a role change three weeks back that nobody connected to support.
Catching it before a customer does
A few checks close most of the gap:
- Send a test email to every active Service Desk address on a schedule, not just after a change. A monthly send from an address outside the company catches a broken key before a real customer does.
- Treat a project move or rename as a Service Desk event, not just a repo housekeeping task. If the project has a custom suffix address, regenerate and re-verify it as part of the move, the same day.
- Watch for the bounce pattern from your customers, not your inbox. The email never reaches GitLab, so GitLab has nothing to show you. The signal is a support ticket in another channel that says some version of "I emailed and heard nothing back."
- Audit who can enable and disable Service Desk per project the same way you'd audit any other access that support depends on, since GitLab ties it to the ordinary Maintainer and Owner roles rather than a dedicated support permission.
One project remembers to check. A dozen projects don't.
All four of those are manual habits, and they scale about as well as any manual habit does. One project with one support address, a small team can hold the mental model of "we moved a project, check the address" indefinitely. A handful of projects each with their own Service Desk address, spread across a company that reorganizes its GitLab groups every couple of quarters, and the check depends on someone remembering to run it every single time, forever.
That's the point where relying on GitLab's mailroom as the only path in stops making sense. Modem doesn't wait for an email to resolve to a project key at all. It reads the same GitLab activity through the GitLab integration directly, alongside Slack, email, and whatever support tool the team actually runs, and it identifies the customer and the topic by who's talking and what they said, not by a token baked into an address at setup time. Move the project, rename the group, reorganize the whole namespace, and the customer's report still lands in the same tracked topic, because nothing about it depended on the project's path staying still. We build Modem, so weigh that against the fact that the address-format brittleness described above comes straight from GitLab's own documentation, not from us.
The reply-threading version of this same fragility, where a moved issue breaks a customer's existing email thread instead of a fresh one, is covered in why GitLab Service Desk creates a new issue for every reply. For the process side of making sure a dropped report gets found regardless of which tool swallowed it, see how to close the feedback loop with customers.
Start with what already moved
Skip the exhaustive audit for a minute and pull up every project move, rename, or namespace reorg from the last two quarters. Test the Service Desk address for each one of those first, since that's where a broken key is already most likely sitting, not somewhere nobody's touched. If those all come back clean, work through the rest on the scheduled-test habit above, so the next reorg doesn't get a four-day head start on you the way this one did on Callum.
