Latest Release: 05/01/19
Release Notes can be found here.

Can you provide a detailed explanation of workflow timing diagram?

birgerbirger Member, Broadie, CGA-mod ✭✭✭

Looking at the workflow diagram, I see for each call a multi-colored bar describing the changing state of a job (called task) on FireCloud. The GUI makes it difficult to get information on each of the states (e.g., sometimes the leftmost portion of the bar is associated with "Pending", other times it is associated with "PreparingJob"). It may be that both states and the transition between the two is captured, but one or the other is so short it is impossible to click on it. Regardless of the graphical display, however, I would like to know what each of these states means.

Using the API, I was able to see that the API returns a sequence of execution events for each call, e.g.,

    "executionEvents": [
        "startTime": "2017-01-10T17:19:59.284Z",
        "description": "Pending",
        "endTime": "2017-01-10T17:19:59.284Z"
        "startTime": "2017-01-10T17:19:59.284Z",
        "description": "PreparingJob",
        "endTime": "2017-01-10T17:19:59.286Z"
        "startTime": "2017-01-10T17:19:59.286Z",
        "description": "RunningJob",
        "endTime": "2017-01-10T18:02:50.113Z"
        "startTime": "2017-01-10T18:02:50.113Z",
        "description": "UpdatingJobStore",
        "endTime": "2017-01-10T18:02:50.124Z"

I'm guessing that it is this information which is depicted in the workflow timing diagram. I'd like to know what each of these states means. In particular,

(1) Is the call in a pending state prior to the creation of the VM Instance? What causes a call to remain in a pending state for a long time?
(2) Does the call state move to PreparingJob when the VM instance is created? What is happening while the call is in this state? I don't think file localization occurs when in the PreparingJob state because typically the call remains in the state for too short a period.
(3) Does the RunningJob state also cover file localization times?
(4) What is going on in the UpdatingJobStore state?
(5) Is the time we are charged for the time we are in the RunningJob state?

We would like this information to assist the benchmarking and workflow optimization work we are doing. It would be very helpful if we could get answers to this relatively quickly.


Issue · Github
by Geraldine_VdAuwera

Issue Number
Last Updated
Closed By


  • birgerbirger Member, Broadie, CGA-mod ✭✭✭

    Note: I think I was wrong about my assumption that the information retrieved from the/api/workspaces/{workspaceNamespace}/{workspaceName}/submissions/{submissionId}/workflows/{workflowId} API is the source of the data for the timing diagram. When I looked at the workflow timing diagram for a workflow that used preemptable machines, it shows the retries resulting from preemption, but the call stats retrieved from the API for the same workflow call does not contain retry information.

    Is the information used to construct the timing diagram available across the public API? If so, what is the API endpoint to retrieve it. If not, it should be (consistent with FireCloud's design philosophy that all information and services available through the GUI should also be available programmatically through the REST APIs).

  • Geraldine_VdAuweraGeraldine_VdAuwera Cambridge, MAMember, Administrator, Broadie admin

    I'll check with the team whether they have internal documentation for this. If not, it will be difficult to produce documentation on this quickly since we have a lot of work on our plate and this is not the highest priority. You may be better off looking at the relevant code directly; if you're interested I can get you some pointers on what to look at.

  • birgerbirger Member, Broadie, CGA-mod ✭✭✭

    Geraldine, I don't know scala. Who in the engineering group can I speak with? It won't be more than a 15 minute conversation.

  • Geraldine_VdAuweraGeraldine_VdAuwera Cambridge, MAMember, Administrator, Broadie admin

    @birger If you'd like to discuss this directly with the engineering team, please attend their office hours at 2pm on Wednesdays in 75A-04-Yosemite-4001.

  • birgerbirger Member, Broadie, CGA-mod ✭✭✭

    I've already arranged for that. Thanks!

  • mnoblemnoble Broad Institute of MIT & HarvardMember, Broadie

    FWIW, I am similarly puzzled by the semantics of the colors used in the timing diagram. For example, in the attached images (both drawn from nci-dheiman-b-org/analyses__2017_09_19 workspace) one uses purple to denote "running" and the other uses orange. Thank you for any clarification.

  • KateNKateN Cambridge, MAMember, Broadie, Moderator admin

    The colors are not consistently the same across different workflows/runs. I'm not sure the reason why it was set up that way originally, but all the colors aim to tell you is that something different is happening when the color changes.

  • birgerbirger Member, Broadie, CGA-mod ✭✭✭

    This can be really confusing for the user.

  • KateNKateN Cambridge, MAMember, Broadie, Moderator admin

    I will raise a feature request ticket for standardizing the colors for you then. Consistent colors would be helpful for sharing screenshots of timing diagrams.

  • birgerbirger Member, Broadie, CGA-mod ✭✭✭
Sign In or Register to comment.