Let me cut to the chase and offer the following as a definition of a successful Sprint:
A successful Sprint is one where an increment of significant customer/user value has been sustainably delivered in broad alignment with what the team had forecast that they would deliver. As a consequence of their work they now have a better understanding of their problem-domain, and of their next steps. Additionally, the team have agreed what they will do differently (improve) to try and increase the likelihood of success in their subsequent Sprint(s).
Success criteria for a Sprint is something that I have discussed more times that I can keep track of. From interns and graduates fresh out of university to seasoned C-level managers, everybody seems to have their own idea of what 'success' looks like in Scrum.
Probably the most commonly cited definition is that 'every card brought into the Sprint in Sprint Planning is done'. I think that this viewpoint revolves around the common misunderstanding that the Sprint Backlog is a task list, and therefore the definition of success is coupled to that list being completed.
That's a kinda scary definition, because it inverts the first principle of agile software development by suggesting that following a plan is the most important thing.
Another common angle is that 'success' means that the Sprint Goal is done. I greatly prefer this over the previous definition; a well crafted Sprint Goal ensures that there is flexibility in scope, but also provides a 'guarantee' that value in being delivered to the user/customer. If a team is achieving this every Sprint, that is a typically a pretty good sign for the health of the team, and the project. But it is definitely not the only sign of success.
For example, imagine a team that takes on a hugely complicated/complex Sprint Goal, and delivers all bar one very small part of it. Perhaps it is a global product and they managed to release an industry-changing new feature in all bar the smallest of their supported markets. This is probably still a triumphant victory for not just the team but their wider business. If they had taken on a smaller goal which they did get completely 'done' but made no material difference to the business or industry, would that have been more successful? I think that we'd all agree not.
The purpose of a Sprint is to give teams a chance to creatively solve complex problems. It's an empirical process which means it all revolves around inspection and adaption.
This starts to highlight the problem with having black and white 'success' criteria. In a complex domain, we cannot [reliably] predict the relationship between cause and effect. In other words, we can't know before we start exactly how things will unfold. It's like trying to define success for each and every child, before they are even born.
Our definition of success really needs to acknowledge the uncertainty that has brought us towards an empirical agile process, rather than a tightly defined (more waterfall) one. This takes us to where we started this post, with a definition of success which can be applied uniformly and crucially explained to key stakeholders like management.
Your Sprint Goal still matters, but I think it is for the team to define and understand exactly what it means to them. The Scrum Guide says it "…is an objective set for the Sprint that… provides guidance to the Development Team on why it is building the Increment", and I think that is a pretty good starting point.
If you've got a different (or more concise) definition of success, please comment below.