Dependency Watch is for the risk that arrives without anybody doing anything: a dependency picks up a security advisory, a third-party API deprecates an endpoint you call, a certificate or a major version is about to lapse. It is an add-on, enabled under Settings → Add-ons.
A daily job checks every dependency on record against OSV.dev, the open vulnerability database, and raises a finding for anything affected. This runs whether a repository's dependencies got on record by connecting GitHub or by pasting a manifest — the scan itself does not care which.
A repository showing 0 dependencies recorded has not had anything read for it yet — an empty findings feed for it means "not looked", not "nothing wrong". Check the dependency count and last-scanned time on the Repositories list before reading anything into a clean feed.
Click Connect GitHub and you land on GitHub's own install screen, where you choose your account or organization and grant it either all repositories or a specific selection — nobody registers anything or handles credentials themselves; that already happened once for the whole workspace.
Back in Time Trakkr, pick which of the granted repositories to actually watch — a repository your installation can read is not automatically scanned; you choose the subset here. Manifests for a connected repository are then fetched automatically ahead of each daily scan, so nothing needs pasting for it again.
Disconnecting removes the connection and falls each connected repository back to the manual manifest-paste path — it does not stop watching them or delete their findings.
If Connect GitHub doesn't appear, no GitHub App is registered for this Time Trakkr deployment yet — see "For whoever administers this deployment" below.
Register a repository by its owner/name (e.g. acme/website) under the plain "Watch repository" form. Registering the same one twice does not duplicate it. This is what "Connect GitHub" does automatically for the repositories you pick there; typing one in by hand works identically, minus the automatic manifest fetch.
Under Submit a manifest, paste the contents of a dependency file for a watched repository — package.json, package-lock.json, requirements.txt, pyproject.toml, or go.mod. It is parsed immediately and the repository's dependency count updates. Not needed for a repository connected via GitHub — that refreshes on its own.
Resubmitting the same file replaces what was on record for it. If a package is removed from the manifest you paste, it disappears from Dependency Watch too, rather than lingering and getting scanned forever after you have actually removed it.
A line the parser cannot make sense of is reported back rather than silently dropped or failing the whole submission; everything else in the file is still recorded.
You can record a provider, its API host, and its published spec or changelog under Providers. API-drift monitoring is not connected yet: provider entries are recorded, but they are not checked and will not produce API-drift findings.
"Connect GitHub" is only possible once, for the whole platform — not per workspace. If it isn't showing up, here is what to create:
GITHUB_APP_ID, GITHUB_APP_SLUG and GITHUB_PRIVATE_KEY environment variables — GITHUB_APP_ID/GITHUB_PRIVATE_KEY on the worker service (so the daily scan can fetch manifests), and all three on the web service (so "Connect GitHub" and the repository picker work).Once those are set, every workspace on this deployment can connect for itself — nothing further to configure per workspace.
Findings carry a kind (security advisory, dependency update, breaking API change, API deprecation), a severity, and a status you can move through as you deal with them.
Severity is derived, never supplied. It is calculated from the kind of finding and the size of the version change, so nothing can downgrade a security advisory into routine noise on the way in.
A finding that recurs reopens. If a finding was marked Resolved or Won't fix and the same problem is found again on a later scan, it moves back to New rather than staying silently closed — a closed status must not go stale while the thing it described is back.
Ownership routing. A finding can be assigned automatically, preferring in order: somebody who recently committed to that repository on that project, then any recent committer, then a member of the project, then the department lead, and finally unassigned. This is where the People add-on earns its keep — the GitHub username on somebody's employee profile is what turns a commit author into a person, and from there into a project and a department.
Anyone in the workspace can move a finding to acknowledged or in progress. Somebody picking up a problem should not have to ask permission to say they are on it.
Closing it requires a manager. Resolved and Won't fix take a finding out of the default feed, so those are a manager's call — otherwise a critical advisory could be quietly retired by anybody who found it inconvenient.
When a dependency version change is classified, 0.x releases are treated more cautiously than semantic versioning alone would suggest: below 1.0, a minor bump is treated as potentially breaking, and below 0.1 even a patch is. This matches how pre-1.0 libraries actually behave rather than how they promise to.
Repository contents are never copied into Time Trakkr wholesale. Only the dependency declarations parsed out of a manifest — package name, ecosystem, and the version range as declared — are kept, along with the fact that you are watching the repository.
The assistant can list findings and watched repositories, register a new repository, and move a finding to acknowledged, in progress, resolved, or won't-fix — the same rules apply as in the app (closing a finding needs a manager or above). Submitting a manifest is a page action, not something to paste through chat.
Updated 2026-08-03. Still stuck? Contact support or return to the Help Center.