Custom module versioning
By default, Drupal assumes that any installed module or theme is hosted on drupal.org. This means that, if you are using a custom module (which is probably not hosted on drupal.org), Drupal will return the error you are seeing because it doesn't find any information about the module you are using, on drupal.org.

If you just want to stop Drupal from looking for a module updates, normally because you are using a different method to update it, or because the module is not hosted on drupal.org (for example, a custom module you have on your computer, on Git, Gitlab, or similar services) you can implement hook_update_projects_alter().

function custom_module_update_projects_alter(&amp;$projects) {
  // Hide a site-specific module from the list.
  unset($projects['custom_module']);
}


With this example code, the custom_module module is hiding itself, but a module can hide any module. For example, if I had a custom_core module that is a dependency for every custom module I use on my site, I would implement the hook using code similar to this.

function custom_core_update_projects_alter(&amp;$projects) {
  // Hide all the site-specific modules from the list.
  unset($projects['custom_user_data']);
  unset($projects['custom_entities']);
  unset($projects['custom_spam_prevention']);
}


If you want Drupal checks for updates on a site that is not drupal.org, then the .info.yml file for the module needs to contain the following line. (See the code of the UpdateFetcher class, which is the class that fetches project information from remote locations.)

project status url: http://example.org/project-history


In this case, for a module using my_module as machine name, Drupal will fetch the information about Drupal 8 releases of the module from http://example.org/project-history/my_module/8.x.

Notice also that:


If the .info.yml file also contains a project: my_custom_project line, Drupal will check for information about Drupal 8 releases of the module from 
http://example.org/project-history/my_custom_project/8.x, not http://example.org/project-history/my_module/8.x (This is useful when a module is a sub-module of another module, and both are packaged in the same file.)
Drupal expects that http://example.org/project-history/my_module/8.x returns XML data that follows a specific format; you can see for example what drupal.org returns for the Date module (https://updates.drupal.org/release-history/date/8.x)

&lt;?xml version="1.0" encoding="utf-8"?&gt;
&lt;project xmlns:dc="http://purl.org/dc/elements/1.1/"&gt;
  &lt;title&gt;Date&lt;/title&gt;
  &lt;short_name&gt;date&lt;/short_name&gt;
  &lt;dc:creator&gt;vijaycs85&lt;/dc:creator&gt;
  &lt;type&gt;project_module&lt;/type&gt;
  &lt;api_version&gt;8.x&lt;/api_version&gt;
  &lt;project_status&gt;unsupported&lt;/project_status&gt;
  &lt;link&gt;https://www.drupal.org/project/date&lt;/link&gt;
  &lt;terms&gt;
    &lt;term&gt;
      &lt;name&gt;Projects&lt;/name&gt;
      &lt;value&gt;Modules&lt;/value&gt;
    &lt;/term&gt;
    &lt;term&gt;
      &lt;name&gt;Maintenance status&lt;/name&gt;
      &lt;value&gt;Actively maintained&lt;/value&gt;
    &lt;/term&gt;
    &lt;term&gt;
      &lt;name&gt;Development status&lt;/name&gt;
      &lt;value&gt;Under active development&lt;/value&gt;
    &lt;/term&gt;
  &lt;/terms&gt;
  &lt;releases&gt;
    &lt;release&gt;
      &lt;name&gt;date 8.x-1.x-dev&lt;/name&gt;
      &lt;version&gt;8.x-1.x-dev&lt;/version&gt;
      &lt;tag&gt;8.x-1.x&lt;/tag&gt;
      &lt;version_major&gt;1&lt;/version_major&gt;
      &lt;version_extra&gt;dev&lt;/version_extra&gt;
      &lt;status&gt;published&lt;/status&gt;
      &lt;release_link&gt;https://www.drupal.org/project/date/releases/8.x-1.x-dev&lt;/release_link&gt;
      &lt;download_link&gt;https://ftp.drupal.org/files/projects/date-8.x-1.x-dev.tar.gz&lt;/download_link&gt;
      &lt;date&gt;1380568703&lt;/date&gt;
      &lt;mdhash&gt;f36524e70ed83fe7f2812d3768a337c0&lt;/mdhash&gt;
     &lt;filesize&gt;164918&lt;/filesize&gt;
     &lt;files&gt;
       &lt;file&gt;
         &lt;url&gt;https://ftp.drupal.org/files/projects/date-8.x-1.x-dev.tar.gz&lt;/url&gt;
         &lt;archive_type&gt;tar.gz&lt;/archive_type&gt;
         &lt;md5&gt;f36524e70ed83fe7f2812d3768a337c0&lt;/md5&gt;
         &lt;size&gt;164918&lt;/size&gt;
         &lt;filedate&gt;1380568703&lt;/filedate&gt;
       &lt;/file&gt;
       &lt;file&gt;
         &lt;url&gt;https://ftp.drupal.org/files/projects/date-8.x-1.x-dev.zip&lt;/url&gt;
         &lt;archive_type&gt;zip&lt;/archive_type&gt;
         &lt;md5&gt;781eb8cb238ed8649c93f0e8e2b9e778&lt;/md5&gt;
         &lt;size&gt;232819&lt;/size&gt;
         &lt;filedate&gt;1380568703&lt;/filedate&gt;
       &lt;/file&gt;
     &lt;/files&gt;
     &lt;security&gt;Dev releases are not covered by Drupal security advisories.&lt;/security&gt;
   &lt;/release&gt;
 &lt;/releases&gt;





Not all the information provided is required, but for each release there must be a URL for the archive containing the module code, which is used from Drupal to download and copy the module on the site server.



As side note, updating a module files with Composer would be the first step to update the module. Drupal still needs to invoke the update hooks the module provide, and update the module information it stores in its database tables (and cache).