A release log is useful when it preserves the source and separates fetched information from a human decision. Use n8n to fetch a GitHub release and store it in NocoDB, but look for an existing record before creating a row. Use the repository plus GitHub’s release ID as the match key, and set Needs review only when creating a new row.

Define the table and its match key

This is a workflow design to build and test on your own instance. Node labels and available filter controls can vary by version. Create these columns before wiring the automation; keep the source fields separate from the review fields.

Column	Value to store
Release key	Owner/repository + a separator + the release id, stored as text.
Repository	The configured owner/repository; normalize the spelling consistently.
Version	tag_name, not the optional display name.
Published	published_at.
Release notes	body; handle an empty value.
Source link	html_url.
Review status	Needs review on creation; preserved on later runs.
Review notes	Human notes; never overwritten by the fetch step.

Keep the GitHub release ID separate from NocoDB’s row ID. The first identifies the release; the second identifies the row to update. Configure a unique constraint on Release key if your table and deployment support it. A lookup followed by Create alone can race if two executions run at once.

Fetch one release manually

1. Start with a Manual Trigger and an HTTP Request node. Use GitHub’s latest-release endpoint: GET /repos/{owner}/{repo}/releases/latest. Substitute the repository you want to follow.
2. Inspect a successful response before mapping it. This endpoint returns the latest qualifying published release, excluding drafts and prereleases. It is not a complete release history.
3. In Edit Fields, map the response fields in the table and construct Release key from the configured repository and id. Keep the release object available for the Create branch after the lookup.
4. Stop without writing a row if required fields are missing or the request fails. A 404 can mean no qualifying release, a wrong repository path, or inaccessible private content. A timeout or rate-limit response is not a new release.

Look up the row before creating it

Follow n8n’s NocoDB credential instructions, using an endpoint reachable from the n8n server and a token authorized for the required table operations. The NocoDB node documents separate Create, Get, Get Many, and Update operations; Create is not an upsert.

1. Use Get Many to find rows whose Release key exactly matches the constructed key. Configure the filter supported by your node version and inspect the returned data. If you filter after retrieval, fetch all required pages so a partial result cannot produce a false “not found.”
2. Route by the match count. Zero matches may create a row; one match skips creation; more than one match stops for duplicate cleanup. Make the empty-result branch explicit: some node configurations emit no items when nothing matches, so a following IF node would otherwise never execute. Test that case and use the node’s supported output settings or a separate aggregation branch.
3. For zero matches, map the stored release fields into Create and set Needs review. For one match, the simplest policy is to skip it. If you choose to refresh release notes later, use the existing NocoDB row ID and update source fields only, preserving review status and human notes.
4. On a timeout during creation, look up the key again before retrying: the first write may have succeeded. If a unique constraint rejects the insert, read the matching row and check it rather than blindly retrying Create.

Use a unique key at the storage layer when available, and avoid overlapping executions. If your deployment cannot enforce uniqueness, serialize this workflow and document that a read-before-create check is not an atomic guarantee.

Lookup result	Action
No match	Create once; initialize review status.
One match	Skip, or update selected source fields while preserving review decisions.
Multiple matches	Stop and resolve duplicate records.
Request or lookup failure	Record the failure; do not create an incomplete row.

Test before adding a schedule

• Run against a release with no existing row. Confirm exactly one row with the expected key, tag, date, notes, source link, and status.
• Run again with the same release. Confirm the row count stays at one.
• Mark that row reviewed and add a human note. Run again and confirm both survive.
• Using test data, exercise a different release ID, an empty lookup result, and a failed request. Verify that only the new release creates a row.
• Check retry and overlap handling before depending on unattended execution.

After those checks pass, add a Schedule Trigger. Set the intended timezone, save and publish the workflow, and configure an error notification or reviewable failure log. Choose a polling interval compatible with the API limits and your review routine.

FAQs

Will this capture every release?

No. The latest-release endpoint can miss releases published between polls and excludes drafts and prereleases. For complete history, use a release-listing workflow with pagination and the same stable-key checks.

Does Needs review mean an update is safe to install?

No. It means the source details were captured. Read the release notes, check your installed version and dependencies, and make the update decision yourself.

Can I use this for a tool outside GitHub?

Use a documented source and a stable identifier from that vendor. Inspect its response and adapt the mapping and deduplication key before scheduling it.

Can a webhook replace polling?

Only when you can configure the relevant webhook and provide a reachable endpoint with the required authentication. A private VPN connection on your own laptop does not make an n8n endpoint reachable by GitHub’s servers.