Access to a variable in the inspector

Health is not a variable, it's a Property, and Properties (like functions) can't be exposed in the inspector.

One option would be to make _health public, then it would automatically be exposed in the inspector. However, presumably the point of your Property is to ensure that your "events" happen when the value is changed from outside the class, and this would remove that protection.

A better alternative is just to use the [SerializeFIeld] attribute on _health. That way you can change its starting value in the inspector, but it retains its privacy as far as its use in code is concerned.

One disadvantage of this approach is that it's still possible to accidentally modify _health directly rather than via Health, from within the class. So an alternative approach that I sometimes take is this kind of thing...

 public int startingHealth = 100;
 private int _healthBacking;
 public int Health
 {
     get { return _healthBacking; }
     set { _healthBacking = value; // other stuff }
 }
 Awake()
 {
     Health = startingHealth;
 }

The point being that because of the names, collaborators (in which I include my future self) are much less likely to use either _healthBacking or startingHealth erroneously. If I'm feeling particularly paranoid I might even call it _healthBackingDONOTUSE. If it's a variable that should never be used directly, why not make that explicit? Similarly, when one changes startingHealth in the inspector one knows exactly what it is one is modifying. When one can, it's better to direct ones collaborators towards the proper usage through careful naming of things, than by adding comments (you can't be sure that they'll spot or read the comments, but they'll always see the names).

It also means that you know that the events that need to happen when Health is set, happen when it is initialised, which can simplify ones set-up code.

Declare you _health variable as public instead of private. "Health" is your function and "_health" is your variable. You mentioned "Health" as a variable.

 public int _health = 100;

 public int Health
 {
     get{return _health;}
     set
     {
         //events
     }
 }

In addition to the backing information provided by @Bonfire-Boy regarding the serialization of fields vs. properties, I want to offer that the recommended way to handle this situation out-of-the-box is:

1. Make your backing field private and mark it with [SerializeField]

2. Use your property or otherwise re-validate your backing field data within the OnValidate() callback for your MonoBehaviour. This message is sent whenever data is modified in the Inspector and when the MonoBehaviour is deserialized in the Editor.

You can also use this Asset Store package and eliminate step 2 (with the qualification that it will only handle editing from the inspector, and not also validating upon deserialization).