Outside of the Jira context, an Epic represents some kind of deliverable business value. An Epic is usually made up of good Stories, the full value is realized to the client and users after all of the stories are completed and delivered. Not all Stories need to be part of an Epic. I would also say that other types of backlog items, such as items that represent technical debt or bugs, would not be part of an Epic.
I tend to use Epics to represent work that spans multiple iterations, although I can also see value in grouping related Stories per the definition of an Epic. It's also tied to a release - although in most cases, the stories could be released independently, I tend to release an Epic into production environments at once while deploying work into test and demonstration environments far more regularly. The Epic makes the work visible as it progresses through states. For example, states include Open, In Progress, Review, Test, Released. Stories move from Open through Released to mean that they are in the Epic's test/demo environment and have been coded, code reviewed, and tested. The Epic does the same, but enters Review when it's being merged into the main development branch and Test as final regression testing is happening, and finally Released to indicate all of its stories are live.
I would look at why you are continuously adding new bugs and stories to Epics. It seems like you're trying to use the Jira Epic as a Release or Tag, both of which also exist in Jira. Instead of trying to track maintenance and support effort by Epic, track it by things like component or assigned to a particular release. If you need to, Root Cause Analysis techniques can be applied to trace future work back to particular epics and you can again use tags or maybe some kind of custom fields to link support work back to the work that caused it.
