►
From YouTube: Design for new Runner Fleet Dashboard
Description
Gina Doyle (Senior Product Designer: Runner Fleet) shares a design for a new Runner Fleet dashboard that will help admins get a better at-a-glance view of their fleets of runners.
Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/390921/
A
What
we
have
today
is
this
we're
looking
in
the
admin
area
right
now,
so
we
have
this
runner's
page,
where
you
have
a
list
of
all
the
runners
that
you
have
instance,
group
or
project
type
and
kind
of
a
breakdown
of
the
statuses.
What
we've
just
added
recently
is
another
item
here
around
mean
waiting
time.
For
instance,
Runners.
A
One
of
the
problems
that
we've
been
facing
recently
are
performance
issues
on
this
page.
When
we
added
the
mean
waiting
time
component
here,
we
actually
had
to
have
him
open
it
up
in
a
modal
so
that
it
was
able
to
load
not
just
when
this
page
loads.
So
not
only
are
we
dealing
with
performance
issues
at
this
point
also,
this
page
isn't
really
scalable.
There's
no
there's
really
not
that
much
more
room
to
put
other
items
here
and
going
back
to
the
problem.
A
Even
if
you
come
to
this
page,
there's
not
enough
data
for
the
platform
engineer
to
know.
Are
there
issues
going
on?
We
don't
show
failures
unless
you
were
to
actually
dig
into
a
runner
and
like
look
at
their
jobs,
and
we
also
just
don't
have
enough
performance
indications
on
this
page
for
them
to
get
an
idea
of
how
the
runners
are
performing.
A
So
one
of
the
things
that
the
team
wanted
to
do
at
first
is
update
the
navigation
to
include
this
new
dashboard
and
different
ways
to
get
to
different
things
for
runners.
Luckily,
the
foundations
team
had
already
included
guidance
around
Navigation
updates
and
Austin
had
presented
at
the
ux
Showcase,
so
I
felt
confident
kind
of
shutting
that
idea
down
and
saying
that
we
should
explore
other
Solutions
first,
which
then
led
us
to
this
dashboard
idea.
A
Give
you
a
look
at
what
that
would
look
like
that.
We
would
really
just
be
replacing
the
current
landing
page
for
the
runner's
nav
item
with
this
new
dashboard
and
we'd
still
allow
users
to
get
to
see
all
their
Runners
like
they
do
today.
So
they
could
still
get
to
this
view
minus
the
stats
here,
but
they
would
have
to
do
that
by
drilling
down
so
they'd
be
able
to
go
view
all
Runners
and
then
we'd
use
breadcrumbs
there
to
indicate
where
there
are
where
they
are
and
in
this
dashboard
View.
A
The
goal
is
to
really
be
able
to
give
them
that
at
a
glance
View
and
highlight
any
problems
that
are
going
on.
So
you
can
see
in
this
larger
panel
over
here
I
talk
about
health
status
and
that's
the
if
there's
unhealthy
Runners.
That
means
that
there's
been
Runner
failures
in
I
say
the
last
hour,
but
we
might
need
to
change
that,
depending
on
what
validation
I
get
unhealthy
Runners.
A
None
of
this
UI
text
has
been
looked
at
just
a
side
note,
but
unhealthy
Runners
are
really
important
to
note,
because
this
means
that
they're
not
running
as
expected
and
code
isn't
going
out.
So
they
need
the
admin
would
need
to
fix
these.
What
we
can
do
right
now
is
when
a
runner
failure
happens,
which
is
not
the
same
thing
as
a
job
failure.
A
A
runner
failure
is
separate,
so
a
job
could
fail
because
of
other
reasons,
but
it
might
not
be
because
a
runner
has
a
problem,
so
we
would
pull
in
the
failure
message
and
then
link
to
the
job
so
that
you
could
look
at
the
job
log,
which
spits
out
some
important
details
about
Runners
and
then
the
other
thing
that
admins
can
do
is
also
look
at
their
Runner
logs.
Those
aren't
in
gitlab
UI,
so
they'd
have
to
look
at
that
locally.
A
The
other
thing
that
I
have
here,
which
I'm
almost
using
these
as
tabs,
which
is
probably
not
the
right
use
but
but
I,
wanted
to
show
this
concept
of
how
busy
our
Runners
are.
We
know
the
concurrency
that
each
Runner
has
set.
If
you
just
create
a
runner
in
the
UI,
concurrency
is
automatically
set
to
one,
it's
always
the
standard,
so
it
can
run
one
job
at
once,
but
you
could
set
it
to
something
larger
like
10..
So
that
means
that
it
can
run
10
jobs
at
once.
A
A
So
we'd
show
like
this
list
of
jobs,
which
is
important,
because
you
could
also
look
at
the
queue
time
and
if
that's
getting
longer,
then
maybe
you
need
to
create
another
Runner
with
the
same
configuration.
But
in
this
case,
like
all
these
would
be
running,
that's
what
you
would
see
here
so
the
other
panels
here.
One
of
them
is
estimated
wait
time,
which
is
a
feature
that
a
lot
of
customers
have
asked
for
lately
and
we've
added
the
first
shot
of
this
to
this
page
actually.
A
But
we
want
to
keep
extending
that
and
we
haven't
had
the
chance
to
because
of
the
whole
performance
issue
that
we're
having
and
because
the
way
that
you
can
store
all
that
in
the
back
end.
We
don't
have
100
down
right
now,
so
this
is
shown
like
over
a
three
hour
period
of
time
and
we
might
not
be
able
to
do
that
right
now,
because
we
don't
have
storage
on
the
back
end.
But
there's
a
working
group.
That's
exploring
that
so
anyways.
A
The
estimated
wait
time
would
actually
give
them
a
more
of
an
idea
of
performance
and
we
could
show
percentiles,
which
we've
already
calculated
through
a
query
and
then
how
the
mean
waiting
time
is
trending
over
time.
So
this
has
been
going
up
by
three
percent
in
the
last
three
days,
which
is
bad
because
you
want
it
to
be
as
low
as
possible.
A
In
this
case.
The
reason
why
I'm,
showing
busy
Runners
by
itself
over
the
left,
and
then
this
over
to
the
right,
is
because
we
can
only
show
estimated
weighted
time
per
like
a
group
of
Runners
right
now
versus
The
Busy
busiest
Runners
over
here
to
the
left.
We
could
show
at
a
singular
level,
so
that
gives
them
so
like
the
opportunity
to
kind
of
go
back
and
forth
if
they
need
to.
A
The
last
thing,
I've
tried
to
add
here
are
events.
We
have
some
audit
events
that
we
get
for
runners
already,
but
I
was
thinking
that
tracking
these
events
would
not
only
help
for
security
and
compliance,
but
also
identify
with
the
root
cause
of
some
problem
was
so
he
could
detect
like
when
a
runner
goes
offline
versus
online
and
maybe
like
that
was
related
to
an
upgrade
that
you
made
to
the
runner
stuff
like
that,
something
that
I'm
exploring
that
I'd
still
want
to
validate.
A
A
The
events
were
something
that
I
was
toying
around
with
to
help
them
kind
of
get
to
that
root,
cause
again,
because
I
know
that
that's
like
the
ultimate
thing
is
that
they
want
to
fix
the
runner.
So
that's
what
I've
come
up
with
so
far
and
I'd
really
really
love
any
feedback
that
you
have
on
this
design.
I
want
to
validate
this
with
Enterprise
customers.
This
Milestone,
so
I
appreciate
it.