I view per-container liveness probes as having 4 main parts:

1. Probe control parameters: At minimum, there needs to be a probe interval (in seconds is probably fine) and timeout period (in same units as probe interval), with reasonable defaults for both. An initial (post-(re)start) delay is also typically needed, to allow for non-trivial application startup times. We could also support a threshold for the number of failures to allow before action is taken (called unhealthy_threshold in the load-balancing context). This would cover retry in the case of spurious failure. If we do, we may also want to support a number of successes before we reset this failure count (healthy_threshold).
2. Probe mechanism.
   • HTTP GET includes at least port, path, and perhaps URL parameters. 200==success is easy to implement and to understand, but would mean that it could not share the same handler as load-balancer health (i.e., readiness) checks. Consequently, we may want to treat 404, 500, and 503 as success, also. Intentional failure would be indicated by not responding. Non-standard success/failure criteria and/or more complex logic could be implemented using commands (e.g., wget or curl).
   • Command. Exit 0 would imply success. Agree that "run in" would be lighter-weight than a separate container.
3. Action control parameters: The main one is the grace period -- how long to wait before using SIGKILL. We could support configuration of a default grace period for all stop operations on the container, but it is also useful to use different grace periods for different kinds of stop reasons.
4. Action mechanism.
   • SIGTERM. Convenient in many languages but hard to pass other information, such as termination reason and grace period.
   • HTTP POST / web hook.
   • Command, again using "run in".

We also want it to be easy to disable/reenable these checks, such as for attaching a debugger and stopping at a breakpoint.

It's worth noting that docker stop sends SIGTERM, waits for a parameterized grace period, and then sends SIGKILL, which is basically the behavior we want:
POST /containers/(id)/stop?t=(seconds)
http://docs.docker.com/reference/api/docker_remote_api_v1.12/

FWIW, some do not like SIGKILL:
moby/moby#6446
It was pointed out that kill takes a signal parameter, which maybe they also want to support in stop, but I think a longer grace period is mostly what they need.

FWIW, here's a description of Marathon's liveness checks:
https://github.com/mesosphere/marathon/wiki/Health-Checks

HTTP responses between 200-399 are considered live. The max # of consecutive failures is configurable (as with GCE's LB readiness checks).

Aurora's are similar:
http://aurora.incubator.apache.org/documentation/latest/configuration-tutorial/

I believe this is now fixed.