There are a few things that this could be caused by. The main root cause is that Reporting is not able to decrypt information it found about a reporting job, because that data was encrypted under a different key.
The quick fix is to make sure there is a xpack.reporting.encryptionKey in the kibana.yml file, and that key is the same for every instance of Kibana that uses the .reporting-* index pattern.
If there is not a xpack.reporting.encryptionKey setting in the kibana.yml file, Reporting will be forced to generate a new key for each server startup, and it will encrypt its jobs in .reporting-* using that encryption key. The problem that causes: jobs that were in pending status right before the server restarted are lost forever. The key that encrypted them was random and is no longer in the server's memory.
If there are multiple Kibana instances using the same Elasticsearch cluster, by default they will also use the same .reporting-* index pattern for Reporting storage. When that is done intentionally, it works very well because the instances can share the load of generating reports. It can unintentionally create a problem where one instance discovers a job that it shouldn't be able to.
For the 6.7 version, the documentation has the details about how to handle either situation:
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.