You can write your own profiling code by using Game.cpu.getUsed(). However, many cpu spikes are caused by things largely out of your control, such as garbage collection. If you're only seeing occasional spikes, it's probably nothing to worry about.

Do visuals posted to all rooms that way only incur a single instance of the serialization cost?

It looks like the creep standing on the build site blocked the construction, because storages are not passable.

Creeps can move off of the site during the tick construction is attempted, so the build() call can't know for certain to return a failure code.

I feel like that might be both too strong and too simple. Perhaps as an alternative, we could have doors, which act like a toggleable wall. It increases the involvement of the door owner's scripts, and potentially provides attack opportunities for opponents to exploit mistakes in its programming.

Figured it out. Python's default auth handling expects a specific style of 401 response to the initialize request, which I guess isn't provided by the screeps site.

I just created a script to start using the upload API, but I ran into a problem. Every GET or POST is being met with a 401 "Unauthorized" response, but as far as I can tell the script is functional (through testing it on other sites) and my email and password should be correct.

For reference, here's the python 3.3 script I'm using: https://gist.github.com/ThyReaper/89fb434d413f45a3c033407410ffdfaa 

Any ideas what might be wrong?

I would second having combat notices (specifically relating to other players attacking) separated out. Having separate frequency settings for these would be great as well.

Perhaps also have an option to disable cpu limit notices - usually I'll get a notification email that is just letting me know that, at some point, the cpu limit was breached once.

In one of my mining rooms, I have a group of Invaders that can't quite figure out how to reach my creeps: https://screeps.com/a/#!/history/E5S11?t=10295324

They chase nearby creeps as they pass by, but then get stuck near the border of the room now and then.

I've also seen this issue, but I wasn't sure it wasn't something I was doing wrong. I saw it with a creep trying to move from E3S14 at 46,24 to 47,23. The creep was unable to move into that tile until something caused the invaders to decide to move away from 47,23.

Perhaps the Invaders are trying to move onto the rampart tile while attacking, and that's somehow reserving the tile as if they were succeeding to move there?

It would be very helpful if the room stats page had options to show stats for periods in ticks, rather than (or in addition to) hours and days. This would help minimize the variation that happens as server load changes over time, or when there's downtime due to some issue.

Possibly as an alternative, if the scripts had access to the same sorts of stats that are being aggregated, we could setup our scripts to generate statistic reports to our liking. e.g. room.getStat(STAT_CREEPS_PRODUCED) would return the number of body parts produced in the previous tick.